【Windows Server入門 第6回】更新プログラムとの戦い。WSUS構築とWindows Updateの完全制御（非推奨化の衝撃を超えて）

「朝起きたら、サーバーが勝手に再起動していました…」

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、WSL2とWindows Terminalを使ったハイブリッド開発環境について解説しました。
これでWindows上でも快適にLinuxコマンドが打てるようになりましたね。

さて、今回はWindows運用における「ラスボス」とも言える存在、「Windows Update」との戦いです。
Linuxエンジニアにとって、yum update や apt upgrade は「自分が決めたタイミングで実行するもの」ですよね。
しかし、Windowsは違います。「OSが勝手にダウンロードし、勝手に再起動する」のです。

本記事では、WSUSの仕組みと構築手順、グループポリシー（GPO）による再起動の完全制御、そして「非推奨化」を受けて我々がどう動くべきかのロードマップを徹底解説します。

---

第1章：Windows Updateの悪夢とWSUSの役割

なぜ企業では、個々のPCが勝手にWindows Updateをしてはいけないのでしょうか？

3つの課題

1. ネットワーク帯域の枯渇: 毎月第2水曜日（パッチチューズデー）の朝、数百台のPCが一斉に数GBのデータをダウンロードし始めると、社内LANもインターネット回線もパンクします。
2. バージョンの不整合: AさんのPCは最新、BさんのPCは古いまま。これでは「特定のバージョンでしか動かない業務アプリ」の動作保証ができません。
3. 勝手な再起動: 業務中や夜間のバッチ処理中に勝手に再起動され、データが飛ぶ事故が発生します。

WSUS（Windows Server Update Services）の仕組み

WSUSは、社内LANに設置する「中継サーバー」です。

1. WSUSサーバーだけが、Microsoftから更新プログラムをダウンロードします。
2. 管理者が「このパッチは適用してよし（承認）」と判断したものだけを配布対象にします。
3. 社内のPC（クライアント）は、インターネットではなく、社内のWSUSサーバーを見に行きます。

これにより、インターネット回線の負荷は「サーバー1台分」で済み、適用のタイミングや対象も完全にコントロールできるようになります。

---

第2章：【重要】WSUSは「非推奨（Deprecated）」になりました

構築を始める前に、残酷な現実をお伝えしなければなりません。
2024年9月、MicrosoftはWSUSの非推奨化を発表しました。

どういうことか？

• 今すぐ使えなくなるわけではない: Windows Server 2025でもWSUS機能は搭載されていますし、既存のWSUSも動き続けます。
• 新機能は追加されない: 今後、新しい機能が開発されることはありません。
• クラウドへの移行を推奨: Microsoftは、IntuneやWindows Autopatch、Azure Update Managerへの移行を強く促しています。

じゃあ、もうWSUSは覚える必要ない？

いいえ、まだ必要です。以下のケースでは、WSUSが「唯一の解」であり続けます。

• 閉域網（インターネットに繋がらない環境）: 工場の制御PCや、高セキュリティエリアのサーバーは、クラウド管理ツール（Intuneなど）を使えません。
• コストの問題: Intuneなどのクラウド管理はユーザー課金（サブスクリプション）ですが、WSUSはWindows Serverのライセンスに含まれており、追加費用ゼロです。

つまり、「クラウドに行ける企業はクラウドへ、行けない企業はWSUSを塩漬け運用」というのが現在のフェーズです。
今回は、依然として需要の高い「オンプレミス環境」のために、WSUS構築を解説します。

---

第3章：実践！WSUSサーバーの構築

それでは、WSUSを構築していきましょう。
ディスク容量は最低でも500GB、できれば1TB以上用意してください（パッチは肥大化する一方です）。

手順1：役割のインストール（PowerShell）

GUIの「役割と機能の追加」でもできますが、PowerShellなら一発です。
データベースには、標準のWID（Windows Internal Database）を使用します。

Install-WindowsFeature -Name UpdateServices -IncludeManagementTools

インストール後、コンテンツの保存先ディレクトリを作成します。

New-Item -Path "D:\WSUS" -ItemType Directory
& "C:\Program Files\Update Services\Tools\wsusutil.exe" postinstall CONTENT_DIR=D:\WSUS

手順2：初期設定ウィザード

「サーバーマネージャー」→「ツール」→「Windows Server Update Services」を開くと、ウィザードが始まります。

1. アップストリームサーバー: 「Microsoft Updateから同期する」を選択。
2. プロキシサーバー: 環境に合わせて設定。
3. 接続の開始: ここで一度Microsoftに接続し、製品リストを取得します（数分かかります）。
4. 言語: 「英語」と「日本語」だけを選択（全言語選ぶとディスクが死にます）。
5. 製品: 必要なOS（Windows 10/11, Server 2019/2022など）とOfficeなどを選択。「ドライバ」は絶対に選ばないでください（数が膨大すぎてWSUSが壊れます）。
6. クラス: 「セキュリティ問題の修正プログラム」「重要な更新」などを選択。
7. スケジュール: 深夜（AM 2:00など）に自動同期するように設定。

手順3：IISのチューニング（重要）

WSUSの実体はIIS上のWebアプリです。
デフォルト設定ではメモリ不足で頻繁に落ちるため、第4回で学んだ「アプリケーションプール」の設定を変更します。

1. IISマネージャーを開く。
2. 「アプリケーションプール」→「WsusPool」を右クリック→「詳細設定」。
3. プライベートメモリの制限(KB): 1843200 (約1.8GB) → 0 (無制限) に変更。
   ※サーバーの物理メモリが少ない場合は、4GB(4000000)程度に制限してください。
4. キューの長さ: 1000 → 2000 に増やす。

これをやらないと、クライアントが一斉にアクセスした瞬間にWSUSが「Service Unavailable (503)」を返して死にます。

---

第4章：GPOによるクライアント制御。「勝手に再起動」を封じる

WSUSを立てただけでは、クライアントは気づいてくれません。
Active Directoryのグループポリシー（GPO）を使って、「更新はWSUSを見に行け」「勝手に再起動するな」と命令します。

GPOの設定箇所

グループポリシー管理エディタを開き、以下のパスを辿ります。
コンピューターの構成 > ポリシー > 管理用テンプレート > Windows コンポーネント > Windows Update

必須設定1：イントラネットのMicrosoft更新サービスの場所を指定する

ここでWSUSサーバーのURLを指定します。

• 更新を検出するためのイントラネットの更新サービスを設定する: http://wsus-server:8530
• イントラネット統計サーバーの設定: http://wsus-server:8530

必須設定2：自動更新を構成する

ここが運用の要です。いくつかのモードがあります。

• 2 – ダウンロードとインストールを通知: 勝手には何もしない。ユーザーが手動でボタンを押す必要がある。サーバー向け。
• 3 – 自動ダウンロードしインストールを通知: ダウンロードまでは勝手にやる。インストールはユーザー任せ。
• 4 – 自動ダウンロードしインストール日時を指定: クライアントPC向け。指定した時間（例: 毎日12:00）に勝手にインストールする。

必須設定3：アクティブ時間内の更新の自動再起動をオフにする

これを有効にし、業務時間（例: 8:00〜18:00）をアクティブ時間として指定すれば、その間は絶対に勝手な再起動は起きません。
（ただし、アクティブ時間外には再起動されます）

---

第5章：WSUS運用の闇。DB肥大化との戦い

WSUSを運用し始めると、半年後くらいに必ずトラブルが起きます。
「WSUSコンソールが開かない」「同期が終わらない」「クライアントがエラーを吐く」。
原因は、WSUSデータベース（SUSDB）の肥大化とインデックス断片化です。
WSUSは「ほったらかし運用」ができないシステムなのです。

やってはいけない運用

• 全ての更新プログラムを「自動承認」にする: ディスクがすぐに埋まります。
• 不要になった更新プログラム（Itanium用など）を放置する: DBが重くなります。
• 「クリーンアップウィザード」を実行しない: 自殺行為です。

プロのメンテナンス術（PowerShell）

WSUSには「サーバークリーンアップウィザード」という機能がありますが、GUIから実行するとタイムアウトして落ちることがあります。
PowerShellを使って、タスクスケジューラで定期実行するのが正解です。

# WSUSクリーンアップスクリプト例
$wsus = Get-WsusServer
$cleanupScope = New-Object Microsoft.UpdateServices.Administration.CleanupScope
$cleanupScope.DeclineSupersededUpdates = $true # 置き換えられた更新を拒否
$cleanupScope.DeclineExpiredUpdates    = $true # 期限切れを拒否
$cleanupScope.CleanupObsoleteUpdates   = $true # 不要な更新を削除
$cleanupScope.CompressUpdates          = $true # 圧縮
$cleanupScope.CleanupObsoleteComputers = $true # 長期間接続のないPCを削除
$cleanupScope.CleanupUnneededContentFiles = $true # 不要なファイルを削除

$wsus.GetSubscription().GetCleanupManager().PerformCleanup($cleanupScope)

さらに、WID（内蔵DB）のインデックス再構築も必要です。
Microsoftが公開しているSQLスクリプト（WsusDBMaintenance.sql）を sqlcmd で月1回実行するように仕込みましょう。

---

第6章：クラウド時代の更新管理への移行

WSUSが非推奨となった今、インターネットに接続できる環境であれば、クラウド管理への移行を検討すべきです。

1. Windows Update for Business (WUfB)

これは「ツール」ではなく「ポリシー」です。
「機能更新プログラムを何日遅らせるか」「品質更新プログラムをいつ適用するか」といったポリシーをGPOやIntuneから適用し、実際のパッチダウンロードは各PCが直接Microsoft Updateから行います。
サーバー不要で無料ですが、詳細な承認制御（このパッチだけ止めたい）は苦手です。

2. Microsoft Intune

PCやスマホをクラウドから管理するMDMツールです。
WUfBのポリシーをクラウドから配布でき、適用状況のレポートもWebブラウザで見られます。
テレワーク環境のPC管理には最適です。

3. Azure Update Manager

サーバー管理の次世代本命です。
Azure上のVMだけでなく、オンプレミスのサーバー（Azure Arc対応サーバー）も一元管理できます。
パッチ適用のスケジュール実行や、適用状況の可視化が可能です。

4. 配信の最適化 (Delivery Optimization)

「クラウド管理にすると、また全員がインターネットからダウンロードして回線がパンクするのでは？」
その対策がこれです。
社内のPC同士がP2P（ピア・ツー・ピア）でパッチを融通し合う機能です。
1人がダウンロードすれば、隣の席の人はその人のPCからパッチをもらうため、インターネット回線の負荷を劇的に下げることができます。

---

まとめ：WSUSは「延命」しつつ、未来へ備えよ

お疲れ様でした！
第6回は、WSUSの構築と、激動するWindows更新管理の未来について解説しました。

今回の重要ポイント：

• WSUSは非推奨になったが、閉域網やコスト重視の現場ではまだ現役。
• GPOで「アクティブ時間」を設定し、業務中の再起動を防ぐ。
• WSUSはメンテナンスフリーではない。クリーンアップとDBメンテを自動化せよ。
• インターネットに出れるなら、IntuneやAzure Update Managerへの移行を計画する。

更新プログラムを当てても、原因不明の不調になることはあります。
そんな時、Linuxなら /var/log/messages を見ますが、Windowsではどうすればいいのでしょうか？

次回、第7回は「トラブルシューティングとイベントビューア。grepできないログをどう読むか」です。
バイナリ形式のログ「イベントビューア」の効率的なフィルタリング方法、パフォーマンスモニターによる負荷解析、そして「ブルースクリーン（BSOD）」の解析手法まで、トラブルシューティングの奥義を伝授します。お楽しみに！