Windows Server Update Services のベスト プラクティス
この記事では、WSUS の設計や設定の制限によりパフォーマンスが低下しない構成とするためのヒントを提供します。
元の製品バージョン:構成マネージャー (現在のブランチ)、Windows Server Update Services
元の KB 番号: 4490414
容量の制限
WSUS では、サーバーあたり 100,000 クライアント (Configuration Manager を使用する場合は 150,000 クライアント) をサポートできますが、制限ぎりぎりまで使用することはお勧めしません。
代わりに、同じ SQL Server データベースを共有する 2 台から 4 台のサーバーで構成することを検討してください。 これにより、数の上での安全性を確保できます。 1 台のサーバーがダウンしても、最新のゼロデイ エクスプロイトに対して更新する必要がある間は、どのクライアントも更新できないため、週末がすぐに台無しになることはありません。
データベースを共有するシナリオでは、スキャン ストームも防止できます。
多くのクライアントが WSUS サーバーを変更し、サーバーがデータベースを共有していない場合、スキャン ストームが発生する可能性があります。 WSUS はデータベース内のアクティビティを追跡するため、クライアントが最後にスキャンされてから何が変更されたかを把握し、それ以降に更新されたメタデータのみを送信します。
別のデータベースを使用する別の WSUS サーバーに変更した場合は、クライアントはフル スキャンを実行する必要があります。 フル スキャンを実行すると、大規模なメタデータ転送が発生する可能性があります。 このようなシナリオでは、特に WSUS サーバーが正しく管理されていない場合は、クライアントあたり 1 GB を超える転送が発生する可能性があります。 これにより、クライアントが WSUS インスタンスと通信するときに、エラーを引き起こすほどの負荷を発生させる可能性があります。 そして、この場合、クライアントは何度も再試行します。
データベースの共有とは、クライアントが同じ DB を使用する別の WSUS インスタンスに切り替えた場合、スキャンのペナルティは発生しないことを意味します。 データベースの切り替えによる負荷の増加は、大きなペナルティではありません。
Configuration Manager のクライアント スキャンは、スタンドアロンの自動更新よりも多くの要求を WSUS に課します。 Configuration Manager では、コンプライアンス チェックが含まれるため、拒否された状態を除くすべての更新プログラムを返す条件でスキャンを要求します。
自動更新エージェントでスキャンする場合、またはコントロール パネルで [更新プログラムの確認] を選択した場合、エージェントは、インストールが承認された更新プログラムのみを取得する条件で送信します。 通常、返されるメタデータは、Configuration Manager によってスキャンが開始されたときよりも小さくなります。 更新エージェントはデータをキャッシュし、次のスキャン要求ではクライアント キャッシュからデータを返します。
リサイクルを無効にし、メモリ制限を設定する
WSUS は、データベースから更新プログラムのメタデータを取得する内部キャッシュを実装します。 この操作はコストが高く、非常に多くのメモリが必要になります。 WSUS をホストする IIS アプリケーションのプール (WSUSPool と呼ばれる) が既定のプライベートメモリと仮想メモリの制限を超過すると、WSUSPool がリサイクルされる可能性があります。
プールがリサイクルされると、キャッシュが削除されるので再構築する必要があります。 クライアントが差分スキャンを受けている場合、これは大きな問題ではありません。 ただし、スキャン ストームのシナリオになると、プールは常にリサイクルされます。 また、クライアントはスキャン要求を行うと、 HTTP 503 などのエラーを受け取ります。
既定のキューの長さを増やし、仮想メモリとプライベート メモリの両方の制限を 0 に設定して無効にすることをお勧めします。 IIS では、アプリケーション プールの 29 時間ごとの自動リサイクル、Ping、アイドル タイムアウトが実装されますが、すべて無効にする必要があります。 これらの設定は、IIS マネージャーアプリケーション プール>で WsusPool を選択し、IIS マネージャー>の右側のウィンドウで [詳細設定] リンクをクリックします。
推奨される変更の概要と関連するスクリーンショットを次に示します。 詳細については、「Configuration Manager でのソフトウェア更新プログラムの計画」を参照してください。
| 設定名 | 値 |
|---|---|
| キューの長さ | 2000 (既定値の 1000 から増加) |
| アイドル タイムアウト (分) | 0 (既定値の 20 から低下) |
| Ping が有効になっている | False (既定値は True) |
| プライベート メモリ制限 (KB) | 0 (無制限、既定値の 1,843,200 KB から増加) |
| 通常の時間間隔 (分) | 0 (リサイクルを防止するため、また既定値の 1740 から変更) |
![[詳細設定] ウィンドウの設定のスクリーンショット。](media/windows-server-update-services-best-practices/advanced-settings.png)
約 17,000 個の更新プログラムがキャッシュされている環境では、キャッシュが約 14 GB に安定するまで構築されるため、24 GB を超えるメモリが必要になる場合があります。
圧縮が有効になっているかどうかを確認します (帯域幅を節約する場合)
WSUS では、Xpress エンコードという圧縮の種類が使用されます。 更新メタデータに圧縮が実装され、帯域幅が大幅に節約される可能性があります。
Xpress エンコードは IIS ApplicationHost.configで有効になっており、この行は [<httpCompression> 要素とレジストリ設定] に表示されます。
ApplicationHost.Config
<scheme name="xpress" doStaticCompression="false" doDynamicCompression="true" dll="C:\Program Files\Update Services\WebServices\suscomp.dll" staticCompressionLevel="10" dynamicCompressionLevel="0" />
レジストリ キー
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\IIsDynamicCompression
両方が存在しない場合は、このコマンドを実行して IIS で WsusPool アプリケーション プールを再起動することで有効にすることができます。
cscript "%programfiles%\update services\setup\DynamicCompression.vbs" /enable "%programfiles%\Update Services\WebServices\suscomp.dll"
Xpress エンコードは CPU オーバーヘッドを追加し、帯域幅は問題ではないものの CPU 使用率が高い場合は無効にすることができます。 次のコマンドを実行すると、無効になります。
cscript "%programfiles%\update services\setup\DynamicCompression.vbs" /disable
製品とカテゴリを構成する
WSUS を構成するときは、展開する予定の製品とカテゴリのみを選択します。 後で必要なカテゴリと製品をいつでも同期できます。 展開を計画していないときに追加すると、WSUS サーバーのメタデータのサイズとオーバーヘッドが増加します。
Itanium 更新プログラムとその他の不要な更新プログラムを無効にする
Windows Server 2008 R2 は Itanium をサポートする最新のバージョンであるため、問題がそれほど長引くことはないはずですが、 言及しておくべきでしょう。
環境内でこのスクリプトをカスタマイズして使用して、Itanium アーキテクチャの更新を拒否します。 このスクリプトでは、更新タイトルに プレビュー または ベータが含まれる更新プログラムを拒否することもできます。
これにより WSUS コンソールの応答性は向上しますが、クライアント スキャンに影響はありません。
置き換えられた更新プログラムを拒否し、メンテナンスを実行する
WSUS の実行を改善するための最も重要な操作の 1 つです。 更新プログラムを必要以上に長く置き換える (たとえば、展開を終了した後) ことが、WSUS のパフォーマンスの問題の主な原因です。 引き続きデプロイしている場合は、それらを維持しても問題ありません。 作業が完了したら、それらを削除します。
置き換えられた更新プログラムとその他の WSUS メンテナンス項目の拒否について詳しくは、Microsoft WSUS と構成マネージャー SUP メンテナンスに関する記事を参照してください。
SSL セットアップを使用した WSUS
既定では、WSUS はクライアント通信に SSL を使用するように構成されていません。 最初のインストール後の手順は、サーバーとクライアントの通信間のセキュリティを確保するために WSUS で SSL を構成することです。
次のいずれかの操作を行う必要があります。
- 自己署名証明書を作成する。 すべてのクライアントがこの証明書を信頼する必要があるため、理想的ではありません。
- サード パーティの証明書プロバイダーから取得する。
- 内部証明書インフラストラクチャから取得する。
証明書には、その証明書が使用する短いサーバー名、FQDN、SAN 名 (別名) が必要です。
証明書をインストールしたら、WSUS サーバーのアドレスと SSL ポートを使用するように、グループ ポリシー (または構成マネージャーのソフトウェア更新プログラムのクライアント構成設定) をアップグレードします。 通常、ポートは 8531 または 443 です。
たとえば、GPO [ イントラネットの指定] Microsoft 更新サービスの場所 を に構成します <https://wsus.contoso.com:8531>。
開始するには、「Secure Sockets Layer プロトコルを使用したセキュアな WSUS」を参照してください。
ウイルス対策の除外を構成する
累積的な更新プログラムと月次ロールアップについて
Windows OS 更新プログラムに使用される月次ロールアップと累積更新プログラムという用語が表示される場合があります。 これらは同じ意味で使用できます。 ロールアップとは、Windows 7、Windows 8.1、Windows Server 2008 R2、Windows Server 2012 R2 に対して公開される部分的に累積的な更新プログラムを意味します。
詳細については、以下のブログ投稿を参照してください。
Windows 10 と Windows Server 2016 では、更新プログラムは最初から累積的でした。
累積とは、完全に修正プログラムを適用するためには、OS のリリース バージョンをインストールし、最新の累積的な更新プログラムのみを適用する必要があることを意味します。 古いオペレーティング システムの場合、そのような更新プログラムはありませんが、今後はその方向です。
Windows 7 と Windows 8.1 では、最新の月次ロールアップをインストールした後も、さらに多くの更新プログラムが必要になります。 Windows 7 および Windows Server 2008 R2 の例を次に示します。この例では、ほぼ完全にパッチが適用されたシステムが必要です。
次の表に、Windows 月次ロールアップと累積更新プログラムの一覧を示します。 Windows <バージョン>の更新履歴を検索して見つけることもできます。
| Windows バージョン | Update |
|---|---|
| Windows 7 SP1 および Windows Server 2008 R2 SP1 | Windows 7 SP1 および Windows Server 2008 R2 SP1 の更新履歴 |
| Windows 8.1 and Windows Server 2012 R2 | Windows 8.1 および Windows Server 2012 R2 の更新履歴 |
| Windows 10 および Windows Server 2016 | Windows 10 および Windows Server の更新プログラムの履歴 |
| Windows Server 2019 | Windows 10 および Windows Server 2019 の更新履歴 |
考慮すべきもう 1 つのポイントは、すべての更新プログラムが WSUS に自動的に同期されるように発行されるわけではないということです。 たとえば、 C 週と D 週の累積更新プログラムはプレビュー更新プログラムであり、WSUS には同期されませんが、代わりに手動でインポートする必要があります。 [Windows 10 更新プログラムサービスの周期] の [月次品質更新プログラム] のセクションを参照してください。
PowerShell を使用して WSUS サーバーに接続する
PowerShell と WSUS API の使い始めるためのコードの例を次に示します。 WSUS 管理コンソールがインストールされている場所で実行できます。
[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$WSUSServer = 'WSUS'
# This is your WSUS Server Name
$Port = 8530
# This is 8531 when SSL is enabled
$UseSSL = $False
#This is $True when SSL is enabled
Try
{
$Wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer($WSUSServer,$UseSSL,$Port)
}
Catch
{
Write-Warning "$($WSUSServer)<$($Port)>: $($_)"
Break
}
関連情報
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示