Windows Serverのサーバーの役割の1つであるWindows Server Update Services（WSUS）は、企業内ネットワークでWindows、Windows Server、およびその他のマイクロソフト製品の更新プログラムの管理の一元化と配布の自動化を可能にする、Windowsネットワークにおける重要なインフラストラクチャサービスです。 しかし、WSUSサーバーを長期に運用していると、WSUSの管理コンソールでエラーが発生して管理画面にアクセスできなくなったり、パフォーマンスが低下したり、WSUSのコンテンツの格納先のディスク領域が不足したりといった、さまざまなトラブルを発症することがあります。 特に、WSUS管理コンソールのエラーに関する問題については、マイクロソフトの公式ドキュメントおよびWSUSサポートチームの情報が役に立つでしょう。また、WSUSの安定運用に関するホワイトペーパー『WSUS正常性監視のポイント Windows 10時代の重要インフラWSUS、安定運用の勘所』も参考にしてください。
WSUSメンテナンスガイド
https://docs.microsoft.com/ja-jp/troubleshoot/mem/configmgr/wsus-maintenance-guide
「WSUS 管理コンソールにつながらない！」を解消するための 7 つのワザ（JAPAN SCCM & WSUS Support Team）
https://social.msdn.microsoft.com/Forums/ja-JP/0dc69153-1d4e-4e91-bf91-df311424a8be/wsus-7-?forum=jpsccmwsus
WSUS正常性監視のポイント Windows 10時代の重要インフラWSUS、安定運用の勘所
https://www.say-tech.co.jp/yamaichi/key_point_of_wsus_monitoring
ここでは、WSUSを長期的に安定運用するのに役立つ、一般的な考慮点やメンテナンスタスクの定期実行について説明します。既にパフォーマンスの低下や容量不足に陥っているWSUSサーバーについても、これらの手順を実施することで劇的に改善する可能性があります。
WSUSデータベース（SUSDB）をホストするWindows Internal Database（WID、Windows Server付属のサーバーの機能の1つ）またはSQL Serverのサーバーメモリオプションは、WSUSサーバー全体のパフォーマンスを最適化できる重要な調整ポイントです。
WIDおよびSQL Serverのサーバーメモリオプションは、最小サーバーメモリと最大サーバーメモリがあり、既定値は最小0MB、最大2,147,483,647MB（約2ペタバイト）で、SQL Serverがメモリを動的に自動管理します。最大サーバーメモリを既定から変更していない場合、SQL Serverは最大で、システムやSQL Server以外のアプリケーションに必要なメモリ容量を物理メモリ全体量から差し引いた容量を割り当てます。SQL Serverの負荷が高く、既に利用可能な最大容量を使用している場合、新たに起動するサービスやアプリケーションや、既存のプロセスが追加で要求するリソースを確保できないという状況が発生します。
動的メモリを使用する仮想マシン仮想環境では、最小サーバーメモリをメモリを予約しておく目的で重要です。SUSDBをホストするSQL Serverでは、最小サーバーメモリを1024MBに設定することで安定したという実績があるそうです。
物理サーバーメモリを指定すると、サーバーの物理メモリ容量に余裕がない場合に、システムやSQL Server以外のアプリケーションのためにメモリを予約できます。
最小サーバーメモリおよび最大サーバーメモリは、SQL Server用の管理ツールであるSQL Server Management Studio（SSMS）を使用して簡単に変更できます。SUSDBのホストにWIDを使用している場合は、以下のURLから最新のSSMSをダウンロードしてWSUSサーバーにインストールしてください。
SQL Server Management Studio (SSMS) のダウンロード
https://docs.microsoft.com/ja-jp/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver15
SSMSを起動したらSQL ServerのインスタンスまたはWIDをホストするサーバーのデータベースエンジンに接続します。WIDを使用している場合はサーバー名として以下の名前を入力して接続してください。
¥.¥pipe¥MICROSOFT##WID¥tsql¥query
サーバーに接続したらサーバー名を右クリックして［プロパティ］を選択し、［メモリ］を選択し、［最小サーバーメモリ］および必要に応じて［最大サーバーメモリ］を変更し、［OK］をクリックします（画面1）。設定の変更は即座に反映されます。
画面1 SQL Serverのサーバーのプロパティを開き、［最小サーバーメモリ］および必要に応じて［最大サーバーメモリ］を変更する
WIDを使用している場合、SSMSでデータベースサーバーのプロパティを開くとエラーが発生する場合があります。その場合は［新しいクエリ（New Query）］を開き、次のようなクエリを入力して実行（Execute）し、設定値の変更を確認します（画面2）。次の例は最小サーバーメモリを1024MB（1GB）に変更します。
sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
sp_configure 'min server memory', 1024
GO
RECONFIGURE
GO
EXEC sp_configure 'min server memory'
GO
次の例は最大サーバーメモリを4096MB（4GB）に変更します。
sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
sp_configure 'max server memory', 4096
GO
RECONFIGURE
GO
EXEC sp_configure 'max server memory'
GO
Windows 10バージョン1809およびWindows Server 2019では、累積更新プログラム（Cumulative Updates）と呼ばれる毎月の品質更新プログラムのWindows Updateでの配布方法とパッケージ形式に大きな変更が加えられました。
Windows 10バージョン1803以前の従来の累積更新プログラムは、以前にリリースされたすべての修正プログラムが含まれています。半期チャネル（SAC）ではあまり問題になることはありませんが、複数年にわたって品質更新プログラムが提供される長期サービスチャネル（LTSC）の場合、毎月の累積更新プログラムに累積される以前の修正プログラムが増える影響で、更新プログラムのパッケージサイズが肥大化し続け、ダウンロードのためのネットワーク帯域幅に直接的な影響を与えてしまうことがあります。例えば、Windows Server 2016用の累積更新プログラムは半年ほどで1GBを超え、リリースから4年以上経過した2021年春には1.6GBを超えるまでになっています。
累積更新プログラムのサイズの肥大化に対して、Windows Updateにおけるダウンロード時間とネットワーク帯域幅の圧迫を改善するため、高速インストール（Express Install）または高速ダウンロード（Express Download）という仕組みが利用されてきました。高速インストール／高速ダウンロードでは、フルパッケージ（例：Windows10.0-KBXXXXXXX-x64.cab）をダウンロードする代わりに、カタログを含むExpressパッケージ（例：Windows10.0-KBXXXXXXX-x64_express.cab）がまずダウンロードされ、Expressパッケージの内容に基づいて、更新が必要なものだけを差分でダウンロードするようになっています。
Windows 10バージョン1809およびWindows Server 2019では、Windows Updateでの累積更新プログラムのダウンロードに高速インストール／高速ダウンロードは原則として使用しなくなり、フルパッケージをダウンロードするようになりました（サービススタックの更新プログラムなど一部の更新プログラムについては引き続きExpressパッケージが使用されます）。新しい累積更新プログラムは以前にリリースされたすべての修正プログラムを含むのではなく、前方差分と後方差分を含む形で更新履歴を追跡可能にしています。これにより、フルパッケージのサイズは小さく抑えられ、年月とともに肥大化するということはなくなりました。詳しくは、以下のホワイトペーパーで説明されています。
前方差分と後方差分を使用したWindowsの更新プログラム（Windows Updates using forward and reverse differentials）
https://docs.microsoft.com/ja-jp/windows/deployment/update/psfxwhitepaper
Windows 10バージョン1803以前（Windows Server 2016を含む）のWindows Updateで利用される高速インストール／高速ダウンロードの仕組みは、WSUSでも［高速インストールファイルをダウンロードする］というオプションを有効化することで対応できます。このオプションを有効化した場合、企業内ネットワーク内での高速インストール／高速ダウンロードを提供できますが、WSUSサーバーにMicrosoft Updateからダウンロードされるコンテンツは大幅に増加します。そのため、サーバーへのダウンロード時間が長くなり、WSUSコンテンツのディスク領域をより多く消費するようになります。
もし現在、WSUSで［高速インストールファイルをダウンロードする］オプションを有効にして運用している場合、その必要性を検討してください。企業内ネットワークで稼働中のクライアントやサーバーの、Windows 10バージョン1809およびWindows Server 2019以降への移行が完了し、以前のバージョンのWindows 10やWindows Server 2016が存在しなくなったのであれば、［高速インストールファイルをダウンロードする］オプションを有効にしているメリットはもうありません（画面3、画面4）。
画面3 WSUSに同期された累積更新プログラムのファイル情報の比較。Windows 10バージョン1803以前向けはフルパッケージ（.cab）と高速インストール用（_express.cabおよび.psf）の両方が用意されているが（画面上）、Windows 10バージョン1809以降はフルパッケージ（.cab）の提供のみ
画面4 企業内のWindowsバージョンによっては［高速インストールファイルをダウンロードする］オプションを有効化するメリットはほとんどない
毎月リリースされる更新プログラムおよび数か月ごとにリリースまたは改訂される機能更新プログラムの情報はWSUSデータベース（SUSDB）に蓄積され、承認に基づいてダウンロードされたWSUSコンテンツ（WSUSContent）ディレクトリに格納される更新プログラムの本体はドライブのディスク領域を使用し続けます。
WSUSはデータベースのデータとコンテンツディレクトリからのファイルの削除に関しては自動管理を行いません。そのため、数か月に1回、あるいは毎月（同期完了後）など定期的にメンテナンスを実施することが重要です。それには、［Update Services］（wsus.msc）スナップインの［オプション］から［WSUSサーバークリーンアップウィザード］を開始して、すべてのクリーンアップ対象を選択して実行します（画面5）。
なお、WSUSをダウンストリームサーバーとアップストリームサーバーの多階層構成で展開している場合は、階層の下部から順番にクリーンアップを実施するようにしてください。同じ階層の場合は複数のサーバーで同時にクリーンアップを実行できます。
画面5 WSUSサーバーを安定的に運用するためには、［WSUSサーバークリーンアップウィザード］を定期的に実行してデータベースとコンテンツディレクトリを最適化する
クリーンアップを定期的に実施していれば短時間で終了しますが、そうでない場合はすべての対象をクリーンアップするのに数時間単位の時間を要する場合があります。また、クリーンアップの実行中に複数回、WSUS Serviceサービスが再起動されます。長時間かかる場合、管理コンソールへのアクセスやパフォーマンス、クライアントアクセスに影響する可能性があります。影響を最小限にするためには、クライアントに影響しない業務時間外の日時に、クライアントの更新スケジュールと重複しない形で実施することをお勧めします。
PowerShellのInvoke-WsusServerCleanupコマンドレット（Windows Server 2012以降のWSUSで利用可能）を使用すると、パラメーターで1つ以上のクリーンアップ対象を指定することでコマンドラインからクリーンアップを実施することができます。クリーンアップ対象とパラメーターの対応を表１にまとめました。コマンドラインを記述したPowerShellスクリプト（.ps1）をタスクとして登録（Windowsの運用管理を快適にする10の裏ワザ／表ワザ 『4.タスクスケジューラの使いこなし』を参照してください）することで、毎月1回、あるいは数か月に1回といったサイクルで自動実行することができます。
表１ クリーンアップ対象とInvoke-WsusServerCleanupコマンドレットのパラメーターの対応
| WSUSサーバークリーンアップウィザードでのクリーンアップ対象 | Invoke-WsusServerCleanupのパラメーター |
| 不要な更新プログラムと更新プログラムのリビジョン |
-CompressUpdate -CleanupObsoleteUpdates |
| サーバーにアクセスしていないコンピューター | -CleanupObsoleteComputers |
| 不要な更新ファイル | CleanupUnneededContentFiles |
| 期限の切れた更新プログラム | -DeclineExpiredUpdates |
| 置き換えられた更新プログラム | -Decli#99acc2neSupersededUpdates |
次のWsusmaintenance.ps1は、ホワイトペーパー『WSUS正常性監視のポイント Windows 10時代の重要インフラWSUS、安定運用の勘所』で紹介したサンプルスクリプトです。すべてのクリーンアップ対象にクリーンアップを実行し、実行結果をログファイルにリダイレクトします。
| Wsusmaintenance.ps1 |
|
$starttime = Get-Date -Format "yyyyMMdd-HHmm" $result = (Invoke-WsusServerCleanup -CompressUpdates -CleanupObsoleteUpdates -CleanupObsoleteComputers -CleanupUnneededContentFiles -DeclineExpiredUpdates -DeclineSupersededUpdates) $endtime = Get-Date -Format "-HHmm" $result > C:¥work¥wsusmaintenance_$starttime$endtime.logs |
［WSUSサーバークリーンアップウィザード］と同等、あるいはそれ以上の機能を持つメンテナンスタスクをタスクスケジューラで自動実行することを目的とした有償／無償のツールや製品*4がいくつか存在します。その中で、Samer Sultan氏がGitHubで無償で公開しているWSUS Cleanup PowerShell Scriptを紹介します。
WSUS Cleanup PowerShell Script（GitHub samersultan/wsus-cleanup）
https://github.com/samersultan/wsus-cleanup
*4 筆者は以前、Adam Marshall氏（https://www.adamj.org/）が作成し、無料公開していたClean_WSUS.ps1スクリプト（通称、Adamj Clean-WSUS）をWSUSのメンテナンスに優れたツールとして利用および紹介していましたが、現在、数年前にこのスクリプトの提供は終了しています。Adamj Clean-WSUSは後継のWSUS Automated Mantenanceという有償ツールに置き換えられました。その早期のバージョンであるAdamj Clean-WSUSは使用しないことが推奨されています。
WSUS Cleanup PowerShell Scriptは、［WSUSサーバークリーンアップウィザード］やInvoke-WsusServerCleanupコマンドレットが行うのと同じメンテナンスタスクを、SQL Serverのストアドプロシージャを直接的に実行することで、タイムアウトエラーなどを回避しながらメンテナンスタスクを確実に実行するように作られています。さらに、データベースのインデックスの再構築という追加のデータベースメンテナンスタスクも実施してくれます。しかも、最後にIISとWSUSサービスの再起動は発生するものの、実行中にWSUSへのクライアントアクセスや管理アクセスが制限されることはありません。
このスクリプトはマイクロソフトが提供するものではなく、コミュニティベースのものですが、通常の［WSUSサーバークリーンアップウィザード］がエラーで失敗する場合は、試してみる価値はあります。
使い方は非常に簡単で、ダウンロードしたWSUS-Cleanup.ps1およびWsusDBMaint.sqlを格納したディレクトリから、WSUS-Cleanup.ps1を管理者として実行するだけです（画面6）。タスクスケジューラに登録して（Windowsの運用管理を快適にする10の裏ワザ／表ワザ 『4.タスクスケジューラの使いこなし』を参照してください）、毎月1回、あるいは数か月に1回といったサイクルで自動実行すればよいでしょう。スクリプトの作成者によると、週次または月次での実行を薦めています。
.¥WSUS-Cleanup.ps1 ↲
なお、リモートのSQL Serverインスタンスを使用している場合はWSUS-Clean.ps1の$SqlServerにコンピューター名を設定する必要があります。
データベースのインデックスの再構築のためには、SQLCMDユーティリティが利用可能であることが必要です。WIDを使用している場合は、以下のURLからSQLCMDユーティリティ（本稿執筆時点のバージョンはMicrosoft Commanｄ Utilites 15 for SQL Server）をダウンロードしてWSUSサーバーにインストールしてから実行してください。
sqlcmd ユーティリティ
https://docs.microsoft.com/ja-jp/sql/tools/sqlcmd-utility
SQL Serverを使用している場合、スクリプトの問題によりインデックスの再構築でエラーが発生し、スキップされるかもしれません。筆者が使用したスクリプトのバージョン（Last updated 11-26-2019、Version 4）の場合は、WSUS-Cleanup.ps1のfunction RebuildDBIndexes{} 内のコードを以下のように変更することでローカルのWIDとSQL Serverの両方に対応させることができます。なお、WIDを使用している場合は変更の必要はありません。
| 変更前 | $status = SQLCMD -S ¥¥.¥pipe¥Microsoft##WID¥tsql¥query -i $SQLPath -I |
| 変更後 | if ( $script:SqlServer -match "microsoft##" ){ $status = SQLCMD -S ¥¥.¥pipe¥Microsoft##WID¥tsql¥query -i $SQLPath -I } else { $status = SQLCMD -S $script:SqlServer -i $SQLPath -I } |
WSUSはWindows Server 2016でWindows 10に対応して以降（Windows 10対応はWindows Server 2012/2012 R2 WSUSにも更新プログラムでバックポートされました）、実質、変更されていません。製品の分類でWindows 11を選択するだけで、Windows 11のパッチ管理に対応できます。
ただし、WSUS では、検出したWindows 11クライアントの「オペレーティングシステム」列の情報を「Windows 10」と表示することに注意してください。これは、WSUSがクライアントの
「HKLM¥SOFTWARE¥Microsoft¥Windows NT¥CurrentVersion¥ProductName」レジストリ値から取得した情報を基に、「オペレーティングシステム」列の情報を表示しているからです。これは表示上の問題で、インストール済みのWindows 11向け更新プログラムの状態やインストール対象としてのWindows 11向け更新プログラムの承認には影響しません。
似たような問題に、Windows 10やWindows 11の実際の詳細なビルド番号とWSUSのコンソールで確認できるクライアントの「バージョン」列の情報が一致しないことがあります。WSUSは、ここにWindowsのバージョンではなく、Windows Update Agentコンポーネント（wuaueng.dll）のファイルバージョン情報を表示する仕様だからです。
※本ページは2022年6月22日現在の情報です。
こちらのページの続きを含めた、全10テクニックをまとめたホワイトペーパーをご覧いただけます。以下のフォームよりお申込みください。