Azure Dev Box 上の仮想マシンで Install-Module -Name d365fo.tools を実行すると、依存モジュール PSFramework のダウンロード失敗（PackageFailedInstallOrDownload）で止まってしまうことがあります。ブラウザでは PowerShell Gallery にアクセスできても、PowerShell だけ失敗するケースは珍しくありません。この記事では原因の切り分けから、オンライン／オフライン双方の確実な解決手順までまとめます。
起きている現象：Install-Module d365fo.tools が PSFramework で失敗する
Azure Dev Box（または類似のクラウドVDI/仮想マシン）上で、PowerShell から次のようにモジュールをインストールしようとすると失敗します。
Install-Module -Name d365fo.tools -Force -Verboseログ上の典型的なメッセージは、以下のような内容です（表現は環境で多少変わります）。
Package 'PSFramework' failed to downloadPackageFailedInstallOrDownload
d365fo.tools は内部的に PSFramework を利用しているため、依存関係が解決できないとインストールが止まります。問題の本質は「d365fo.tools そのもの」ではなく、PowerShell 側が PowerShell Gallery/NuGet から必要なものを取得できない点にあることが多いです。
ブラウザで見えるのに PowerShell が失敗する理由
「ブラウザでパッケージページは開けるのに、PowerShell の Install-Module だけ失敗する」場合、ネットワークが完全に死んでいるわけではありません。よくある理由は、ブラウザと PowerShell が参照する設定や通信経路が異なることです。
| 症状 | よくある原因 | 確認ポイント |
|---|---|---|
| ブラウザはOK、PowerShellはダウンロード失敗 | プロキシ設定の差（WinINET と WinHTTP の違い） | netsh winhttp show proxy、IE/Edge のプロキシ設定 |
PackageFailedInstallOrDownload が出る | TLS 1.2 未使用／証明書検査（SSLインスペクション） | TLS有効化、社内CAの配布状況 |
| NuGet Provider の取得に失敗する | PackageManagement/NuGet Provider が自動導入できない | Get-PackageProvider の結果 |
| インストールはできたのに Import が失敗 | ExecutionPolicy、ファイルのブロック（Zone.Identifier） | Get-ExecutionPolicy -List、Unblock-File |
| 管理者権限がないと失敗しやすい | AllUsers パスに書き込めない | CurrentUser に入れる、保存してコピー |
特に Azure Dev Box のような管理された環境では、セキュリティ機構・プロキシ・TLS/証明書・実行ポリシーが組み合わさって「PowerShell Gallery からの取得だけが不安定」になりがちです。
最短で直すための基本整備：TLS / PowerShellGet / NuGet / リポジトリ信頼
まずは土台を整えます。ここが崩れていると、どのモジュールでも似たような失敗を繰り返します。以下は「変更を最小限」にしつつ成功率を上げるための定番セットです。
TLS 1.2 を明示してから実行する
古い OS/PowerShell、あるいは環境の設定次第では TLS 1.2 が自動で使われず、ギャラリーへのアクセスが途中で失敗します。セッション内だけ明示してから実行します。
# セッション内で TLS 1.2 を有効化（影響範囲を限定）
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12PowerShell Gallery を確認し、必要なら Trusted にする
初回導入時に確認プロンプトが出たり、環境によっては信頼状態が中途半端で止まることがあります。状態を確認し、必要に応じて Trusted に変更します。
Get-PSRepository
# PSGallery が Untrusted の場合（運用ポリシーに従って実施）
Set-PSRepository -Name PSGallery -InstallationPolicy TrustedNuGet Provider の状態を確認する
Install-Module は内部的に NuGet Provider を使います。ここが入っていない／壊れている／取得できないと、依存モジュールの取得が失敗します。
Get-PackageProvider
Get-PackageProvider -Name NuGet -ListAvailableNuGet Provider が見当たらない場合は、次を試します（管理者権限がない場合は失敗することがあります）。
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Forceよく使う事前チェック（まとめ）
| チェック項目 | コマンド | 期待する状態 |
|---|---|---|
| TLS 1.2 | [Net.ServicePointManager]::SecurityProtocol | Tls12 が含まれる |
| PSGallery | Get-PSRepository | PSGallery が存在し、必要なら Trusted |
| NuGet Provider | Get-PackageProvider | NuGet が利用可能 |
| モジュールパス | $env:PSModulePath -split ';' | 書き込み可能なパスがある |
ここまで整えても PSFramework のダウンロードが失敗する場合は、次の「依存モジュールを先に入れる／手動で入れる」方向に進むのが早いです。
解決策：依存モジュール PSFramework の存在確認と手動導入
d365fo.tools が失敗する直接原因が PSFramework の取得失敗である以上、先に PSFramework を確実に導入できれば解決に近づきます。
まずは存在確認（インストール済みか）
Get-Module -ListAvailable PSFrameworkAllUsers（全ユーザー）に入っているかを、フォルダでも確認できます。
C:\Program Files\WindowsPowerShell\Modules\PSFramework
ただし Azure Dev Box などで管理者権限がない場合、AllUsers パスに書き込めないことがあります。その場合は CurrentUser パス（ユーザー配下）へ入れるのが安全です。
| スコープ | 代表的な配置先 | 権限 |
|---|---|---|
| AllUsers | C:\Program Files\WindowsPowerShell\Modules\ | 管理者が必要になりやすい |
| CurrentUser | C:\Users\<ユーザー名>\Documents\WindowsPowerShell\Modules\ | ユーザー権限でOKなことが多い |
オンラインで入れられるなら、まず PSFramework 単体を入れる
# 依存を先に解消
Install-Module -Name PSFramework -Force -Scope CurrentUser -Verbose
# その後に d365fo.tools
Install-Module -Name d365fo.tools -Force -Scope CurrentUser -Verboseポイントは「-Scope CurrentUser を明示して、書き込み先をユーザー配下に寄せる」ことです。AllUsers への書き込みや UAC で詰まるケースを避けられます。
PowerShell Gallery から nupkg をダウンロードして手動配置する
今回のように「ブラウザはOK」なら、nupkg（実体は ZIP に近い）を落として手動で配置する方法が強力です。手順の要点は次のとおりです。
- ブラウザで
PSFrameworkのパッケージページを開き、nupkg をダウンロードする - ダウンロードしたファイルのプロパティで「ブロックの解除」を実行する（重要）
- nupkg を解凍し、モジュールフォルダを取り出す
$env:PSModulePathに含まれる配置先にコピーする（推奨：CurrentUser）
ブロック解除は GUI でもできますが、PowerShell でも実行できます。
# 例：ダウンロードフォルダのファイルを解除
Unblock-File -Path "$env:USERPROFILE\Downloads\PSFramework.1.0.19.nupkg"モジュールの配置先が不明な場合は、次で確認します。
$env:PSModulePath -split ';'配置後は認識されるかを確認します。
Get-Module -ListAvailable PSFramework
Import-Module PSFrameworkここまでできたら、改めて d365fo.tools の導入に進みます。
ExecutionPolicy と「ブロック」の解除：インストール後に Import が失敗する対策
モジュールのダウンロードに成功しても、実行ポリシーやファイルのブロックで読み込みが止まることがあります。特に管理された仮想環境では、既定のポリシーが厳しめに設定されがちです。
現在の ExecutionPolicy を確認する
Get-ExecutionPolicy -ListRestricted や AllSigned が強く効いている場合、まずは影響範囲を限定して緩めます。
セッション（Process）だけ Bypass にする
Set-ExecutionPolicy Bypass -Scope Process -Forceこの方法は「今開いている PowerShell だけ」に適用されるため、恒久設定を避けたい場合に便利です。
ユーザー単位で RemoteSigned にする（必要な場合）
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -Forceまた、ブラウザ経由で落としたファイルは Windows が「インターネット由来」と見なしてブロック情報（Zone.Identifier）を付与することがあります。手動インストールを行う場合は、nupkg や展開したフォルダ内のファイルも含めてブロック解除を意識してください。
# 展開したモジュール配下をまとめて解除する例（フォルダ配下に対して）
Get-ChildItem "C:\Users\<ユーザー名>\Documents\WindowsPowerShell\Modules\d365fo.tools" -Recurse -File |
Unblock-Filed365fo.tools を手動インストールする：オンラインが不安定な環境で最も確実
Install-Module がどうしても通らない場合、d365fo.tools 自体もオフライン（手動）で配置するのが最短ルートです。ポイントは「正しいフォルダ構成」と「モジュールパスに置く」ことです。
手動導入の流れ
- PowerShell Gallery から
d365fo.toolsの nupkg をダウンロードする - nupkg をブロック解除して解凍する
d365fo.toolsフォルダ（モジュール本体）を取り出す$env:PSModulePathに含まれる配置先へコピーする（推奨：CurrentUser）Import-Moduleとコマンド実行で動作確認する
モジュールパスを確認する
$env:PSModulePath -split ';'代表的には以下が候補です。
C:\Program Files\WindowsPowerShell\Modules\C:\Users\<ユーザー名>\Documents\WindowsPowerShell\Modules\
読み込み確認（ここが通れば「使える状態」）
Import-Module d365fo.tools
Get-D365Moduleさらに、どのコマンドが利用できるか確認するには次が便利です。
Get-Command -Module d365fo.tools | Select-Object -First 30この時点でエラーが出る場合は、ほぼ以下のどれかです。
- 依存モジュール（
PSFrameworkなど）が見つからない - フォルダ構成が崩れている（モジュール直下に
.psd1がないなど） - ExecutionPolicy / ブロックで読み込めない
NuGet Provider が自動で取得できない場合の回避策（手動配置）
環境によっては、Microsoft.PackageManagement.NuGetProvider の取得が最初の壁になります。自動導入が失敗する場合、DLL を直接配置して回避する方法が知られています。
一般的な流れは次のとおりです。
onegetcdn.azureedge.net/providers/配下から NuGet Provider の DLL を取得する- DLL を「ブロック解除」する
C:\Program Files\PackageManagement\ProviderAssembliesにコピーする- PowerShell を再起動し、
Install-Moduleを再実行する
ただし、DLL の手動配置は運用ポリシー（配布元の正当性、ハッシュ確認、監査要件）に影響します。組織ルールがある場合は、社内の手順（承認済みの配布物、社内レポジトリ経由の配布）を優先してください。
うまくいかないときのネットワーク／プロキシ／証明書チェックリスト
「ブラウザはOK」でも PowerShell が失敗する最大要因は、プロキシや証明書です。特に企業ネットワークや管理された仮想環境では、HTTPS の中身を検査する仕組み（SSLインスペクション）が入っていることがあり、PowerShell 側がうまく追随できない場合があります。
WinHTTP のプロキシ設定を確認する
netsh winhttp show proxyWinHTTP にプロキシが設定されていない一方で、ブラウザ（WinINET）は自動構成でプロキシを使っている、という差があると PowerShell だけ外に出られません。必要に応じて WinHTTP にも設定を反映します（環境のルールに従って実施してください）。
# 例：IE/Edge のプロキシ設定を WinHTTP に取り込む（許可されている場合のみ）
netsh winhttp import proxy source=ie通信先を許可できているか確認する（代表例）
PowerShell Gallery の利用では、複数のドメイン／CDN が絡みます。ネットワーク制限がある場合は、次のような宛先がブロックされていないか確認してください（環境で差があります）。
| 用途 | 代表的な宛先 | メモ |
|---|---|---|
| パッケージ情報 | www.powershellgallery.com | ブラウザで見える部分 |
| 実体ダウンロード（CDN） | *.azureedge.net | ブラウザで見えても PowerShell が落とせない原因になりやすい |
| NuGet 関連 | *.nuget.org | 依存解決で参照される可能性 |
| Provider 配布 | onegetcdn.azureedge.net | NuGet Provider の取得経路 |
「PowerShell だけ失敗」を減らす実践的アプローチ
- Scope を CurrentUser に寄せる：管理者権限・書き込み失敗を回避できます。
- 依存モジュールを先に入れる：
PSFrameworkを先に通すと全体が安定します。 - オフライン導入を標準手段として用意する：VDI/Dev Box は環境差が大きいため、手動配置手順を決めておくと再現性が上がります。
- TLS と証明書を疑う：途中で切れる、サイズの大きいファイルだけ落とせない、などは TLS/検査が絡むことがあります。
最後の仕上げ：d365fo.tools を「使える」状態にする確認ポイント
インストール作業が終わったら、次の観点で確認すると安心です。「インストールできた」だけではなく、「読み込める」「コマンドが動く」まで確認します。
モジュールが認識されているか
Get-Module -ListAvailable d365fo.tools
Get-Module -ListAvailable PSFrameworkImport できるか
Import-Module d365fo.tools -Force主要コマンドが列挙できるか
Get-Command -Module d365fo.tools | Measure-Objectここまで問題なく通れば、少なくとも「PowerShell のモジュールとして正常に機能する前提」は整っています。D365FO の作業はここから先、接続先環境の権限・パス・ツールチェーンに依存するため、まずはモジュール導入の不安定さを取り除くのが最優先です。
再発防止：Azure Dev Box / 仮想マシンで詰まりにくくする運用のコツ
一度直しても、Dev Box の再作成やポリシー変更で再発することがあります。次のような運用にしておくと、将来的な手戻りが減ります。
| 施策 | 狙い | 具体例 |
|---|---|---|
| CurrentUser スコープを標準にする | 管理者権限依存を減らす | Install-Module ... -Scope CurrentUser |
| 依存モジュールを先に固定 | 依存解決の揺れを減らす | PSFramework を先に導入し、Import テストまで実施 |
| オフライン手順を整備 | ネットワーク制約の影響を最小化 | nupkg を所定の社内共有に置き、ブロック解除手順もセット化 |
| プロキシ差分を潰す | ブラウザと PowerShell の通信差を解消 | WinHTTP の設定確認、必要なら取り込み |
| TLS/証明書を標準化 | 環境差で落ちないようにする | TLS 1.2 明示、社内CAの配布確認 |
まとめ：失敗箇所ごとに「最短の一手」を選ぶ
同じ Install-Module 失敗でも、詰まっている箇所で打ち手が変わります。最後に、実務で使いやすい形に整理します。
| 詰まっているポイント | 最短の対処 | 補足 |
|---|---|---|
PSFramework のダウンロード失敗 | PSFramework を先に -Scope CurrentUser で導入／手動配置 | 依存解決が通れば d365fo.tools 側は進みやすい |
| NuGet Provider の取得失敗 | Install-PackageProvider NuGet／手動 DLL 配置 | 組織のルール（配布物の承認）に注意 |
| インストール後の Import 失敗 | Set-ExecutionPolicy -Scope Process Bypass＋Unblock-File | 「ダウンロードしたもの」はブロックされやすい |
| 管理者権限がなく書き込みできない | AllUsers ではなく CurrentUser に入れる | Dev Box ではこのルートが安定 |
| ブラウザだけOKで PowerShell が外に出ない | WinHTTP プロキシ確認（netsh winhttp） | ブラウザと PowerShell の設定差を疑う |
d365fo.tools を使えるようにする最短ルートは、「PSFramework を確実に導入」し、「ExecutionPolicy とブロック解除」まで含めて整え、必要なら「オフライン手動配置」に切り替えることです。Azure Dev Box のような管理環境では、オンラインインストールに固執せず、再現性の高い手順を持つことが結果的に一番早い解決につながります。
コメント