ネットワークの基本構成を検査する
　今回紹介するパッチ・テストは，複数のバッチ処理で構成されている。まず図3のbaseline.batは，基本的なネットワークの接続状況をテストするものだ。テスト・マシンのコマンド・プロンプトで以下のように入力してバッチ・プログラムを実行し，その結果をテキスト・ファイル（before.txt）に出力させる。

baseline.bat > before.txt

　続いて，テスト環境にパッチを適用し，再起動させる。それから同じバッチ・プログラムを再度実行して，その結果を別のファイル（after.txt）に出力させる。

baseline.bat > after.txt

　出力された2つのファイルは，ファイルの中身を比較するfcコマンドを使って検査する。両者に違いがあるかどうかをすぐに判断できる。

fc.exe /l /n before.txt after.txt

　テスト範囲を拡大するために，バッチ・プログラムにテスト・ツールを追加してもよい。ただし，無意味な違いを報告するツールもあるので注意が必要だ。findstr.exeのようなユーティリティを使って，追加するツールの出力結果をフィルタリングすべき場合がある。

　テスト結果のファイルを比較する際，fc.exeではなくグラフィカルなツールを使いたい場合は，Windows 2000 ServerのSupport Toolsに同こんされているwindiff.exeを試すとよい。

　baseline.bat内のgpresult.exeコマンドは，before.txtとafter.txtファイルに対して意図的に異なる結果を出力するようになっている。このツールは，マシンが最後にGPOを処理した時刻を正確に記録するからだ。この情報は，グループ・ポリシーが正常に動作しているかどうかを確認する際に有効である（詳細は後述）。

　baseline.bat内のnetdiag.exeも特徴的なツールで，複数のネットワークのテストを自動的に実行する。冗長モード（/vスイッチを使う）で実行すると，不良パッチが引き起こした接続上の問題に関して，構成情報やトラブルシューティング情報を豊富に表示してくれる。

リモート管理機能をテストする
　テスト環境でbaseline.batを実行したら，次は図4のバッチ・プログラムremote.batをリモート・システムから実行して，テスト環境のリモート管理機能をテストしよう。remote.batに含まれるすべてのツールを実行するには，リモート・システムのOSがWindows Server 2003かWindows XPでなければならない。ただし，ターゲット・システムはWindows 2000でもよい。

　remote.batは，rpcdump.exeですべてのRPCエンド・ポイント（ポート）へのリモート・アクセスが正常に動作しているか確認し，wmic.exeでWMI（Windowsマネジメント・インストゥルメンテーション）サービスへのDCOM（分散COM）アクセスをテストする。続いてschtasks.exeでタスク・スケジューラとやり取りしたり，net useコマンド（net.exe）でC$管理共有＊にドライブ文字を割り当てたりする。

　mstsc.exeは，シン・クライアント・セッションの動作検証のためにRDP（リモート・デスクトップ・プロトコル）でターミナル・サービス/リモート・デスクトップに接続する。RDPシン・クライアントと接続するために，target.rdpという名前のリモート・デスクトップ接続設定ファイルを作成して保存しておく。

　このファイルには，ターゲット・マシンのIPアドレス，ユーザー名，パスワードなどが含まれている。mstsc.exeを起動して，［全般］タブの［接続設定］欄の操作により作成する。

　バッチ・プログラムを実行したら，シン・クライアントのウインドウが表示されたときに自動でリモート・デスクトップにログオンできているかどうかを目で見て確認する。次にbaseline.batの場合と同様に，リモート・システム上にbefore.txtとafter.txtファイルを作成してfc.exeで2つのテスト結果ファイルを比較する。

　実稼働中のLANでIPSecを使っているなら，テスト環境でもIPSecを設定すべきである。VPNアクセスのためにIPSecを利用している場合は，NAT-T（ネットワーク・アドレス変換-トラバーサル）に関するアップグレードを必ずインストールする（詳細はサポート技術情報818043「Windows XPおよびWindows 2000用L2TP/IPSec NAT-T修正プログラム」を参照）。

重要なアプリケーションとサービスを検査する
　ネットワーク接続やリモート管理に加え，グループ・ポリシーの処理を含めたミッション・クリティカルなアプリケーション/サービスもテストする必要がある。そのためには，テスト環境のマシン上でアプリケーションやサービスのログをとる機能を有効にする。例えば，監査ポリシーをすべて有効にして，DNS，RRAS＊，認証サービス，SQL Server，Exchange Serverのデバッグ・ログも取るように設定する。こうしておけば，パッチが何かを壊した場合は，問題を検知して解析するための監査ログが残る。

　アプリケーション・ログに広範なグループ・ポリシー情報を残したい場合は，HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnosticsレジストリ・キーにあるRunDiagnosticLoggingGroupPolicyという名前のREG_DWORD値を1に設定する（大抵はこの値とDiagnosticsキーの両方を自分で作成する必要がある）。詳細はマイクロソフトの技術文書「Windows 2000におけるグループポリシーのトラブルシューティング」で紹介されている（該当サイト）。

　さらに詳細なグループ・ポリシー情報のログを取る必要がある場合は，ユーザー環境ログを有効にすることもできる。詳細はサポート技術情報221833「製品版Windowsでユーザー環境デバッグログ収集を有効にする」を参照してもらいたい。

　これらのサービスのログをすべて有効にしたら，すべてがうまく動作していることを確認するためにログをチェックし，ログをクリアしてからパッチを当てる。テキスト・ベースのログ・ファイル（イベント・ログではない）を消去したり，ブランクのテキスト・ファイルを作成したりするには以下のコマンドを実行する。

echo 1>nul 2>c:\logfile.txt

　「1>nul」はEchoコマンドからの標準出力の内容を何も表示させないようにするパラメータだ。「2>c:\logfile.txt」は標準エラー出力の内容（ブランク）を指定したファイルにリダイレクトして，既に何か記述されている場合はブランクで上書きし，ファイルが存在しない場合はそのファイルを作成するものだ。

　Windowsのイベント・ログを消去するには，VBScriptで記述したClearEventLog.vbs（図5）を呼び出す以下のようなバッチ処理を実行する。

cscript.exe ClearEventLog.vbs 127.0.0.1 Application
cscript.exe ClearEventLog.vbs 127.0.0.1 Security
cscript.exe ClearEventLog.vbs 127.0.0.1 System

　各コマンドのスクリプト名に続く引数は，イベント・ログを消去したいマシンのIPアドレスかコンピュータ名（ローカルまたはリモート）で，その次の引数はログ名である。DNS，Active Directoryまたは他のサービスのイベント・ログがある場合は，それらもクリアする。

　ログを消去したらテスト・マシンにパッチをインストールする。その後，アプリケーションやストレスのかかるサービスを開始して，エラーが起こるかどうか試してみよう。ユーザーが日常呼び出すすべての機能を実行し，その際，ネットワーク，印刷，セキュリティ制御，ファイル・システム・アクセスといった経験的に異常が起こりやすい機能を特に念入りに確認する。

　例えば，Microsoft Wordを起動する以下のようなバッチ・ファイルを作成して，Wordに自動でfile.docファイルを開かせる。

winword.exe c:\file.doc

　file.docには，AutoOpenという名前のマクロを作成して，リモート・プリンタへの出力，コピーの共有またはWebDAV（Web分散オーサリング＆バージョニング）フォルダへの保存，PDF＊ファイルへのレンダリングなどを実行させる。このマクロをAutoOpenと命名すれば，Wordがこれを含むファイルを開いたときに，マクロを自動実行する。

　Microsoft Officeのマクロを作成するに当たって，プログラミングは必要ない。例えばWord 2000/2002では［ツール］－［マクロ］－［新しいマクロの記録］を選択して，そのマクロを「AutoOpen」と命名し，保存先を［すべての文書］ではなく現在のファイルにする。この手順の後，Wordに対する操作はすべて記録されるので，印刷やWebDAVフォルダへの保存などを実行しよう。このときWordは，キーストロークやマウスのクリック操作を記録する。Excel 2000/2002では，マクロを「Auto_Open」と命名してファイルを開いたときにマクロを自動実行させるようにする。他のアプリケーション・ソフトでも同様の自動実行機能を備えているかどうかを確認しよう。アプリケーションによっては，コマンド・ライン・スイッチで多くの機能を公開している。

GUIベースのアプリケーションをテストする
　手入力しかできないGUIベースのアプリケーションをテストしたい場合でも自動化はできる。図6のkeystrokes.vbsスクリプトは，GUIアプリケーションにキーストロークを送信するためにSendKeys（ ）メソッドの使い方を紹介した例である。これを基に，自社の環境に合わせたテスト・スクリプトを作成してもらいたい。GUIプログラムをテストする際のコマンドは注意しながら入力して，スクリプトに同じコマンドを入力させる。メニューをプルダウンしたいときにAltキーが使えることをお忘れなく。

　keystrokes.vbsを見ると分かるように，AppActivate（“アプリケーション・タイトル”）メソッドは，特定のタイトルをタイトル・バーに持つアプリケーションに入力の焦点を当て，スクリプト化されたキーストロークが目的のアプリケーションに送信されるようにしている。Sleep（ミリ秒）メソッドは，スクリプトの実行をミリ秒単位で待たせて，アプリケーションがスクリプトのスピードに対応できるようにする。keystrokes.vbs内のコメントは，特別なキーやキーの組み合わせ，頻繁に使うキーとその組み合わせのキーストロークを書き出したものである。少し試行錯誤すれば，ほとんどのGUIアプリケーションを手作業なしで自動操作できる。

　他のスクリプトを使って，サービスにリモートからストレスをかけることもできる。IISサーバーのテストに当たっては，Application Center Test（ACT）のようなWebロード・シミュレータを検討しよう。詳細はサポート技術情報307492「Application Center Test（ACT）を利用したWebアプリケーションのテスト」を参照してもらいたい。

ログからエラーや警告を抽出する
　バッチ・プログラムや他のスクリプトを使ってサービスに負荷をかけたとき，ブルー・スクリーンを伴うシステム・ダウンやマウス・ポインタのフリーズが起これば異常を簡単に発見できる。一方，サービスの一部の誤動作はログに静かに記録されるだけだ。こうしたログを目で追って調べるのはあまりにも面倒で，非現実的である。そこでツールやバッチ・プログラムを使って，ログから自動的にエラーや警告を抽出できるようにしよう。

　テキスト形式のログならツールで簡単に検索可能である。Windows標準のfindstr.exeユーティリティは，特定の文字列を含む行をファイルから抽出できる。あらかじめ，テストしたいサービスが生成するテキスト・ログを調べ，異常が起きていることを示す「Fail」「Error」などの文字列を特定しておくことが肝心だ。これらの文字列はsignatures.txtと命名したテキスト・ファイルに記録する（各種のログごとにファイルを用意する）。次に以下のコマンドで異常を示す文字列を含む行を検索し，その結果を出力ファイル（output.txt）にリダイレクトする。

findstr.exe /g:signatures.txt logfile.log > output.txt

　output.txtファイルのサイズが0バイト以上の場合，何かが起きていることを意味している。findstr.exeの詳細については，Windowsのヘルプにあるコマンド・リファレンスを参照してもらいたい。

　Windowsのイベント・ログはバイナリ形式なので，findstr.exeで検索するにはテキスト形式に変換する必要がある。Windows 2000リソース・キットのdumpel.exeを使えば，イベント・ログ・データをfindstr.exeに引き渡すためのタブ区切りテキストに変換できる。

　例えば図7の抽出方法（1）のdumplog.batは，アプリケーション・ログやシステム・ログのエラー/警告のメッセージと，セキュリティ・ログの監査失敗だけを抽出するコマンドで構成されている。バッチ・プログラム内のdumpel.exeに付けられた/Rスイッチは，検索文字列が正規表現であることを明示的に示している。

　Windows XPに標準で組み込まれているEventQuery.vbsを使って，エラーと警告，あるいは失敗監査だけをダンプすることも可能だ（図7抽出方法（2）のeventquery.bat）。グループ・ポリシー・デバッグ・ログを有効にしているとアプリケーション・ログのUserenvソースから大量のエラー・イベントが発生する可能性がある点に注意してほしい。そのため，デバッグ・ログを無効にするか，それらのエントリをフィルタするとよい。また，コマンド・プロンプトでの作業が多い場合は，Windowsスクリプト・ホスト（WSH）の既定値をWindowsベースのwscript.exeからコマンド・ライン・ベースのcscript.exeに変更しておくとよい。

cscript.exe //h:cscript //nologo //s

　上記のコマンドを実行すれば，Windowsスクリプト・ホストの既定値が変更される。