「.NET Framework 3.5をインストールしようとしたら、またISOをマウントする羽目になった…」そんな経験はないでしょうか。WSUS（Windows Server Update Services）で端末を管理している環境では、インターネット経由での.NET 3.5インストールが失敗するケースが頻繁に発生します。特にActive Directory（AD）を持たない中小規模の環境では、解決策を調べても「GPOで設定する」という情報ばかりで、自分たちの環境に合った手順がなかなか見つからないものです。
この記事では、ADなしのWSUS環境において、PowerShellスクリプト1本で.NET Framework 3.5を50台のWindows 11端末へ一括インストールする方法を解説します。なぜWSUSが邪魔をするのかという仕組みの理解から、具体的なスクリプトコード、リモート実行の手順、実行後の確認方法まで、実務で使えるレベルで丁寧にまとめています。ISOのsxsフォルダを毎回マウントする作業から卒業したい方は、ぜひ最後まで読み進めてください。
なぜWSUS環境で.NET Framework 3.5のインストールが失敗するのか
UseWUServerレジストリが引き起こす通信ブロックの仕組み
.NET Framework 3.5は、Windowsのオプション機能として提供されており、インストール時にMicrosoft Updateへアクセスして必要なファイルを取得する仕組みになっています。しかしWSUSを使って端末管理をしている環境では、レジストリの設定によってWindows Updateの通信先がWSUSサーバーに固定されています。
具体的には、HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU 配下にある UseWUServer という値が 1 に設定されている場合、WindowsはMicrosoft Updateへ直接アクセスせず、すべての更新リクエストをWSUSサーバーへ向けます。.NET Framework 3.5のインストールに必要なコンポーネントはWSUSのカタログに含まれていないか、同期されていないケースがほとんどのため、結果としてインストールが失敗してしまいます。エラーメッセージとしては「0x800F0906」や「0x800F081F」が表示されることが多く、原因がWSUSにあると気づくまでに時間がかかるケースも少なくありません。
このエラーコードについてはMicrosoftも公式ドキュメントで原因を明記しており、「WSUSサーバーを使用するよう構成されているコンピューターでは、オプション機能の取得先がWSUSに向けられるため、.NET 3.5のインストールに失敗する」と案内しています。詳細は公式ページ「.NET Framework 3.5 インストール エラー – Microsoft Learn」をご参照ください。
ISOのsxsフォルダを使う方法が非効率な3つの理由
WSUSが原因と判明した後、多くの現場で採用されているのが「Windows 11のISOイメージをマウントして、sxsフォルダを指定してインストールする」という方法です。確かにこの方法は確実に動作しますが、50台規模の展開を考えると以下の点で非効率です。
まず、作業が1台ずつの手動対応になりがちという点が挙げられます。ISOのマウントとDISMコマンドの実行を各端末で行う場合、スクリプト化しても端末ごとにISOファイルへのパス解決や共有フォルダへのアクセス権の確認が必要になり、手間が増えます。次に、ISOイメージのバージョン管理が必要になるという点です。Windows 11はサービスチャネルの更新が頻繁なため、古いISOのsxsを使うとバージョン不一致によるエラーが発生する場合があります。最後に、共有フォルダやストレージの容量を消費し続けるという運用コストも見逃せません。インターネット経由でMicrosoft Updateから直接取得できれば、これらの問題はすべて回避できます。
【前提確認】ADなしWSUS環境で一括配布するための事前準備
PowerShellリモーティング（WinRM）の有効化手順
PowerShellのリモート実行機能（PSRemoting）を使うためには、対象の全端末でWinRM（Windows Remote Management）サービスを有効化しておく必要があります。管理PCから各端末へSSH的に接続してコマンドを実行するイメージです。
対象端末で管理者権限のPowerShellを開き、以下のコマンドを実行します。
Enable-PSRemoting -Force
Microsoft公式のコマンドレットリファレンスによると、Enable-PSRemoting を実行するとWinRMサービスの起動・スタートアップの自動化・ファイアウォール受信規則の追加・セッション構成の有効化までが一括で実行されます。手動でWinRM設定を構成する場合と比べ、このコマンド1つで必要な設定が完結する点が大きなメリットです。
ADがない環境では、管理PCと対象PCが同じワークグループにある場合、TrustedHostsの設定も必要になることがあります。その場合は以下のコマンドで管理PC側に対象端末を信頼済みホストとして登録してください。
# 管理PCで実行（全台を対象にする場合は * を指定）
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "192.168.1.*" -Force
なお、Microsoftのセキュリティに関する公式ドキュメントでは、ドメイン参加環境ではKerberos認証が使用されるのに対し、ワークグループ環境ではNTLM認証が使用されるため、TrustedHostsに登録した接続先の「なりすまし検証」ができない点を注意喚起しています。本手順は社内LAN内の信頼できるサブネットへの適用に限定し、外部ネットワークや公衆回線へ開放しないよう注意してください。
IPアドレス範囲やコンピュータ名のリストで指定することも可能です。50台規模であれば、サブネット指定（例：192.168.1.*）が最も効率的です。
ファイアウォール設定とTCP 5985の穴あけ確認方法
PSRemotingはHTTPの場合TCP 5985番ポートを使用します。Enable-PSRemoting を実行すれば自動的にWindowsファイアウォールの受信規則が追加されますが、セキュリティソフトや別途設定されたファイアウォールポリシーがある場合は手動での許可が必要なケースもあります。
接続確認は管理PCから以下のコマンドで行えます。
Test-NetConnection -ComputerName "対象PCのIPアドレス" -Port 5985
TcpTestSucceeded : True が返ってくれば問題ありません。False の場合は対象PC側のファイアウォール設定を確認してください。
プロキシ環境の場合に追加で必要なWinHTTP設定
社内にプロキシサーバーが存在する環境では、Enable-WindowsOptionalFeature によるMicrosoft Updateへのアクセスが、WinHTTPプロキシ設定を経由します。ブラウザのプロキシ設定とは別管理のため、意外と見落とされがちなポイントです。
WinHTTPのプロキシ設定は以下のコマンドで確認・設定できます。
# 現在の設定確認
netsh winhttp show proxy
# プロキシを設定する場合
netsh winhttp set proxy proxy-server="http://proxy.example.com:8080"
# ブラウザ（WinINet）の設定をWinHTTPに引き継ぐ場合
netsh winhttp import proxy source=ie
プロキシが不要な環境であればこの手順はスキップして問題ありません。
WSUS一時無効化スクリプトで.NET 3.5を50台に一括インストールする手順
スクリプトの全コードと各処理の解説
このスクリプトの基本的な流れは「WSUSを一時的に無効化 → .NET 3.5をインターネット経由でインストール → WSUSの設定を元に戻す」という3ステップです。シンプルですが、wuauserv（Windows Updateサービス）の再起動を挟むことで、レジストリの変更をOSに即時反映させる点がポイントです。
# NET35_Install.ps1
# 管理者権限で実行してください
$wsusKey = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"
# 現在のUseWUServer値を退避
$useWUServer = (Get-ItemProperty -Path $wsusKey -Name "UseWUServer" -ErrorAction SilentlyContinue).UseWUServer
Write-Host "[$env:COMPUTERNAME] WSUSを一時無効化中..."
Set-ItemProperty -Path $wsusKey -Name "UseWUServer" -Value 0
# wuauservを再起動してレジストリ変更を即時反映
Restart-Service wuauserv -Force
Start-Sleep -Seconds 5
Write-Host "[$env:COMPUTERNAME] .NET Framework 3.5 をインストール中..."
try {
Enable-WindowsOptionalFeature -Online -FeatureName "NetFx3" -All -NoRestart -ErrorAction Stop
Write-Host "[$env:COMPUTERNAME] インストール完了"
} catch {
Write-Warning "[$env:COMPUTERNAME] インストール失敗: $_"
}
# WSUS設定を復元
Write-Host "[$env:COMPUTERNAME] WSUS設定を復元中..."
$restoreValue = if ($null -ne $useWUServer) { $useWUServer } else { 1 }
Set-ItemProperty -Path $wsusKey -Name "UseWUServer" -Value $restoreValue
Restart-Service wuauserv -Force
Write-Host "[$env:COMPUTERNAME] 完了。UseWUServer = $restoreValue に復元しました。"
各処理の意図を補足します。UseWUServer の現在値を $useWUServer に退避しているのは、環境によって値が異なる可能性を考慮したためです。インストール後に $useWUServer がnullだった場合は安全のために 1（WSUS有効）を設定します。また Start-Sleep -Seconds 5 はサービス再起動後の安定待ちです。端末のスペックによっては秒数を延ばした方が安定する場合があります。
Invoke-Commandで50台に一括リモート実行する方法
管理PCからスクリプトを配布・実行するには Invoke-Command を使います。対象PC名またはIPアドレスをリストにして一括処理する流れです。
# computers.txt に対象PC名またはIPを1行1台で記載しておく
$computers = Get-Content "C:\admin\computers.txt"
$cred = Get-Credential # 管理者アカウントの認証情報を入力
$session = New-PSSession -ComputerName $computers -Credential $cred -ErrorAction Continue
# セッションが確立できた端末に対してスクリプトを実行
Invoke-Command -Session $session -FilePath "C:\admin\NET35_Install.ps1"
# 完了後にセッションを閉じる
Remove-PSSession $session
New-PSSession に -ErrorAction Continue を指定することで、一部の端末でセッション確立に失敗した場合でも処理が中断されず、残りの端末へのセッション確立を継続します。実行後はどの端末で成功・失敗したかを $session オブジェクトで確認できます。
タスクスケジューラ＋共有フォルダを使った代替配布方法
PSRemotingの構成が難しい場合や、端末ごとにログインユーザーが異なる環境では、タスクスケジューラを利用する方法も有効です。スクリプトファイルをネットワーク共有フォルダ（例：\\fileserver\scripts\NET35_Install.ps1）に配置し、各端末のタスクスケジューラで「1回だけ実行」するタスクを登録します。
タスクスケジューラへの登録自体もPowerShellからリモートで行うことができますが、最もシンプルな方法はログオンスクリプトや既存の資産管理ツールと組み合わせて初回ログイン時に実行させることです。50台規模であれば、数日以内に全台でスクリプトが自動実行される運用を組むことが現実的です。
実行後の確認とWSUS設定が正しく復元されているかのチェック方法
.NET 3.5インストール成功の確認コマンド
スクリプト実行後、.NET Framework 3.5が正常にインストールされているかを確認するには、以下のコマンドを使います。
Get-WindowsOptionalFeature -Online -FeatureName "NetFx3"
出力の State が Enabled になっていれば成功です。Disabled のままの場合はスクリプトのログを確認し、インストール中にエラーが発生していなかったかを確認してください。50台分を一括確認する場合も Invoke-Command を組み合わせることで一度に状態確認が可能です。
WSUS復元確認とwuauserv再起動の検証
インストール後にWSUSの設定が正しく復元されているかも必ず確認しましょう。確認コマンドは以下の通りです。
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "UseWUServer"
UseWUServer の値が 1 に戻っていれば正常です。合わせて、wuauserv が正常に動作しているかも確認します。
Get-Service wuauserv | Select-Object Name, Status, StartType
Status が Running、StartType が Automatic であれば問題ありません。WSUS設定の復元漏れがあると、以降のWindowsアップデートが正常に当たらなくなるリスクがあるため、50台すべての確認を推奨します。
WSUS×PowerShell一括管理でよくある失敗パターンと対処法
PSSessionが繋がらない時の原因チェックリスト
一括実行の最大の障壁は、PSSessionの接続失敗です。よくある原因と確認方法を整理します。
WinRMが有効になっていない場合は、対象端末で Get-Service WinRM を実行して Status を確認してください。Stopped であれば Start-Service WinRM で起動し、Enable-PSRemoting -Force を再実行します。TrustedHostsが未設定の場合は、管理PC側で Get-Item WSMan:\localhost\Client\TrustedHosts を確認し、対象端末のIPやホスト名が含まれているかを確認してください。ファイアウォールがTCP 5985をブロックしている場合は、前述の Test-NetConnection で疎通確認を行い、必要であれば受信規則を手動追加します。また、ユーザーアカウント制御（UAC）の影響でリモートから管理者権限が取得できないケースもあります。ローカル管理者アカウントでの接続が前提であるため、ドメインではなくローカルアカウントのフルパス（.\Administrator形式）で認証情報を指定してください。
wuauservの再起動を忘れた場合に起きる症状
スクリプト内で UseWUServer を変更した後に wuauserv を再起動しないと、レジストリの変更がWindowsに認識されません。この状態で Enable-WindowsOptionalFeature を実行しても、内部的にはWSUSへのアクセスが継続されるため、インストールが失敗します。「レジストリを変更したはずなのに失敗する」という場合は、まずwuauservの再起動が行われているかを確認してください。再起動には通常数秒かかるため、Start-Sleep による待機処理も合わせて入れることを推奨します。環境によっては5秒では不十分なケースもあるため、10秒程度に延ばすと安定性が向上します。
まとめ：ISOマウント地獄から卒業するためのチェックリスト
この記事で解説した手順を振り返ります。
- [ ]
UseWUServerレジストリがWSUSブロックの原因であることを理解する - [ ] 対象50台でPSRemoting（WinRM）を有効化する
- [ ] ファイアウォールでTCP 5985の受信を許可する
- [ ] プロキシ環境の場合はWinHTTPプロキシを設定する
- [ ]
NET35_Install.ps1を管理PCに配置する - [ ]
Invoke-Commandで50台に一括リモート実行する - [ ]
Get-WindowsOptionalFeatureでインストール成功を確認する - [ ]
UseWUServerが1に復元されていることを確認する
今回紹介したスクリプトの構造（WSUS無効化 → 処理実行 → WSUS復元）は、.NET 3.5だけでなく、他のWindowsオプション機能のインストールや、Windows Updateを一時的にバイパスして行いたい任意の操作全般に応用できます。ぜひスクリプトをベースとしてカスタマイズし、日々の運用効率化に役立ててください。
ADなし環境でのPowerShell一括管理についてさらに深く知りたい方は、関連記事「ADなし環境でPowerShell一括管理を始めるための完全入門ガイド」もあわせてご覧ください。
コメント