運用 Microsoft Software Update Servicesの実力を探る 8．SUSの運用 デジタルアドバンテージ 2002/10/03

SUSの動作ログ管理

　SUSによるHotfixの配布が正しく行われているかどうかは、ログ・ファイルを調べることによって分かる。とはいっても、GUIベースの分析ツールのようなものが用意されているわけではなく、単にWebのアクセス・ログが残っているだけである。この点ではSUSはまだまだ未完成な製品であるといわざるをえない。

■サーバ側のログ
　SUSのサーバは、IISを使ってWebサーバ経由でHotfixを配布している。そのため、自動更新クライアントがSUSサーバへアクセスすると、その結果はWebアクセスのログとしてSUSサーバ上に記録される。SUSの管理者はこのファイルを見て、実際にクライアントへHotfixが配布されたかどうか（つまり、クライアントがアクセスに来たかどうか）を調べる必要がある。

　SUSの自動更新クライアントがSUSサーバへアクセスする場合、ある特別なアクセス・パターンが使われ、IISのログ・ファイルにはその記録が残るようになっている。具体的には、Webサイトのルート（通常はC:\Inetpub\wwwrootフォルダ）にある「wutrack.bin」というファイルをアクセスする（このファイル自体は単なるダミーであり、内容には特に意味はない）。このとき引数として、自動更新クライアントの動作状態を表す文字列をパラメータとして渡している。管理者はこの文字列の内容を調べることにより、クライアントが何をしようとしているのかを知ることができる。例えば、ダウンロードしようとしているHotfixの名前やOSプラットフォーム、動作状態（ダウンロードしようとしているのか、インストールしようとしているのか）、インストール結果などが分かる。

　IISのログは通常は%windir%\system32\Logfiles\W2SVC1フォルダの中に、日付ごとに個別のファイルとして記録されている。まずはここからwutrack.binという文字列を含む行だけを取り出してみよう。findは、一致する文字列を含む行だけを取り出すコマンドである。

C:\>cd \WINNT\system32\LogFiles\W3SVC1 C:\WINNT\system32\LogFiles\W3SVC1>find "wutrack.bin" *.log ---------- EX020701.LOG 2002-07-01 13:23:01 192.168.0.121 - 192.168.0.59 80 GET /wutrack.bin U=f30025f9b2ef9a4f9fd07a3f7ec51ab1&C=IU_SITE&A=n&I=&D=&P =5.1.a28.2.100.1.0&L=ja-JP&S=s&E=00000000&M=&X= 020701132301344 200 Industry+Update+Control …（以下省略）…

　先頭にある“2002-07-01 13:23:01”はアクセスされた日付、“192.168.0.121”はクライアントのIPアドレス、“192.168.0.59”はSUSサーバのIPアドレス、“80 GET”はHTTPプロトコルのGETコマンド、“/wutrack.bin”はアクセスしているファイル名である。

　そして“U=f30025f9b2ef9a4f9f ……”以下がクライアントの動作状態を表すパラメータである。自動更新クライアントは、その動作の各段階ごとにこのようなコマンドを発行することになっているので、それらを追跡すれば、クライアントの動作が分かるという仕組みである。この部分のパラメータの詳細については、SUSのドキュメント（「Software Update Services の展開」）を参照していただきたい。

　これらのログを解析することにより、各クライアントにどのようなHotfixが配布されたかを調べることが可能だが、実際にはかなり困難であろう。Hotfixの番号（QnnnnnnやMS02-nnというような数字）がすぐには分からないし、ある特定のクライアントに対して、どのHotfixが適用されかがほとんど分からないからだ（DHCPを使っていたりすると、IPアドレスとホスト名が常に同じであるとは限らないため）。各クライアント・マシンに直接ログオンして、インストールの履歴などを調べた方が早いかもしれない。

■クライアント側のログ
　クライアント側で動作している自動更新クライアントは、自身の動作ログを“%windir%\Windows Update.log”というファイルに出力している。これを調べることによっても、自動更新クライアントの動作を知ることができるだろう。アクセスしている先のサーバが正しくSUSサーバを指しているかどうかを見ればよい。以下の例では、“http://susserver/autoupdate/getmanifest.asp”となっている部分がローカルのSUSサーバへのアクセスである。“Querying software update catalog from https://v4.windowsupdate.microsoft.com
/autoupdatedrivers/getmanifest.asp”などとなっていれば、SUSサーバではなく、マイクロソフトのWindows Updateサーバへアクセスしていることを表す。

■Windows Update.logの例 2002-10-01 13:53:42 04:53:42 Success IUENGINE Querying software update catalog from http://susserver/autoupdate/getmanifest.asp 2002-10-01 13:53:42 04:53:42 Success IUENGINE Determining machine configuration 2002-10-01 13:53:42 04:53:42 Success IUENGINE Querying software update catalog from http://susserver/autoupdate/getmanifest.asp 2002-10-01 13:53:43 04:53:43 Success IUENGINE Determining machine configuration 2002-10-01 13:53:43 04:53:43 Error IUENGINE Querying software update catalog from http://susserver/autoupdatedrivers/getmanifest.asp (Error 0x80190194) 2002-10-01 13:53:43 04:53:43 Success IUENGINE Shutting down 2002-10-01 13:53:43 04:53:43 Success IUCTL Shutting down

最後に

　以上、簡単にSUSの仕組みとその運用方法について述べてきた。SUSを使えば、社内に存在する多数のWindows系クライアント・マシンに対して、最新のHotfixやセキュリティ・パッチを適切に、かつ迅速に、そして確実に適用可能になるとされている。だが実際には、現在のバージョンのSUSでは、セキュリティ・パッチやHotfixの管理（Hotfixマネジメント）が格段に容易になるとはいえないかもしれない。

　例えばSUSでサポートされているクライアントはWindows 2000とWindows XP（とWindows .NET Server）のみで、現在企業で多く使われていると思われるWindows 9xやWindows Me、Windows NTは対象外である。Hotfixのうち、特にセキュリティに関するパッチなどはOSの種類を問わず、できるだけ速やかに適用したいところだが、SUSでは管理することができない。それらのOSでは結局、各マシンごとにWindows Updateなどを実行しなければならないとすると、SUSによる管理者の負担はあまり軽減されないかもしれない。

　また、各クライアントのHotfixの適用状態を知ることができないのも問題があるだろう。SUSによるHotfixの配布が正しく行われたかどうかを確認するには、何らかの方法で各クライアントに適用されているHotfixの状態を調べなければならない。そして未適用のマシンに対しては強制的にHotfixを配布したいところだ。だが、SUSにはこのようなHotfixの調査機能はないので、Hotfixが配布、インストールされているかどうかを確認するには、結局のところは、各マシンごとにログオンして、インストールの履歴を調べたりする必要がある。

　なおリモート・マシンのHotfixの適用状態などを調べるツールとして、HFNetChkツール（詳細については別稿の「TIPSセキュリティ・パッチの適用状態を調べる」参照）やMicrosoft Baseline Security Analyzer（MBSA、日本語版は未発表）というツールがある。これらを使えば、リモートのマシンの状態を調べることができるが、SUSとは統合されていないので、あまり使いやすいとはいえない。SUSにおけるHotfixの配布はサーバからの“プッシュ型（Hotfixを強制的に送信するタイプ）”ではなく、クライアント側からの“プル型（クライアント側から取りに来るタイプ）”なので、たとえHotfixが未適用のマシンが見付かったとしても、その後の手間はあまり軽減されない。強制的にHotfixを適用する（今すぐにHotfixを適用する）ことはできず、クライアント側がアクセスに来るのを待つしかない。

　SUSにおけるHotfixの配布は、組織内全体に対して同時に適用されてしまうが、場合によってはこれが問題となる可能性がある。リリースされたHotfixは常にすべてのマシンにいっせいに適用するのではなく、アプリケーションの互換性テストなどを実行して、問題がないと分かってから組織全体に配布したい場合もある。だがSUSでは配布先のクライアントやグループを細かく制御できないので（1台のSUSサーバがあれば、その配下にあるクライアントへはすべて同じ設定で同時に送られることになる）、少し面倒かもしれない。解決策としては、一部のクライアントへはWindows UpdateもしくはSUSの管理コンソールにある個別ダウンロード機能を使って、テスト的にHotfixを導入し、テスト後に全体に対して配布を始めるという方法がある。SUSを使っていてもWindows Updateは問題なく併用できるので、状況によって使い分けるというのも賢い使い方といえるだろう。

　ところでマイクロソフトには、ソフトウェア（やパッチなど）の自動配布、クライアント・マシンのインベントリ調査（内容を調べること）機能などを持つ、Systems Management Server（SMS）という製品がある。クライアント数が500台を超えるような大組織では、SUSではなく、SMSによるHotfixマネジメントを使うようにマイクロソフトでは推奨しているが（「セキュリティ アップデート マネジメント ソリューションの選択」参照）、あまり大きくない組織ではSMSは大げさすぎて向かないだろう。

　ノー・コストで導入可能な無償ツールという大きなメリットがあるものの、現状のSUSは、Hotfixの適用が正しく実行できたかを簡単には確認できないなど、企業ユーザーが社内のセキュリティ・レベルを向上させるために安心して使えるとは考えにくい。SUSで満足できなければ、有償製品のSMSがあるが、単純なHotfixマネジメント・ツールとしてみたときには、SMSでは機能過剰といえる。SMSよりも簡便で、Hotfixやセキュリティ・パッチ、さらにはService Packや企業独自のプログラムなどの配布、管理機能を持つ、よりシンプルにして、かつ十分な機能を持つ管理用ソフトウェアがほしいところだ。

関連リンク
マイクロソフト	Microsoft Software Update Servicesのページ

INDEX
	［運用］Microsoft Software Update Servicesの実力を探る
	1．Software Update Servicesの概要
	2．SUSの仕組み
	3．SUSで管理するHotfixの配布
	4．SUSサーバのインストール
	5．SUSサーバの設定
	6．SUSクライアントの制御
	7．SUSのクライアントの動作
	8．SUSの運用

　

運用

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