Windowsで「Windows の機能の有効化または無効化」から.NET Framework 3.5（NetFx3）を追加しようとすると、最後にエラー 0x80072EE2 で止まることがあります。Defenderを停止しても、ネット接続があっても改善しない場合は、取得元を切り替えて“確実にソースを渡す”のが近道です。
.NET Framework 3.5（NetFx3）とは何か：なぜ今でも必要なのか
.NET Framework 3.5 は、古い業務アプリや社内ツール、古いドライバー設定ユーティリティなどで今でも要求されることがある「Windows 標準のランタイム」です。.NET Framework 4.x（4.8/4.8.1 など）とは別系統で、Windows 10/11 でも “標準搭載＝すぐ使える” ではなく、必要になった時点で追加（有効化）するオプション機能として扱われます。
この「オプション機能」であることが、今回の 0x80072EE2 の根っこです。GUI で有効化する操作は一見シンプルですが、内部ではNetFx3 のソース（機能ファイル）をどこから取得するかという問題があり、ネットワーク環境や更新コンポーネントの不整合で失敗しやすくなります。
症状：Windows の機能から .NET Framework 3.5 を入れようとして 0x80072EE2 で失敗する
よくある状況は次のとおりです。
- 「Windows の機能の有効化または無効化」から .NET Framework 3.5（.NET 2.0 と 3.0 を含む） をチェックして適用
- 進捗が 100% 近くまで進む／長時間待たされる
- 最後に エラーコード 0x80072EE2 で失敗し、.NET 3.5 が有効化されない
- Microsoft Defender（AV）を一時停止しても改善しない
- インターネット接続がある環境でも改善しない（社内プロキシ、VPN、WSUS 配下など）
- オフラインインストーラーを試しても同様に失敗する
エラー 0x80072EE2 の意味：タイムアウトで “取りに行けていない” サイン
0x80072EE2 は、ざっくり言うと通信のタイムアウトです。Windows Update（またはその代理となる WSUS、プロキシ）経由でコンテンツを取得しようとした結果、時間内に必要なデータを取れず失敗しているパターンが多く見られます。
| 観点 | 内容 | 現場で多い原因例 |
|---|---|---|
| エラーの性質 | 通信・取得のタイムアウト | 回線は生きていても、プロキシや検査装置で遅延／遮断されている |
| 発生箇所 | NetFx3 のソース取得（Windows Update/WSUS 等） | WSUS が「オプション機能のコンテンツ」を配信していない／到達できない |
| 再現条件 | GUI で追加、または “オンライン取得が必要” な状況 | VPN 常時接続、セキュリティゲートウェイ、社内 DNS などが絡む |
結論：NetFx3 のソースを “取りに行く” のではなく “渡す” と通りやすい
Defender を止めても改善しない、ネット接続があっても改善しない…というケースでは、セキュリティソフトというより取得元（Windows Update/WSUS/プロキシ）側の問題であることが多いです。そこで効果的なのが、Windows インストールメディア（ISO/USB/DVD）内の X:\sources\sxs をソースとして DISM に明示する方法です。
この方法なら、Windows Update を見に行かずにローカルのファイルから有効化できるため、0x80072EE2（タイムアウト）系の失敗を避けられます。
対応の優先順位：おすすめの進め方（迷ったらこの順）
| 優先 | やること | 狙い | 所要感 |
|---|---|---|---|
| 1 | Windows Update のトラブルシューティング | 更新コンポーネントの不整合を自動修復 | 短い |
| 2 | ISO/メディアをソースに DISM で NetFx3 を有効化 | オンライン取得を回避して確実に入れる（本命） | 中 |
| 3 | Windows Update キャッシュ（SoftwareDistribution）を整理 | ダウンロード破損やキャッシュ詰まりの解消 | 中 |
| 4 | 企業ネットワーク（WSUS/プロキシ/ポリシー）を点検 | 環境要因を潰して再発防止 | 状況次第 |
手順：Windows Update のトラブルシューティングを実行する
まずは Windows Update の整合性が崩れていないかを自動修復で確認します。GUI で完結するため、影響が少なく先に試す価値があります。
- 設定を開く
- （Windows 10 の場合）「更新とセキュリティ」→「トラブルシューティング」→「追加のトラブルシューティング ツール」→「Windows Update」
- （Windows 11 の場合）「システム」→「トラブルシューティング」→「その他のトラブルシューティング ツール」→「Windows Update」
- 画面の案内に従って実行し、修復後に再起動
ここで直れば最短です。ただし 0x80072EE2 は「取りに行けない」系が多いため、改善しない場合は次の DISM 手順へ進むのが現実的です。
本命：インストールメディアをソースにして DISM で .NET Framework 3.5 を有効化する
この方法のポイントは次の 2 つです。
- ISO/USB/DVD の
X:\sources\sxsにある NetFx3 ソースを使う - /LimitAccess を付けて Windows Update を見に行かせない
準備：ISO（または USB/DVD）を用意し、ドライブとしてマウントする
Microsoft 公式の Windows インストールメディア（ISO）を用意し、エクスプローラーで右クリックして「マウント」します。マウントできない場合は、USB/DVD でも構いません。
- マウント後は「D:」や「E:」などのドライブ文字が割り当てられます（環境により異なります）。
- エクスプローラーで X:\sources\sxs が存在することを確認します（X は実際のドライブ文字）。
実行：管理者のコマンドプロンプトで DISM を実行
管理者権限のコマンドプロンプト（または Windows Terminal）を開き、次のコマンドを実行します。
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:X:\sources\sxs実行前に押さえるべきポイントを表にまとめます。
| 項目 | 意味 | 重要ポイント |
|---|---|---|
| /Online | 今起動している Windows を対象にする | オフラインイメージではなく “現PCに入れる” 場合に使用 |
| /Enable-Feature | オプション機能を有効化する | GUI の「Windows の機能」と同じ目的 |
| /FeatureName:NetFx3 | .NET Framework 3.5 の機能名 | NetFx3 が正しい指定 |
| /All | 依存関係もまとめて有効化 | 不足が原因で失敗するのを防ぐ |
| /LimitAccess | Windows Update を参照しない | 0x80072EE2 対策の核心。必ず付ける |
| /Source:X:\sources\sxs | ローカルのソースパス | ドライブ文字 X を実環境に合わせる |
成功の確認：有効化されているかをチェック
DISM が正常終了したら、次のどれかで状態を確認できます。
- 「Windows の機能の有効化または無効化」で .NET Framework 3.5 にチェックが入っているか確認
- コマンドで確認（DISM）
DISM /Online /Get-Features /Format:Table | findstr /i NetFx3State が Enabled になっていれば有効化できています。アプリ側が再起動を要求することもあるので、必要に応じて Windows も再起動してください。
失敗しがちなポイント：ここでつまずくと “別のエラー” に変わる
0x80072EE2 ではなく、別のエラーに変わるケースもあります。これは “前進” で、通信タイムアウトからソース不一致やパス違いに論点が移ったサインです。
| よく出るエラー | 意味・原因の方向性 | まず確認すること |
|---|---|---|
| 0x800f081f | ソースが見つからない／不一致 | X:\sources\sxs が存在するか、Windows の世代・言語・ビルドが合っているか |
| 0x800f0906 | ソースのダウンロードに失敗（オンライン） | /LimitAccess を付けたか、ソースを指定したか |
| 0x800f0922 | 更新適用に失敗／予約領域不足など | 空き容量、保護されたシステム領域、更新の状態を確認 |
特に重要なのが、インストールメディアの “同系統” を使う点です。Windows 10 用 ISO で Windows 11 に当てる、言語が違う、エディションやビルド差が大きい…といった場合は不一致で失敗しやすくなります。可能なら、対象 PC と同じ世代・同じ言語のメディアを使ってください。
チェック：本当に X:\sources\sxs を指定できているか
地味ですが、ドライブ文字の間違いが最も多いです。まずはフォルダが見えているかを確認します。
dir X:\sources\sxsファイル一覧が出ればパスは正しい可能性が高いです。出ない場合は、ドライブ文字が違う／ISO をマウントできていない／メディアが別物のいずれかです。
参考：Windows Update のキャッシュを削除してやり直す（同じエラーになりがちだが試す価値はある）
提示されることが多い定番手順が、Windows Update のキャッシュ（SoftwareDistribution）を整理する方法です。今回のような 0x80072EE2（タイムアウト）では根本解決にならないこともありますが、更新コンポーネントが詰まっているケースでは効くことがあります。
管理者のコマンドプロンプトで、次を順に実行します（実行中の更新がある場合は中断されるので、作業前に再起動しておくと安全です）。
net stop wuauserv
net stop bits
net stop cryptsvc
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start cryptsvc
net start bits
net start wuauservその後、再起動してから .NET Framework 3.5 の有効化を再実行します。結果が変わらない場合は、やはりローカルソース指定（DISM）の方が確実です。
企業ネットワーク（WSUS/プロキシ）で詰まりやすい理由と、現場で効く確認ポイント
社内 PC では、Windows Update のアクセスがそのままインターネットに出ていないことが普通です。代表例が次の 3 つです。
- WSUS（社内更新サーバー）：更新は通るが、オプション機能のコンテンツが配信されていない／未同期
- プロキシ：認証が必要、または SSL 検査で遅延し、タイムアウトになりやすい
- VPN：トンネル経由の遅延、分岐（スプリットトンネル）設定で更新だけ不安定
このような環境では「ネットはつながっているのに取れない」が起きます。そこで、切り分けに役立つコマンドをまとめます。
| 確認項目 | コマンド例 | 見たいポイント |
|---|---|---|
| WinHTTP プロキシ設定 | netsh winhttp show proxy | 意図しないプロキシが入っていないか |
| インターネット疎通 | ping -n 1 www.microsoft.com | DNS/経路が異常ではないか（ICMP が遮断されている環境では参考程度） |
| 更新サービスの状態 | sc query wuauserv | RUNNING になっているか |
とはいえ、ネットワーク要因の調査は時間がかかりがちです。短時間で復旧が必要なら、まずは DISM の /LimitAccess + /Source が最優先です。ネットワークやポリシーの是正は、復旧後に落ち着いて進める方が現実的です。
それでもうまくいかない場合：追加の切り分けとログの見方
DISM のソース指定でも失敗する場合は、次の観点で切り分けると原因に近づけます。
1) 対象 Windows とメディアの整合性を確認する
まずは OS のバージョンを確認します。コマンドで確認するなら以下が手早いです。
winver
systeminfo | findstr /i "OS 名 OS バージョン"同じ世代・同じ言語の ISO を使っているか、改めて確認してください。特に社内で配布されるカスタムイメージ（不要コンポーネント削減済み）だと、sxs の内容が欠けている場合があります。
2) DISM と CBS のログを確認する
エラーの手掛かりはログに残ります。次のパスをメモ帳で開き、最後の方（新しい時刻）を確認します。
C:\Windows\Logs\DISM\DISM.logC:\Windows\Logs\CBS\CBS.log
ログの中で “source” “NetFx3” “0x” などを検索すると、ソースの場所や失敗理由が見つかることがあります。
3) GUI ではなく PowerShell で明示的に指定する（操作ミスを減らす）
PowerShell で同じことを行うと、パラメータが見やすくなります。管理者 PowerShell で次を実行します（X はメディアのドライブ）。
Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source "X:\sources\sxs" -LimitAccessよくある質問
Q. 「オフラインインストーラー」でも失敗するのはなぜ？
一般に “オフラインインストーラー” と呼ばれるものでも、実態としてはWindows のオプション機能（Feature on Demand）に紐づくコンテンツを OS が取りに行く動きが残っている場合があります。確実に回避したいなら、DISM に X:\sources\sxs をソースとして渡すのが安定です。
Q. Defender（AV）を止めても直らないのはなぜ？
0x80072EE2 の多くは通信（Windows Update/WSUS/プロキシ）側のタイムアウトが原因です。AV 側のブロックであれば別のエラーになったり、ログに痕跡が出たりすることが多く、Defender 停止で改善しない場合は “取得元” を疑うのが合理的です。
Q. 会社PCで管理者権限がない場合はどうすればいい？
.NET Framework 3.5 の有効化はシステム機能の追加なので、通常は管理者権限が必要です。IT 管理者に依頼する際は、次の情報を伝えると話が早くなります。
- エラーコード：0x80072EE2
- 実施したこと：GUI での有効化、トラブルシューティング、DISM（/LimitAccess + /Source）
- 使用したメディア：OS と同系統の ISO/USB、X:\sources\sxs の存在確認
- 社内環境：WSUS/プロキシ/VPN の有無
まとめ：0x80072EE2 は “NetFx3 のソース取得に失敗している” 可能性が高い
Windows で .NET Framework 3.5 の追加が 0x80072EE2 で失敗する場合、原因の本命はNetFx3 のコンポーネントを取得できていない（タイムアウトしている）ことです。まずは Windows Update のトラブルシューティングで整合性を直し、それでもダメならインストールメディアをソースにした DISM（/LimitAccess + /Source）で、Windows Update への依存を断つのが最短ルートです。
同じ症状でも環境要因（WSUS/プロキシ/VPN）で発生しやすさは変わります。復旧後は、再発しないよう更新経路やポリシーも見直しておくと、別の “オプション機能の追加” でも詰まりにくくなります。
コメント