【図解】初心者向けWSUSの設計/運用ガイド~仕組みやグループ分けの負荷分散,サイジングについて~

WSUS とは

WSUS (読み方 : だぶさす、だぶるさす) とは Windows Server Update Services の略で、Windows の更新プログラム (パッチファイル) を配信するサーバのことです。

WSUS サーバを社内などに構築することにより、数百数千の台数の Windows に対して更新プログラムを効率的に配信することができます

仕組みとしては単純で、本来 Microsoft がインターネット上に公開している更新プログラムを WSUS にダウンロードし、クライアントはその更新プログラムをダウンロードします。

以下に WSUS のコンポーネントと仕組みを示します。

『更新プログラムをクライアントに配信する』という表現も使われますが、実際にはクライアントが WSUS サーバに対して更新プログラムを要求し、ダウンロードし、インストールします。(WSUS サーバからクライアントに対してプッシュするわけではありません。)

クライアント側は一般には Active Directory のグループポリシーを使って以下を一斉に設定します。

  • WSUS サーバの接続先 URL (IP アドレス)
  • 最新の更新プログラムの有無確認する時刻とクライアント側の通知有無

クライアントは設定されたダウンロード時刻になったら自動的に指定された WSUS サーバに更新プログラムの確認・ダウンロードを開始します。

なお、グループポリシーが使えない環境 (Windows 10 Home やドメインに参加していない PC 等) においては『ローカルグループポリシー』でクライアント 1 台 1 台に上記設定をすることができます。※MS公式ではありませんが、Windows 10 Home でも gpedit.msc が利用できるように設定でき、ローカルグループポリシーを使用可能です。

WSUS にダウンロードした更新プログラムは WSUS の管理者に『承認』されない限り、クライアントには配信されません。後述する『グループ分けと承認』により検証を行ってから配信することもできますし、検証しなくていいから早く適用したい!という場合は『自動承認』機能によって WSUS にダウンロードしたらすぐにクライアントに配信できるようにすることもできます。

WSUSのメリット・デメリット

会社で WSUS を構築するメリットとして、社内の Windows クライアントおよび Windows サーバは高速なネットワークの中で必要なスペックで動作する WSUS サーバ上から効率的に Windows 更新プログラムを取得することができます

また、後述しますが、社内の管理者は『承認』機能を使うことで、一部のクライアントにだけ配信・インストールさせて動作を検証した後に、全クライアントに対して配信・インストールさせる、といった運用をすることもできます。

また、社内の管理者はクライアントの更新プログラムの適用状況を WSUS サーバのレポート画面で確認することができます。

デメリットとしてはそのサーバを構築する費用が掛かります。

一方、Microsoft としても 本来用意しているインターネット上のサーバの負荷が減るので、利用してもらったほうが嬉しいはずです。

更新プログラムの分類・種類

一般にパッチは以下の 3 種類に分けられます。

  1. セキュリティパッチ : 脆弱性対応
  2. バグフィックス : セキュリティ上の問題は無いがハングアップするなどの不具合を改修
  3. 機能追加:新たな機能の追加

Windows では上記とは異なる軸 (その他) でも分類しています。以下に分類の一覧を示します。

  • Feature Packs [機能追加] : OS 上で動作する新しいアプリケーションを追加します
  • Service Packs [その他] : 今までの様々なパッチをいい感じに含みつつ、さらに一部大きな修正を含むことがあります
  • Upgrades [機能追加] : OS 自体の機能を更新します
  • セキュリティ問題の修正プログラム [セキュリティパッチ] : 脆弱性の修正です
  • ツール [その他] : タスクマネージャ等のユーティリティツールの修正です
  • ドライバ [その他] : Intel 等の多ベンダのドライバを更新します
  • ドライバーセット [その他] : ドライバ群をまとめてセットで更新します
  • 更新 [バグフィックス] : ちょっとした不具合を解消します
  • 修正プログラム集 [その他] : ホットフィックス、セキュリティ問題の修正プログラム、重要な更新、および更新をまとめて1つにパッケージ化したものを配信します
  • 重要な更新 [バグフィックス] : 目立つくらいの不具合を解消します
  • 定義更新プログラム [その他] : Windows Defender の定義ファイルや Office 等で使われる定義ファイルを更新します

WSUS設計のポイント

以下については個人の経験知であり、参考程度に見て下さい。

WSUS サーバのサイジング

[CPU/メモリ]

CPU とメモリは接続してくる台数によって大きく変わります。最小スペックとしては CPU : 2 GHz, メモリ : 2 GB となっていますが、例えば 1000 台を管理するには CPU : 4 core 程度, メモリ : 8 GB 程度は欲しいところです。

[ディスク]

ディスク自体は HDD でもよいでしょうがクライアント同時接続数が多いならやはり SSD がよいです。

容量は対象とする更新プログラム (『製品の選択』と『分類の選択』) や WSUS サーバの運用期間によって異なりますが、例えば『製品の選択』として Windows 10 系と Office 2019 系、Windows Server 2019 を対象とし、『分類の選択』としてデフォルトの分類 (Upgrades/セキュリティ問題の修正プログラム/重要な更新/定義更新プログラム) を5 年間運用するのであれば 800 GB もあれば十分かな、という感覚です。(Microsoft 次第なので明言はできませんが。)

[データベース]

これに加えて Windows 8.1 や Windows 2016、SQL サーバ等の色々な種類の更新プログラムを溜めるとなると、もっと余裕のある容量に設計すべきです。

また、データベースは WID (Windows Internal Database) が無料で使えるので通常の場合はこれで十分です。もし高パフォーマンスを求める場合は Windows SQL Server を使うこともできます。他のサーバの兼ね合いで対象クライアント分の SQL Server CAL を買っている場合などは調達コストが低くなるため要検討です。

負荷分散

大量の PC (例えば 1000 台以上) を接続させるならコンピュータアカウントを異なる OU で分割し、それぞれに接続先 WSUS サーバの異なる設定をした GPO (グループポリシーオブジェクト : グループポリシーの設定情報) を適用し、負荷分散させることを検討しましょう。

※ Active Directory グループポリシーは原則 OU 単位に適用します

グループ分けと承認による検証

WSUS ではクライアントを『グループ分け』することで、承認 (更新プログラムのダウンロード・インストール許可) をグループ単位に行うことができます。

これは OU によるグループ分けではありません。OU は先ほどの例で『Active Directory のグループポリシーの適用範囲をグループ化するため』に使いましたがこれは『WSUS の承認ルールなどの設定範囲をグループ化するため』に使います。

また、WSUS に接続してさえいれば良いので、ドメインに参加していなくてもグループ分けは可能です。

これを使って、『数台のクライアントグループに対して承認を行い、動作検証』⇒『他の全グループに対して承認』という運用を行うことができます。WSUS サーバ上で任意のグループを作成し、その後、接続済のクライアントに対してそのグループを割り当てます。

すると更新プログラムの承認を実施する際に『どのグループにその更新プログラムを承認するか』というのを聞かれるようになります。

自動承認

承認は更新プログラム 1 つ 1 つに対して行うため非常に面倒です。『検証しなくていいからすぐにクライアントに配信したい!』というものについては自動承認機能を使うことで手間を省くことができます。

例えば更新プログラムの種類の中でも『セキュリティ問題の修正(セキュリティパッチ)』と『重要な更新(バグフィックス)』については自動承認する、という設定をしておけばこれらについてはすぐにクライアントに配信されるようになります。

全てのプログラムを自動承認する、という運用をするところもあります。

承認後のクライアント側の自動実行、通知&手動実行

承認後、クライアント側で更新プログラムのダウンロードを自動で実施するか、ダウンロードボタンをユーザに通知することでダウンロードのタイミングをユーザに委ねることができます。

インストールについても同様で、インストールを自動実行するか、インストールボタンをユーザに通知し、インストールタイミングをユーザに委ねることができます。※インストールを自動実行したとしても、再起動のタイミングはユーザが手動で実行します。

クライアントのプロキシ除外

クライアントが Windows Update 通信をプロキシ経由になるように設定してしまうとプロキシの負荷が高まります。クライアントが大量にある場合、Windows Update の動作が重くなり、不快に感じるでしょう。

クライアントから WSUS サーバへの通信が除外されるように確実に設定しましょう。以前に、『PAC ファイルを使っているクライアントは、インターネットオプションで自動検出を無効にしようが何をしようが、最優先で PAC ファイルの記述の通りにプロキシを利用してしまう』という事象に遭遇したことがあります。このあたりも注意が必要です。

これは WSUS を使わずクライアントが直接 Microsoft のアップデートサイトを見に行くときも同様です。これに関しては以下も併せてご参照下さい。

【プロキシ負荷低減】セッション数の多いo365をpacで迂回(bypass)する設定~FortiGate編~
【プロキシ負荷低減】セッション数の多いo365をpacで迂回(bypass)する設定~FortiGate編~
プロキシの負荷とセッション数 プロキシサーバは主に『ログの集中管理』や、アダル...

Windows の更新プログラムについて

Windows は毎月 第2火曜近辺で月恒例のアップデートが配信されますが、緊急の場合は緊急パッチが随時配信されます。

また、過去のパッチを手動で適用することもできます。Microsoft のカタログサイトで KB 番号で過去のパッチを検索し、それを直接適用したい Windows 上で実行するだけです。

https://www.catalog.update.microsoft.com/Home.aspx