Insider's Eye 次世代パッチ管理ソフト最新版、WSUSの新機能（2） Peter Pawlak 2005/03/29 Copyright (C) 2005, Redmond Communications Inc. and Mediaselect Inc.

WUSの変更点

　WUSはSUSを全面的に刷新したもので、基本機能は同じだが、実装の詳細は大幅に変わっている。

　SUSがActive Server Page（ASP）ベースのアプリケーションであるのに対し、WUSはASP.NETアプリケーションであり、バンドルされたMSDEデータベースに構成情報と承認の詳細を格納する。企業はローカルまたはリモートのSQL Server 2000データベースを使うこともできる。WUSは.NET Frameworkを導入したWindows 2000 Server SP4環境か、32bit版のWindows Server 2003上で動作する。

　この新しいアーキテクチャは、MicrosoftがSUSよりはるかに優れた管理用のユーザー・インターフェイスを構築するのに貢献した。この新しいインターフェイスはローカライズしやすく（最初のリリースでは17の言語がサポートされる）、開発者がサードパーティ・アプリケーション（例えば、パッチ対応監査ツールや、新しい更新プログラムが利用可能になった際に管理者に電子メールで通知する製品など）の統合に利用できるマネージドAPIとSDKをサポートする。

　WUSでは、主に次のような分野で新機能が提供される。

WUSの変更点（1）：管理者向けのレポーティング

　SUSは、Internet Information Services（IIS）の生のログにダウンロードやインストールの動作記録を残すが、それらの解析や分析を行うためのレポーティング・ツールは提供していない。WUSは、管理対象コンピュータごとにどのソフトウェア更新プログラムが必要で、どれがインストールされているかを管理者が調べられるステータス・レポート機能を提供し、管理者のシステム監視を支援する。

　管理者はパッチ適用システムをトラブルシューティングする場合には、各管理対象コンピュータについて、更新プログラムのダウンロード状態や、再起動を待っているかどうかなど、きめ細かなステータス情報も入手できる。だが、企業全体のソフトウェア更新状況の要約レポートは入手できないほか、WUSのレポートは、管理者以外の人が見られるようにイントラネット・サイトに公開することができない。このため、サードパーティのアドオンを導入しなければ、ヘルプデスク担当者やビジネス・マネージャにステータス情報を提供するのは難しい。

　WUSサーバはSUSと同様に、WANトポロジでのパフォーマンスを向上させ、スケーラビリティを高めるために階層的に構成できる。だが、ステータス情報は親WUSサーバに送られない。複数のWUSサーバを運用する企業では、管理者はシステム全体についての単一で包括的なレポートは入手できず、そうした情報を得るには、複数のWUSサーバに手動で接続しなければならない。WUSのリリース時には、報告データをエクスポートして包括的なレポートに集約するプロセスを自動化する方法を示すサンプル・スクリプトが管理者向けに提供される。しかし、この自動化機能は製品本体には統合されない。

　またMicrosoftは、WUSのリリースまでに、複数のWUSサーバの動作状態とパフォーマンスを一元的に監視できるMicrosoft Operations Manager 2005（MOM2005）用管理パックを提供すると表明している。

WUSの変更点（2）：対象設定が可能に

　WUSでは、SUSとは異なり、WUSで定義したコンピュータ・グループに基づいて、ソフトウェア更新を一部のコンピュータを対象に承認できる。この機能は特にテストを行ううえで便利だ。テストの際には、管理者はソフトウェア更新プログラムのインストール先をテスト用のコンピュータ群に限定したいからだ。またWUSでは、一般に更新承認の設定が異なるサーバとワークステーションとを手動で分けることもできる。

　しかし、SMSとは異なり、WUSの対象設定システムはかなり単純なものだ。このシステムはActive Directoryのコンピュータ・グループを利用しておらず、コンピュータは一度に1つのWUSグループにしか所属できない。また、WUSのグループ割り当ては動的ではなく、クライアントの属性、例えばサーバかワークステーションかといった属性などに基づいている。管理者はWUSサーバからコンピュータをグループに手動で割り当てるか、グループ・ポリシーやローカル・ポリシー、レジストリを編集してWUエージェントにグループ名を設定しなければならない。

WUSの変更点（3）：より柔軟な承認／発行オプション

　SUSの承認メカニズムは、ソフトウェア更新プログラムごとにシンプルなチェック・ボックスが用意され、チェックされた更新プログラムが、SUSサーバでカバーされるすべての適用可能なコンピュータにインストールされるというものだが、WUSはさまざまな承認オプションをサポートする。

　例えば、管理者は前述したように対象グループを設定できるだけでなく、ソフトウェア更新プログラムについて「検出のみ」と指定することで、更新プログラムをインストールせずに、適用可能なコンピュータの一覧を入手できる。また、管理者は「期日付きインストール」と指定して、ソフトウェア更新プログラムをWUエージェントにダウンロードし、ユーザーが期日までの都合の良いときにインストールできるようにすることもできる。ユーザーが更新プログラムをインストールせずに期日になると、WUエージェントが自動的にインストールする。

　WUS管理者は、ロールバックをサポートするように開発されたソフトウェア更新プログラムについては、インストール後にロールバックを行うこともできる（Microsoftは将来的に、すべてのソフトウェア更新プログラムでインストールを取り消せるようにする計画だ）。管理者はまた、より新しい更新プログラムで代替された更新プログラムを自動的に拒否することができ、承認がその分簡単になる。企業はWUSでサポートするソフトウェア更新プログラムやプラットフォームの種類を絞ることができる。これにより、ストレージやネットワークの要件が管理しやすくなり、検討が必要な更新プログラムの数が少なくなる。例えば、社内にWindows 2000システムがない場合には、企業はまったく使わないWindows 2000用更新プログラムに関連するオーバーヘッドを避けることができる。

WUSの変更点（4）：ネットワークが整備されていない場合のサポート

　リモート・オフィスが社内ネットワークに接続されていない場合や、広帯域のWANでインターネットに接続されていない場合には、企業はCDやDVDなどのリムーバブル・ディスクを使って、承認データやダウンロードしたソフトウェア更新プログラムのファイルを中央のWUSサーバからリモート・サイトのWUSサーバに移すことができる。ただし、このプロセスでは、ソースとなるWUSサーバからデータをエクスポートしてリモートWUSサーバにインポートするのに数段階の手作業が必要になる。また、このプロセスは、在宅勤務者向けのソフトウェア更新用CDを作る手段としては想定されていない。それでも、これはこうしたシナリオをまったくサポートしていないSUSからの改善点だ。

クライアント・エージェントの変更点

　Windows 2000 SP4以降が稼働するコンピュータ用のWUエージェントは、WUSサーバに接続して適用すべき新規のソフトウェア更新プログラムの有無を検索し、ローカル・ファイル・システムとレジストリをスキャンして必要なソフトウェア更新を調べる。次に、承認されたソフトウェア更新プログラムをWUSサーバからダウンロードし、各ソフトウェア更新プログラムが求めるインストール・テクノロジを用いてインストールする。

　最後に、ステータス情報をWUSサーバに返信し、必要に応じて再起動を実行する。SUSと同様、管理者はクライアントがWUSから適用および承認データを取得し、その後、更新ファイルをMicrosoftから直接ダウンロードするように設定できる。このような更新方法は、クライアントからインターネット接続するための帯域幅は広いが、WUSサーバとの帯域幅は限られているような場合には便利である。

　現行のWindows UpdateサイトおよびWUSを利用するすべてのコンピュータのエージェントはバージョン5に更新される（Windows XP SP2のものと同じ）。この新しいWUエージェントは、更新をより確実にすると同時に、ネットワーク利用を減らす次のようないくつかの機能を搭載している（編集部注：この記事の執筆後、Microsoftは、Windows Update v5の次バージョンとなる最新版のベータ・テストを開始した。詳細はMicrosoftの解説ページ［英文］を参照）。

■バイナリ・デルタ圧縮とBITS 2.0
　WUエージェントは、ソフトウェア更新プログラムに必要なファイルを完全ダウンロードする代替手段として、バイナリ・デルタ圧縮をサポートしている。これにより、クライアントはファイルの変更部分だけをダウンロードして、新しいパーツのみを既存ファイルにマージできる。その結果、WUエージェントとファイル・ソース（MicrosoftまたはWUSサーバ）間のトラフィックは劇的に緩和される。各クライアントから要求されるデータが少なくなるため、サーバはより多くのクライアントに同時に対応できる。

　しかし、WUSでバイナリ・デルタ圧縮を使用する際にはトレード・オフがある。「高速インストール・ファイル（express installation files）」と呼ばれるソース・ファイルは、従来のソフトウェア更新プログラムの約3倍の容量がある。従って、より大容量のローカル・ストレージが必要になり、各WUSサーバとそのアップストリーム・データ・ソース（Microsoftまたは別のWUSサーバ）間のリンクはファイル転送のためのトラフィックが増大することになる。

　バイナリ・デルタ圧縮には、Windows XP SP2、Windows UpdateまたはWUSサーバによってインストールされるBackground Intelligent Transfer Service（BITS）のバージョン2.0が必要だ。BITSはHTTPベースのファイル転送テクノロジであり、ユーザーがネットワークから切断されても中断されたファイル転送をその中断個所から復帰できるチェックポイント機能を持っている。またBITSは、ネットワーク利用をほかのネットワーク・アダプタのトラフィックに基づいて調節できるため、ネットワーク帯域幅が狭く、接続が断続的なリモート・ユーザーがソフトウェア更新ファイルをバックグラウンドでダウンロードするのに特に適している。

■Windows Installer 3.0のサポート
　新しいWUエージェントは、対象として設定されたコンピュータにWindows Installer 3.0が存在しない場合はそれをインストールする。Windows Installerがインストールしたすべてのアプリケーションの更新は、それに依存することになる。また、Windows Installer 3.0は更新ロールバックをサポートし、アプリケーション開発者がより小型のパッチ・ファイルを公開できるようにする。さらに、更新を適切な順番でインストールし、MSIベースのアプリケーションが抱えるパッチ修正の自動化を阻んできた、オリジナルのインストール・メディアの必要性をなくすことができる（『Directions on Microsoft日本語版』 2004年11月号の「セキュリティ強化時代のWindowsインストーラ、Windows Installer 3.0を徹底解剖」を参照）。

　WUエージェントはさらに、クライアントによる更新のチェック頻度を効率よく管理し、システムのシャットダウン時のみ更新をインストールするオプションを用意する。また、強制リブートの実行までにユーザーに与える猶予を管理者が設定することもできる。ただし、これらの設定オプションはすべてマシン単位であり、更新プログラム単位でコントロールすることはできない。

　これらWUエージェント側の改良により、必要な帯域幅とダウンロード時間は削減されるが、クライアントは依然としてMicrosoftのサイトまたはWUSサーバという単一の更新ソースでカバーされる。この手順は固定されたワークステーションやサーバにはよいが、WUはクライアントの現在のロケーションと利用可能な帯域幅に合わせて、効率的なソフトウェア更新ファイルのソースを識別することはできないので、ローミングを行うラップトップ・ユーザーにとって理想的ではない。

サイト統合が進むWebサービスの変更点

　現行のWindows Update Webサイト（エンド・ユーザーがブラウザでアクセスして更新プログラムをダウンロードする）とWindows Update Webサービス（現行の自動更新エージェントまたはSUSがアクセスして更新プログラムをダウンロードする）はWUSの出荷と同時に更新されてMicrosoft Updateと名称が変更される。この変更はWindows UpdateとOffice Updateサイトの統一的な更新サイトへの統合を反映したものである。Microsoft Updateは実行時にWindows OS、IE、Windows Media Player、SQL Server 2000（MSDEを含む）、Exchange 2003およびOffice XP／Office 2003の検出と更新をサポートする。いずれはすべてのMicrosoft製品の更新をサポートするようになる予定だ。

　さらにMicrosoft Updateは、パッチやサービスパックだけでなく、開発キット、デバイス・ドライバ、機能パック、ガイダンス・キット、ツール、更新ロールアップ、ノンクリティカルな更新、さまざまなMicrosoft製品をリンクするコネクタなど、多くのものを含む予定だ。またMicrosoft Updateは、サードパーティ製品のソフトウェア更新をホスティングするようには設計されていないが、Windows Hardware Compatibility Lab（WHCL）の認定ドライバを有するハードウェア・ベンダは、Microsoftへ依頼してMicrosoft Updateのサイトから配布できるようにすることができる。

　Microsoftは2004年に、自社製品に使用するインストール・テクノロジをアプリケーション用のWindows InstallerとWindowsコンポーネント用のUpdate.exeインストーラ・エンジンの2つに削減する意向を発表した。同社は、Microsoft Updateの運用が開始されるころには、この目標にかなり近づくとしている。この2つのインストーラに標準化されることで、Microsoftやほかの管理ツール・ベンダは、システム管理者が管理しやすい更新ソリューションを容易に開発できるようになる。例えば、一貫性のあるインストール・スイッチを用いて、標準フォーマットのインストール・ログを標準のファイル・ディレクトリに記述できるようになる。

SUSからWUSへの移行の課題

　WUSは機能的にはSUSに似ているが、まったく異なる基盤テクノロジを採用しているので、WUSをSUSサーバにインストールしても更新されることはなく、両製品が並列してインストールされることになる。

　WUSにはコマンドラインの移行ツールが付属し、管理者はこれを用いてソフトウェア更新の承認とダウンロード済みソフトウェア更新プログラムをSUSからWUSへと移行できる。この2段階のエクスポート／インポート・プロセスはネットワークでも行えるので、同一マシンまたは別のマシンに新規インストールしたWUSサーバを既存のSUSサーバを用いて更新できる。

　単一のSUSサーバ、または階層的に配置されていない複数のSUSサーバを利用している組織は、承認とソフトウェア更新データをエクスポートし、SUSをアンインストールする。次にWUSを既存サーバにインストールし、移行した（エクスポートした）データをインポートする。これらのサーバでカバーされるクライアントは、接続して自身を最新のWindows UpdateおよびBITSバージョンに自動的に更新する。

　組織が異なるコンピュータ名で新たなサーバを使用する場合はさらに、代替サーバのURLでアクセスできるように、クライアントを再設定する必要がある。SUSおよびWUSサーバは単一の階層に混在させることができないので、階層的なSUSシステムの移行はさらに複雑だ。WUSサーバはほかのWUSサーバまたはMicrosoft Update Webサービスとのみ同期ができる。SUSおよびWUS階層システムを、段階的に移行させる場合は並列で稼働させておく必要があるだろう。また、標準的なHTTPのポート80番の代わりにカスタム・ポート番号を使用するように設定して、SUSとWUSサーバを同じコンピュータ上で稼働させることもできる。

INDEX
	Insider's Eye
	次世代パッチ管理ソフト最新版、WSUSの新機能（1）
	コラム パッチ管理に関する用語の変更
	コラム Windows Update Servicesのアーキテクチャ
	次世代パッチ管理ソフト最新版、WSUSの新機能（2）
	次世代パッチ管理ソフト最新版、WSUSの新機能（3）

　

「Insider's Eye」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）