第2回 w32timeデバッグ・ログとw32tmコマンド：Windowsネットワーク時刻同期の基礎とノウハウ（1/3 ページ）
今回はw32timeサービスのログとw32tmコマンドの使用法について解説する。
本連載では、Windows XPやWindows 2000 Server／Windows Server 2003における時刻同期サービスについて解説しています。Windows Vista、Windows 7、Windows Server 2008／R2を対象とした時刻同期サービスについては、以下の改訂版記事を参照してください。
・連載「Windowsネットワーク時刻同期の基礎とノウハウ（改訂版）」（2012年版）
前回は、Windows XPおよびWindows Server 2003ではNTPベースの時刻同期サービス“Windows Time”が存在し、「信頼に足る時刻」かどうかを判断したうえ、参照先NTPサーバから同期を行うこと、時刻同期のStratum（階層構造）に従い上位のNTPサーバから時刻同期を行うことなどを述べた。
今回は、w32timeのデバッグ・ログの見方とNTPプロトコル・パケットの例、およびw32tmコマンドの使用方法について解説する。
NTPベースでの時刻同期に必要な条件とは何か
従来、Windowsの世界では、閉じたネットワーク内で特定コンピュータとの時刻同期（net timeコマンドなど）をサポートしており、NTPのような多対多の関係を重視した時刻同期のシステムにはなじみが薄い。Windowsシステム管理者の中には、単純に、なぜNTPサーバが稼働し、時刻を提供しているにもかかわらず、時刻同期ができないケースがあるのか、いぶかしがる向きもあるだろう。以下、時刻同期を行うために最小限考慮が必要な要件を挙げてみよう。
■時刻同期とStratum（階層）の関係
前回では、NTP階層は原子時計やGPSといった高度に正確な時計を頂点に、時刻同期のための階層がインターネット上に形成されていると述べた。仮にこういったシステムがなく、標準時刻を提供する機器にNTPクライアントが一斉にアクセスにいけば、ネットワークレベルで当然パンクしてしまうだろう。こういったことを防ぐためには負荷分散が欠かせないが、一方で正確な時刻を持つ機器から離れるほど時刻の正確性は薄れてしまう。そこで、最も正確度が高いNTPサーバをStratum 1として、Stratum 2以下がn＋1（上位Stratumに1を足した形）形式で最大Stratum 15までの階層を構成したうえ、それぞれのサーバ上で数式などで算出される「時刻の正しさの度合い」に組み込むことで、最も正確な時刻を持つ機器から離れているために発生する、時刻のずれを修正するしくみが用意されている。
すべてのNTPサーバ／クライアントは時刻同期時に上記の形式でStratumに組み込まれる形となり（Windows Timeサービスも含まれる）、NTP階層情報が見つけられない場合、時刻同期は行われない。
NTPプロトコルヘッダ内情報の確認
前回述べたが、NTPプロトコルでは「信頼に足る時刻」を参照先NTPサーバからNTPクライアントが受け取れなかった場合、時刻同期を行わない。では、NTPクライアントはどのようにして「信頼に足る時刻」かどうかを判断しているのだろうか。
NTPサーバに時刻同期の情報を問い合わせた場合、応答パケットに含まれるNTPプロトコルヘッダ情報に“Leap Indicator”というフィールドが存在する。このフィールドは、応答元（つまり参照先）NTPサーバ自身の同期状態を示す内容となっている。ここで“not synchronized”（同期していない）となっていた場合、参照先NTPサーバ自身が正しい時刻同期を行っていないことを示しているので、NTPクライアントは受け取った時刻を無効と判断する（※）。
【2012/04/16追記】
※LIフィールドの扱いについて
「Leap Indicator（LI）」は本来、うるう秒があるかどうかという状態を示すフィールドだが、RFC 1305ではLeap Indicatorフィールド値が「3（2進数で11）」の場合、「alarm condition (clock not synchronized)」という同期失敗を示す状態として定義されている。
またUNIX／LinuxのNTPサーバでは、ntpdがローカル・クロックを含めたどのNTPサーバとも安定な同期状態（ntpq -pコマンドで「*」が存在する状況）になっていない場合、Windowsクライアントからの問い合わせに対する応答パケットでは、Leap Indicatorフィールドに値3が設定される。
このようなことから、必ずしも最適とはいえないが、LIフィールドを同期失敗（同期未完了）を表すインジケータとして利用しても問題ない、と筆者は考えている。
また、上位NTPサーバから時刻同期を受けているNTPサーバでは、参照先NTPサーバがさらなる上位NTPサーバから時刻同期を行っている場合、その情報を保持しており、“Reference Timestamp”フィールドに記録される。この情報が正常に存在すれば、NTPクライアントは正しい時刻がどのように（参照先NTPサーバに）設定されたのかが分かる。併せて“Reference Clock Identifier”フィールドには、参照先NTPサーバ自身が参照した情報を持つ、NTPサーバのIPアドレスが記録される。以下はパケット・アナライザ・ソフトウェア（Etherealというフリー・ソフトウェア）で取得したパケット・キャプチャの内容である（【2012/04/16追記】Etherealは現在ではWireSharkという名前になっている。こちらの関連記事も参照）。
同期した場合のパケットの例
参照先NTPサーバが正当な時刻情報を持っている場合のパケットの例。LI（Leap Indicator）の内容が00（2進数）となっている。
（1）参照先NTPサーバ（この例では192.168.10.252）が保持する時刻が正当であることを示している (パケットは NTP サーバから NTP クライアントへのレスポンスであることに注意)
（2）参照先NTPサーバが保持している、上位NTPサーバ（この例では210.173.160.27）からの時刻同期情報が記録されている。
同期できない場合のパケットの例
参照先NTPサーバが正当な時刻情報を持っていない場合のパケットの例。LI（Leap Indicator）の内容が11（2進数）となっている。
（1）（参照先NTPサーバが保持する時刻が）適切なNTPサーバから同期を行っていないことを示している。
（2）時刻同期を行っていないため、同期先に関する情報は記録されていない。
なおNTPヘッダ情報に関しては、RFC2030および下記の資料を参照いただきたい。
- RFC2030：Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI（IETF）
- NTP Architecture, Protocol and Algorithms［PDFファイル］ （David L. Mills氏のホームページ）
w32timeデバッグ・ログを読む
前回、時刻同期がうまくいっているかどうかをチェックする方法としてイベント・ビューアのシステム・ログから確認する方法のほかに、w32timeデバッグ・ログを判読する方法を紹介した。実際にNTPプロトコルがどのようにやりとりされ、内部にどう反映されているかどうか、残念ながらシステム・ログからでは詳細は分からない。そのため、w32timeデバッグ・ログはトラブル時に有用な情報となる。以下に作成方法と簡単な判読方法についてみていこう。
w32timeデバッグ・ログの作成方法
w32timeデバッグ・ログはトラブルシューティング用のログとして位置付けられているため、作成するためにはレジストリを設定する必要がある。設定するレジストリ値は以下のとおりである（HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Configキー配下に以下の値を追加する）。
| 項目 | 内容 |
|---|---|
| キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Config |
| 値の名前 | FileLogSize |
| 型 | DWORD |
| 値の内容 | 10000000（10進数） （ログファイルのサイズを指定する） |
| 値の名前 | FileLogName |
| 型 | REG_SZ |
| 値の内容 | C:\Windows\Debug\w32time.log （ログファイルのフルパスを指定する） |
| 値の名前 | FileLogEntries |
| 型 | REG_SZ |
| 値の内容 | 0-300 （これは文字列型であることに注意。“0-300”は最も詳細な情報を採取する場合の設定） |
| w32timeデバッグ・ログのためのレジストリ設定 | |
FileLogSize値およびFileLogName値の意味は特に説明は不要と考えられるが、FileLogEntries値は数値の範囲を指定していることに注意してほしい。FileLogEntries値に適切な値を設定することで、情報の種類をフィルタリングして、必要と考えられるものだけを書き出すことも実は可能だ。興味のある方は、次の情報を確認されたい。
w32timeデバッグ・ログ自体の情報は、以下を確認してほしい。
なお、Windows Timeサービスの実行権限はWindows Server 2003 SP1ではLocal SystemからLocal Serviceアカウントに変更されているため、（上記の例では）C:\Windows\Debugフォルダに対してLocal Serviceアカウントが書き込み権限を持つようにアクセス権を変更しないと、書き込みができないことに注意してほしい。
w32timeデバッグ・ログの判読例
w32timeデバッグ・ログを記録すると、さまざまな情報が書き込まれるが、トラブルシュートに必要な最小限の判読方法について見ていこう。ただし、判読方法に関するマイクロソフトの資料などは存在しなかったため、筆者の推測が含まれる点は、あらかじめお断りしておく。
時刻同期のごく大まかな流れとしては、まずWindows Timeサービスのコンポーネントの初期化を行い、参照先NTPサーバからのポーリング（時刻同期情報の取得）を行い、一定の条件を満たせばClientプロバイダで取り込んだうえ、Windowsシステム時刻に反映を行おうとする。
下記は、過去に一度も時刻同期していない状態のWindows Server 2003 SP1上で、0x1モード（定間隔で同期）でWindows Timeサービスを実行した状況をトレースしたものである。
1．ログでは、まずWindows Timeサービス設定についての初期化が行われ、Windows Time Clientプロバイダ（NTPクライアント機能を提供するプログラムのコンポーネント）のロードが開始される。
Windows Timeサービスの初期化1
Windows Timeサービスの初期化が行われ、Windows Time Clientプロバイダがロードされる。
（1）初期設定として各種レジストリ値が読み込まれる。
（2）Windows Time Clientプロバイダがロードされる。
2．次いで通信に必要なソケットが生成されたうえ、Windows Time Clientプロバイダのロードの完了とWindows Time Serverプロバイダ（NTPサーバ機能を提供するプログラムのコンポーネント）のロードが行われ、必要な処理の後、時刻同期のためのNTPパケットがリクエストされる。
Windows Timeサービスの初期化2
Windows Time ServerプロバイダのロードとNTPサーバへの到達性の確認が行われる。
（1）Windows Time ClientプロバイダおよびServerプロバイダの設定が完了する。
（2）参照先NTPサーバへの到達性を確認し、ポーリングが行われる。
3．参照先に指定されたNTPサーバからのレスポンスの内容が確認され、必要な条件を満たしていればClientプロバイダが同期情報として取り込む。この作業が成功すると、イベント・ビューアのシステム・ログにログが記録されるが、デバッグ・ログにもその状況が記されていることが分かる。
NTPサーバからのレスポンスの確認
参照先に指定されたNTPサーバからのレスポンスの内容が確認され、必要な条件を満たしていればClientプロバイダが同期情報として取り込む。
（1）参照先NTPサーバからのレスポンス内容が記録される。
（2）Clientプロバイダに同期情報が取り込まれる。
（3）成功を示すイベント・ログが記録されたことを表す。
4．3で取り込んだ時刻に対して、Windowsシステム時刻に反映させるための処理を行う。この作業が成功すると、イベント・ビューアのシステム・ログにログが記録されるが、デバッグ・ログにもその状況が記されていることが分かる。
Windowsシステム時刻の反映処理
3で取り込んだ時刻に対して、Windowsシステム時刻に反映させるための処理を行う。
（1）取り込んだ時刻同期情報のうち、最も適切なものを選択する。この例では1つだけなので、自動的に決定される。
（2）Windowsシステムに対して時刻同期が反映される。
（3）動作の成功を示すイベントが記録された。
w32timeデバッグ・ログの大まかな見方が分かれば、トラブルシューティングに大いに役立てることができるだろう。例えば、2の項目でWindows Time Serverプロバイダが起動していなければNTPサーバとして機能していないことが分かるし、3の項目で参照先NTPサーバからの応答状況（応答そのものがないのか、NTPヘッダ情報に問題があるのか）といったことを確認できる。4の項目で、実際に同期内容が反映されているかどうか、の確認も可能となる。
例えば典型的な事例として、参照先のNTPサーバが上位NTPサーバから時刻同期を行っていないことで信頼に足る時刻を保持していない場合、受け取ったパケットのNTPヘッダ情報のLeap Indicatorがnot synchronizedに設定され、かつReference Timestamp情報が空欄になっていることで、時刻同期が行われないことが、デバッグ・ログから判断できる。
同期エラーの例
参照先NTPサーバが、上位NTPサーバから信頼に足る時刻情報を取得していない場合の例。
（1）Leap IndicatorおよびStratumが同期を行っていない値となっている。
（2）Reference Timestampなどの値も同期を行っていないため、設定されていない。
（3）チェックで問題があったため、同期内容を無視したことが記録されている。
【更新履歴】
【2012/04/16】LIフィールドの扱いに関する補足コラムを追加しました。
【2005/11/10】当初公開した記事の図「同期した場合のパケットの例」の解説において、参照先NTPサーバのIPアドレスが間違っていました。お詫びして訂正いたします。
Copyright© Digital Advantage Corp. All Rights Reserved.