企業のドメイン環境で、.NET Framework 3.5 だけがどうしても WSUS から入らない…という相談はとても多いです。本記事では、なぜ WSUS 単独では配布できないのかを整理し、オンライン／オフライン環境別に、安全かつ再現性高く .NET 3.5 を展開する手順と運用のコツをまとめます。
.NET Framework 3.5 を WSUS で配布したいときによくある状況
まず、よくある前提条件と問題のパターンを整理しておきます。どれか一つでも当てはまる場合は、本記事の対象になります。
- クライアント PC はすべて Active Directory ドメインに参加している
- Windows Update の配布元は WSUS（または MECM/SCCM 経由の WSUS）に統一されている
- 特定の業務アプリケーションが .NET Framework 3.5（2.0／3.0 を含む） を必須としている
- 「Windows の機能の有効化」や「役割と機能の追加」から .NET 3.5 を有効化しようとすると、WSUS へリダイレクトされてインストールに失敗する
管理者としては、次のように考えるのが自然です。
- .NET Framework 4.x の累積更新やその他のパッチは WSUS に承認して配布できている
- であれば、.NET Framework 3.5 も「更新プログラム」として WSUS に取り込んで承認し、他のパッチと同じ要領で一括展開したい
しかし結論から言うと、.NET Framework 3.5 のバイナリそのものを WSUS だけで配布することはできません。
結論：WSUS 単独では .NET Framework 3.5 を配布できない
この問題の本質は、.NET Framework 3.5 が「オンデマンド機能 (Feature on Demand, FOD)」として扱われている点にあります。
通常の更新プログラム（品質更新プログラム、累積更新、セキュリティ更新など）は、WSUS が参照する更新カタログに公開されています。そのため、管理者は WSUS で該当パッチを同期・承認し、クライアントへ配布できます。
一方、.NET Framework 3.5 本体は、次のような扱いになっています。
- OS に「機能」として組み込まれているが、デフォルトでは無効
- 必要になったタイミングで「オンデマンド」でソースを取得して有効化する
- このオンデマンド用バイナリは、通常の WSUS カタログには含まれない
その結果、クライアントが .NET 3.5 を有効化しようとしたとき、次のような流れになります。
- クライアントが「Windows の機能の有効化」や DISM を通じて .NET 3.5 を有効化しようとする
- バイナリを取得しようとするが、グループポリシーで「Windows Update の管理サーバー＝WSUS」が設定されている
- オンデマンド機能のソースを WSUS 側から取得しようとするが、WSUS は .NET 3.5 のインストールソースを持っていない
- 結果としてエラーになり、インストールに失敗する
つまり、WSUS には「.NET Framework 3.5 を新規インストールするためのファイル」を配布する仕組みがないため、他のパッチと同じように「同期して承認する」というアプローチは取れません。
ここまでをまとめると、以下のようになります。
| 項目 | 通常の更新プログラム | .NET Framework 3.5 本体 |
|---|---|---|
| 分類 | 更新プログラム（Quality Update / Security Update） | オンデマンド機能 (Feature on Demand) |
| WSUS カタログへの掲載 | あり（同期・承認可能） | なし（新規インストール用バイナリは載らない） |
| WSUS だけで完結できるか | 可能 | 不可能（別ソースが必須） |
| 導入後のセキュリティ更新 | WSUS から配布可能 | 導入さえできれば WSUS で配布可能 |
重要なのは、「導入さえできればその後の更新は WSUS で配布できる」という点です。そのため、最初のインストールだけは「WSUS 以外のソース」を使う設計に切り替える必要があります。
環境別：.NET Framework 3.5 の現実的な導入パターン
ここからは、ネットワーク環境別におすすめの導入パターンを整理します。大枠としては次の 3 パターンに分かれます。
| 環境 | おすすめ手順 | ポイント |
|---|---|---|
| インターネット接続あり | GPO で「WSUS ではなく Windows Update からオンデマンド機能を取得」+ PowerShell / DISM | Microsoft Update から直接取得。追加の共有フォルダ不要 |
| 完全オフライン | インストールメディアの \sources\sxs を共有配置し、DISM / PowerShell で有効化 | ビルド・言語が OS と一致するソースが必須 |
| 大規模一括展開 | 上記コマンドを GPO 起動スクリプトや MECM/Intune などで配布 | .NET 3.5 のバイナリは WSUS ではなく、共有フォルダ等から取得 |
インターネット接続あり：GPO + Add-WindowsCapability
クライアントがインターネットへ直接、もしくはプロキシ経由でアクセスできる環境であれば、最もシンプルで管理コストが低い方法です。
グループポリシーの設定
対象のクライアントに適用される GPO で、次のポリシーを有効にします。
- コンピューターの構成 > 管理用テンプレート > システム > オプション コンポーネントのインストールとコンポーネント修復の設定を指定
このポリシーを [有効] にした上で、次のようなオプションを有効化します。
- 「修復コンテンツおよびオプション コンポーネントを、Windows Server Update Services (WSUS) ではなく Windows Update から直接ダウンロードする」 にチェック
これにより、オンデマンド機能に限り、WSUS を経由せず Microsoft Update（インターネット側）から直接ファイルを取得できるようになります。通常の更新プログラムは引き続き WSUS 経由で配布されるため、パッチ管理ポリシーを崩さずに運用できます。
PowerShell から .NET 3.5 を有効化する
GPO の反映後、管理者権限の PowerShell で次のコマンドを実行します。
Add-WindowsCapability -Online -Name NetFX3~~~~
サーバー OS の場合（Windows Server 2012 / 2012 R2 / 2016 など）や、GUI ではなくコマンドで統一したい場合は、DISM コマンドでも構いません。
DISM /Online /Add-Capability /CapabilityName:NetFX3~~~~
インターネット接続環境でこの方式を取るメリットは次のとおりです。
- 別途
\sources\sxsを管理する共有フォルダを用意しなくてよい - OS のビルドや言語の違いをあまり意識しなくてよい（Microsoft 側が適切なパッケージを返してくれる）
- 将来的に OS がアップグレードされた場合でも、基本的には同じポリシーとコマンドで対応可能
逆に、セキュリティポリシー上「クライアントからインターネットへの直接通信は一切禁止」という環境では、この方式は採用できません。その場合は次で紹介する「完全オフライン」の手順に進みます。
完全オフライン環境：インストールメディアの \sources\sxs を使用
金融機関や制御系ネットワークなど、クライアントがインターネットに一切出られない環境では、インストールメディアから .NET 3.5 のソースを取得し、社内共有フォルダなどに配置して利用する方法が基本になります。
準備：インストールメディアからソースを抽出
まず、OS と同じビルド・エディション・言語のインストール ISO を用意します。以下は一般的な流れです。
- 管理用端末で該当 OS の ISO ファイルをマウントする
- マウントされたドライブの
\sources\sxsフォルダを確認する - そのまま、ファイルサーバー上の共有フォルダ（例：
\\fileserver\WinSrc\Win10_22H2_JP\sxs）へコピーする
このとき重要なのが、次の 2 点です。
- OS のビルド（例：21H2, 22H2 など）と ISO のビルドを合わせる
- OS の言語と ISO の言語を合わせる
どちらかが異なると、インストール時に 0x800F081F などのエラーが発生しやすくなります。
| チェック項目 | 一致させるべき内容 | 一致しない場合の代表的な症状 |
|---|---|---|
| OS ビルド | Windows 10/11 なら 21H2 / 22H2 など | 0x800F081F エラー、インストール途中でロールバック |
| OS の言語 | ja-JP などの表示言語 | 構成ファイルが見つからないエラー |
| エディション | Pro / Enterprise / Server Standard など | まれに機能一覧が合わないことがある |
クライアントで DISM から有効化
ソースを配置したら、クライアント側で次のように実行します。
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:\\fileserver\WinSrc\Win10_22H2_JP\sxs
主なオプションの意味は以下の通りです。
| オプション | 意味 |
|---|---|
/Online | 現在起動中の OS（オンラインイメージ）を対象にする |
/Enable-Feature | 指定された Windows 機能を有効化する |
/FeatureName:NetFx3 | .NET Framework 3.5 を指す機能名 |
/All | .NET 2.0 / 3.0 を含む関連機能もまとめて有効化 |
/LimitAccess | Windows Update など外部ソースへのアクセスを禁止 |
/Source:… | \sources\sxs を格納した共有フォルダなどを指定 |
PowerShell をメインで使っている環境であれば、次のコマンドでも同様のことが可能です。
Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source \\fileserver\WinSrc\Win10_22H2_JP\sxs -LimitAccess
Server Core 環境（GUI のない Windows Server）の場合は、次のようなコマンドもよく使用されます。
Install-WindowsFeature Net-Framework-Core -Source \\fileserver\WinSrc\WS2019_JP\sxs
この方式を採用するときのポイントは、「ソースフォルダの管理と命名ルールをしっかり決める」ことです。
- 例：
\\fileserver\WinSrc\<OS名>\<ビルド>\<言語>\sxs - ISO からコピーした日付や、元となった ISO ファイル名を README で残す
- 今後 OS の大型アップデート（例：21H2 → 22H2）を行ったときの更新手順もあらかじめ決めておく
多数のクライアントに一括展開したい場合のアプローチ
台数が数十台程度であれば、管理者が手動で DISM や PowerShell を実行しても現実的ですが、数百～数千台規模になると自動化は必須です。そこでよく使われるパターンが次の 3 つです。
| 手段 | 概要 | 向いている環境 |
|---|---|---|
| GPO 起動スクリプト | コンピューターの起動時にバッチ / PowerShell スクリプトを実行し、DISM で NetFx3 を有効化 | AD ドメインがあり、スタートアップスクリプト運用に慣れている環境 |
| MECM / SCCM | パッケージまたはタスクシーケンスとして .NET 3.5 有効化スクリプトを配布 | すでに MECM/SCCM でアプリ配布や OS 展開を行っている環境 |
| Intune / MDM | スクリプト配布機能や Win32 アプリとして、DISM/PowerShell をラップして配布 | クラウドベースの管理を採用している環境 |
いずれの方法でも、基本的な考え方は同じです。
- WSUS は「更新プログラムの配布」に専念させる
- .NET Framework 3.5 の「インストールソース」は共有フォルダやインターネットから取得させる
- インストールの実行トリガーだけを GPO / MECM / Intune などの管理ツールで制御する
例えば、GPO 起動スクリプトを使う場合のイメージは次のようになります。
@echo off
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:\\fileserver\WinSrc\Win10_22H2_JP\sxs
exit /b 0
これを共有フォルダに置き、GPO の「コンピューターの構成 > ポリシー > Windows の設定 > スクリプト（スタートアップ）」に登録することで、対象 OU のクライアント起動時に自動的に .NET 3.5 が有効化されます。
インストール時によくあるエラーとチェックポイント
.NET Framework 3.5 の導入で特に多いトラブルと、そのチェックポイントをまとめます。エラーコードそのものは覚えなくても構いませんが、「どこを疑えばよいか」の型を持っておくと、トラブルシュートが格段に楽になります。
0x800F081F：ソースの不一致・不足
最もよく報告されるエラーが 0x800F081F です。多くの場合、次のいずれかが原因です。
- OS のビルドと
\sources\sxsのビルドが一致していない - OS の言語と ISO の言語が異なる
- 共有フォルダのパスやアクセス権に問題があり、クライアントからソースフォルダへアクセスできていない
チェックの観点を表にまとめると次のようになります。
| 確認すべきポイント | 具体的な確認方法 | 問題があった場合の対処例 |
|---|---|---|
| ビルドの一致 | クライアントで winver または systeminfo を確認、ISO のラベルと見比べる | OS と同じビルドの ISO を入手し直し、その \sources\sxs を使用 |
| 言語の一致 | 表示言語・システムロケールを確認し、ISO の言語と比較 | OS の言語に合った ISO を再取得 |
| ネットワーク経路 | クライアントから共有フォルダにアクセスできるか、UNC パスでテスト | アクセス権（読み取り権限）や FW 設定を見直す |
インターネット接続環境なのに失敗する場合
インターネット接続があるはずの環境で、GPO を設定しても .NET 3.5 のインストールに失敗する場合、次のような要因が考えられます。
- プロキシサーバー経由の通信で認証が必要だが、システムコンテキストで認証できていない
- ファイアウォールや URL フィルタで Microsoft Update への通信がブロックされている
- GPO を誤った OU にリンクしており、対象クライアントに適用されていない
この場合は、まず gpresult /h や「結果セットポリシー」を用いて、該当の GPO が本当に適用されているか確認するところから着手するのがよいでしょう。その上で、プロキシ認証の仕組みや、必要 URL の許可状況をネットワーク担当とすり合わせます。
Server Core での注意点
Server Core は GUI がないため、管理者はすべてコマンドベースで操作することになります。基本的には前述の DISM か Install-WindowsFeature を利用しますが、次のような点に注意が必要です。
- Server Core のバージョンと、インストールメディア（ISO）のバージョンを厳密に合わせる
- OS 展開イメージから展開されたサーバーの場合、その WIM イメージに .NET 3.5 を事前統合する設計も検討する
- リモートから PowerShell セッションを張り、ソースパスの指定ミスがないか慎重に確認する
.NET 3.5 導入後は WSUS だけで更新管理できる
ここまで読むと、「では、.NET Framework 3.5 を入れてしまうのはセキュリティ的に不安だ」と感じる方もいるかもしれません。しかし、一度 .NET 3.5 を有効化してしまえば、その後のセキュリティ更新プログラムは通常の更新プログラムとして WSUS から配布可能です。
つまり、運用上のポイントは次のように整理できます。
- 初回インストール：WSUS ではなく、インターネットまたは
\sources\sxsをソースとして使用する - 以降の更新：WSUS に同期された .NET 3.5 用セキュリティ更新プログラムを承認・配布する
なお、.NET Framework 4.x 系は通常の更新プログラムとして扱われるため、WSUS から直接配布・インストールできます。あくまで「3.5 系（2.0 / 3.0 を含む）がオンデマンド機能として特別扱いされている」と理解すると整理しやすいでしょう。
運用設計のベストプラクティス
.NET Framework 3.5 の導入方法を単発で決めるだけでなく、今後の運用を見据えて「ルール」として設計しておくと、トラブルや属人化を防げます。ここでは、実務でよく採用されるベストプラクティスをいくつか紹介します。
標準ソースパスと命名ルールを決める
インストールメディアから抽出した \sources\sxs をばらばらに配置してしまうと、どのフォルダがどの OS/ビルド向けなのかが分からなくなり、運用が破綻します。次のようなルールを決めるのがおすすめです。
- 共有フォルダのトップを固定する（例：
\\fileserver\WinSrc） - 配下に OS 名、ビルド、言語を表すフォルダを分ける
\\fileserver\WinSrc\
├─ Win10\
│ ├─ 21H2_JP\sxs
│ └─ 22H2_JP\sxs
├─ Win11\
│ └─ 23H2_JP\sxs
└─ WS2019\
└─ RTM_JP\sxs
さらに、それぞれのフォルダに以下のような情報を README などで残しておくと、後任への引き継ぎもスムーズです。
- 元となった ISO ファイル名
- 作成日・作成者
- 想定している OS バージョン（例：Windows 10 Enterprise 22H2 日本語版）
OS 展開イメージへの事前統合も検討する
新規 PC 展開時に毎回 .NET 3.5 を後付けで有効化している場合、OS 展開イメージ（WIM）にあらかじめ .NET 3.5 を統合してしまうのも一案です。これにより、初期展開時点で .NET 3.5 が有効になった状態で配布でき、後工程の作業が大幅に軽減されます。
ただし、.NET 3.5 を標準で有効にすることで不要な攻撃面が増える可能性もあるため、「本当に全端末で必要なのか」「対象部門を限定できないか」といった観点からセキュリティポリシーと合わせて検討する必要があります。
アプリケーション要件を棚卸しし、対象を限定する
.NET 3.5 が必要なのは、ほとんどの場合「古い業務アプリケーション」です。アプリケーションの棚卸しを行い、次のような情報を整理しておくと、将来の移行計画にも役立ちます。
- どのアプリが .NET 3.5（2.0 / 3.0）を必要としているか
- そのアプリのベンダー・サポート状況・バージョン
- .NET 4.x 対応版や Web アプリ版など、代替が存在するか
- どの部署・どの端末グループで利用されているか
この情報があれば、「この OU に属する PC にだけ .NET 3.5 を有効化する」といった設計が可能になり、全社的に不用意に有効化する必要がなくなります。
セキュリティの観点から押さえておきたいポイント
.NET Framework 3.5 は、古いアプリケーションとの互換性を維持するためにどうしても必要になる一方で、セキュリティの観点からは次のようなリスクがあります。
- .NET 3.5 向けの脆弱性（CVE）が今後も報告される可能性がある
- 旧式の API や暗号化方式を利用するアプリが残ることで、全体としてのセキュリティレベルが下がる可能性がある
したがって、.NET 3.5 を導入する際は次のようなポリシーをセットで検討することをおすすめします。
- .NET 3.5 を有効化する対象 OU やデバイスグループを最小限に絞る
- WSUS 上で .NET 3.5 関連の更新プログラムを確実に同期・承認する運用を徹底する
- 可能な範囲で、アプリケーションを .NET 4.x 以降へ移行する中長期計画を立てる
これらを踏まえれば、「レガシーアプリのためにやむを得ず .NET 3.5 を使う」という状況でも、リスクをコントロールしながら安全に運用できます。
よくある勘違いとアンチパターン
最後に、現場でよく見かける勘違いや避けるべきパターンをいくつか挙げておきます。当てはまるものがあれば、早めに見直しを検討するとよいでしょう。
「WSUS で .NET 3.5 のインストーラを配布すればよい」と考える
.NET Framework 3.5 は、従来の「フルインストーラ（MSI/EXE）」を配布するスタイルではなく、OS の機能として組み込まれています。そのため、WSUS で任意の EXE を配布するようなアプローチは原則取りません。
もしカスタムスクリプトを配布する場合でも、あくまで DISM や PowerShell をラップし、OS に組み込まれている機能を有効化する形にするのが正攻法です。
「とりあえず全社で .NET 3.5 をオンにする」
短期的には楽に見える選択肢ですが、長期的には次のような問題を生みます。
- .NET 3.5 を必要としない端末にも無駄に機能が有効化され、攻撃面が広がる
- どのアプリが .NET 3.5 に依存しているのか分からなくなり、将来の廃止計画が立てづらくなる
できる限り、アプリケーションの依存関係を整理したうえで「必要なところにだけ有効化する」設計を心がけましょう。
「インターネット禁止なのに、何とかして Microsoft Update に出そうとする」
セキュリティポリシーで明確に「インターネット接続禁止」とされているネットワークで、.NET 3.5 導入のためだけに例外ルールを追加するのは、稟議も運用も複雑になりがちです。そのような環境では、最初から \sources\sxs を用いた完全オフライン方式を前提に設計したほうが結果的にシンプルになります。
まとめ：WSUS にこだわらず、「ソースの置き場所」を設計する
本記事のポイントを整理すると、次のようになります。
- .NET Framework 3.5 はオンデマンド機能 (Feature on Demand) のため、WSUS 単独で本体バイナリを配布・承認することはできない
- インターネット接続がある環境では、GPO で「WSUS ではなく Windows Update から直接ダウンロード」を許可し、
Add-WindowsCapabilityや DISM で有効化するのが最もシンプル - 完全オフライン環境では、OS と同じビルド・言語のインストールメディアから
\sources\sxsを共有フォルダへ配置し、/LimitAccess付き DISM / PowerShell で有効化する - 多数のクライアントには、GPO 起動スクリプトや MECM / Intune などの管理ツールを使ってコマンドを一括展開する
- 一度 .NET 3.5 を有効化してしまえば、その後のセキュリティ更新は通常の WSUS パッチとして配布・管理できる
重要なのは、「WSUS に .NET 3.5 のインストーラを入れる」ことを目指すのではなく、「どこにインストールソースを置き、どうやってそこへ到達させるか」を設計することです。この記事をベースに、自社環境のネットワーク構成やセキュリティポリシーに合った導入パターンを検討し、安定した .NET 3.5 運用につなげていただければ幸いです。
コメント