WSUS（Windows Server Update Services）は非推奨で、Microsoftは新機能を追加していません。ただし、サポート対象のWindows Server上での本番展開は引き続きサポートされ、製品ライフサイクルに従うセキュリティ／品質更新も受けます。したがって既存環境を直ちに停止する必要はありませんが、2026年に新規構築するなら「承認をオンプレミスで制御する必要」「切断ネットワーク」「帯域制御」などWSUS固有の要件と、保守負担を比較してから採用します。
新規案件では、Windowsクライアントのクラウド管理、Azure／ArcサーバーのAzure Update Manager、Configuration Managerなども比較します。WSUSが無料の役割だからという理由だけで選びません。
新規展開の判断基準
- WSUSが適する：Microsoft Updateへ直接出せない端末、内部承認が必須、上流／下流構成、切断域、ローカル配信でWAN帯域を抑えたい。
- 再検討する：インターネット接続クライアント中心でIntune等を利用、複数OSを一元管理、柔軟な保守時間、動的スコープ、詳細な準拠・アラートが必要。
- Azure Update Managerの候補：Azure VMやAzure Arc接続サーバーをWindows／Linux横断で評価・スケジュール・監視したい。
- WSUS継続条件：SUSDB、IIS、コンテンツ、同期、クリーンアップ、証明書、容量、障害復旧を運用する担当と時間を確保できる。
WSUSはWindows Server 2016／2019／2022／2025のサポート対象役割を使います。導入前に管理対象OS、台数、拠点、製品、言語、必要分類、月間容量、パイロット群、停止可能時間、上流、プロキシを設計します。既にConfiguration ManagerのSoftware Update Pointがある場合は単独WSUSの手順を混ぜません。
1. 役割、DB、コンテンツ先を決める
小～中規模ではWindows Internal Database（WID）とWSUS Servicesが基本候補です。リモートSQLを選ぶ場合はMicrosoftのサポート条件、DB接続保護、バックアップ担当を確認します。SUSDBはメタデータと構成、WSUSContentは更新ファイルであり、どちらか片方だけでは復旧できません。OSドライブの空きだけで決めず、対象製品と言語、UUP、保持中コンテンツの増加を見積もります。
GUIではServer Manager→Add roles and features→Role-based or feature-based installation→Windows Server Update Servicesを選び、WSUS ServicesとWID ConnectivityまたはSQL Server Connectivity、管理ツールを選びます。PowerShellでWID構成を入れる例は次です。
Install-WindowsFeature -Name UpdateServices -IncludeManagementTools
Get-WindowsFeature -Name UpdateServices*
役割導入後、管理コンソールを開く前にpost-installation taskを完了し、専用ボリュームのコンテンツ先を指定します。例のD:をそのまま使わず、容量、バックアップ、ウイルス対策、権限を承認した実パスへ置き換えます。
& "$env:ProgramFiles\Update Services\Tools\WsusUtil.exe" postinstall CONTENT_DIR=D:\WSUS
Get-Service WsusService
2. ポートとTLSを正確に設計する
最上位WSUSがMicrosoft Updateから同期する通信はHTTP 80／HTTPS 443です。クライアントおよび下流WSUSから上流WSUSへの既定ポートはHTTP 8530／HTTPS 8531です。Microsoft公式構成では、8531のTLSで更新メタデータを保護し、署名済み更新ペイロードは8530のHTTPを使う設計があるため、WSUS Webサイト全体へ単純にRequire SSLを設定しません。
証明書のSANにクライアントが使う短縮名／FQDNを含め、信頼チェーンと有効期限を管理します。wsusutil configuressl wsus.contoso.example とIISバインド、クライアントGPOのURLを同じ名前へ合わせます。SQLを別サーバーに置く場合、WSUSとSQL間がTLSで自動保護される前提にせず、同一の保護ネットワークやIPsec等を検討します。
3. 初期構成を最小範囲で行う
- WSUS Administration ConsoleのOptions→Update Source and Proxy Serverで、Microsoft Updateまたは承認済み上流WSUSを選ぶ。
- プロキシが必要なら専用資格情報を設定し、基本認証でパスワードが平文送信される選択肢はネットワーク要件を確認する。
- Productsは実際に保有するWindows／Microsoft製品だけを選ぶ。将来用に全製品を選ばない。
- ClassificationsはまずSecurity Updates、Critical Updates、Updatesなど必要最小限にし、Upgrades、Drivers、Feature Packs、Definition Updatesは運用要件ごとに追加する。
- Languagesは管理対象端末の実言語へ限定する。Express installation filesやUUPの容量影響を計画資料で確認する。
- 同期を手動で一回実行し、成功、所要時間、取得分類、ディスク増加、プロキシ／TLSエラーを確認してから定期同期を設定する。
初回同期は対象によって長時間かかります。コンソールが応答しないからと再インストールせず、Synchronization Results、イベント、WsusService、IIS WsusPool、SUSDB、空き容量を確認します。Products／Classificationsを後で増やした場合は、新しいメタデータの同期後に承認対象を再評価します。
4. コンピューターグループと承認リング
少なくとも「Pilot」「Broad」「Critical Servers」など、業務影響と保守時間でグループを分けます。サーバーと一般PCを同じ自動承認へ入れません。パイロットには代表的なOS、言語、VPN、印刷、業務アプリ、ドライバー構成を含めます。
- 同期後に更新のKB、置換、再起動、Known Issues、対象製品を確認する。
- まずPilotだけへInstall承認し、検出、ダウンロード、インストール、再起動、業務回帰を確認する。
- 合格基準を満たした更新だけをBroadへ承認する。サーバーは役割別保守時間と復旧手順を承認してから展開する。
- 失敗、Not Applicable、Needed、Installed/Not Applicable、未報告端末を区別し、台数の分母を固定して準拠率を確認する。
- 期限設定は強制再起動を伴い得るため、緊急対応の承認と利用者通知なしに使わない。
5. クライアントポリシーを設定して確認する
ドメインGPOでは「Specify intranet Microsoft update service location」に同じWSUS URLを二欄とも設定します。TLSを構成した例なら https://wsus.contoso.example:8531 です。クライアント側ターゲティングを使うならグループ名をWSUS側と完全一致させ、最初はパイロットOU／セキュリティグループへだけリンクします。Dual ScanやWindows Update for Businessポリシーとの競合も棚卸しします。
gpresult /h C:\GpReports\wsus-policy.html /f
Get-ItemProperty HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate
Get-ItemProperty HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate\AU
確認する値はWUServer、WUStatusServer、UseWUServer、TargetGroup等です。次にクライアントがWSUSへ登録・報告し、Pilotグループに入り、承認済み更新を検出できることをコンソールとWindows Updateログで照合します。GPOが見えるだけ、サーバー名が名前解決できるだけでは完了ではありません。
同期、承認、パイロットの完了条件
- 同期結果がSuccessで、選択した製品・分類・言語だけが取得される。
- 8531の証明書検証と8530のコンテンツ取得がパイロット端末から成功する。
- 代表端末が24時間以内など定義済みSLAで報告し、最終接続時刻が更新される。
- 一つの承認済み更新を検出、ダウンロード、インストール、必要な再起動まで完了できる。
- VPN、BitLocker、印刷、認証、業務アプリ、クラスタ／サーバー役割の回帰試験が合格する。
- 非対象端末がPilotへ混入せず、Broadへの自動波及がない。
バックアップと保守
SUSDBをWID／SQLに適したアプリケーション整合方式でバックアップし、WSUSContent、IISバインド、TLS証明書と秘密鍵、postinstallのコンテンツパス、GPO、上流／下流、Products、Classifications、言語、コンピューターグループ、承認ルールを同じ復旧台帳へ保存します。DBだけ戻してコンテンツが別世代、またはその逆にならないよう復元手順を試します。
定期的にSUSDBバックアップ、インデックス／再インデックス、置換済み更新の評価、Server Cleanup Wizard、古い端末、同期失敗、空き容量を保守します。WSUSContentをExplorerで任意削除せず、WSUSの管理機能と検証済み手順を使います。WSUSサーバー自体のOS、IIS、DBも更新対象です。
安全なロールバックと撤去
誤承認が判明したら、まず対象グループの承認をNot Approvedへ戻して新規展開を止めます。既にインストール済みの更新はWSUSの承認を戻してもアンインストールされません。該当KBの削除可否、Known Issue Rollback、修正版、システム／アプリの復旧手順を確認し、影響端末だけを変更管理下で戻します。
クライアント構成に問題がある場合は、パイロットGPOを以前のWSUS URLまたは承認済みのWindows Update管理方式へ戻し、gpresult、レジストリ、検出元、準拠報告を再確認します。WSUS役割を先に削除しません。全端末が代替経路で更新を取得し、SUSDB／WSUSContentのバックアップと保持期限が承認されてから、Server Managerで役割を撤去し、8530／8531、証明書、サービスアカウント、DNSを順に閉じます。
公式情報・参考資料
コメント