Windowsネットワーク時刻同期の基礎とノウハウ
第1回 Windows OSにおける時刻同期サービスとNTP
1.時刻同期プロトコルNTPの概要とWindows Timeサービス第2回 w32timeデバッグ・ログとw32tmコマンド
1.NTPプロトコルとw32timeデバッグ・ログ第3回 UNIXベースのNTPサーバとWindows Timeサービス
1.ネットワーク内に基準となるNTPサーバを導入する第1回 Windows OSにおける時刻同期サービスとNTP
1.時刻同期プロトコルNTPの概要とWindows Timeサービス
ネットワークを介してコンピュータを接続する場合、それらコンピュータ間で「時刻(クロック)」を同期させておくことは非常に重要である。サービスやファイル・システム、イベント・ログなど、さまざまなものが時刻情報を元にして動作しているからだ。本記事では、NTP/SNTPプロトコルを使い、ネットワーク経由で時刻情報を同期させるための手法について解説する。今回は、Windows OSシステムだけでNTPネットワークを構築、運用する方法について解説する。
われわれがコンピュータで作業をする場合、ファイルに行ったアクセス記録にはそのときの時刻(以下「時刻」とは、「年月日時分秒」情報のことを指す)がタイム・スタンプとして記録されることは、皆さんご存じであろう(ファイルの[プロパティ]ダイアログで簡単に確認できる)。同様に、Windowsでのさまざまなシステム稼働状況は、例えばイベント・ログなどにその時刻とともに記録されている。この時刻情報を提供しているのはWindows システム時刻(Windows OS 上で設定された時刻情報)である。
昨今、何らかのセキュリティ上の問題が生じた場合に備え、監視されたアクセス記録などを含めた各種ログを継続的に取得保存するだけでなく、必要に応じてほかに稼働するシステムのログ類との突き合わせに利用するケースが増加している。この突合せのときにはそのログが記録された時刻をよりどころとするしかないわけだが、もしシステムごとにシステム時刻が大きく異なった場合、作業には大きな負担がかかることとなるだろう。
外部の標準時刻に同期されていれば、実際に動作が発生した時刻を正しく把握できる。このため、WindowsおよびUNIX系をはじめ、コンピュータ・システムには時刻同期の仕組みが用意されており、外部の信頼されたリソースと時刻を同期させることが可能となっている。
こういった時刻同期のシステムはさまざまな場所で利用されているが、例えば時間による課金システムなどでは、重要な要件として盛り込まれていることもしばしばである(時刻が正確でない場合、課金の正当性に問題が生じるため)。
Windowsに話を戻すと、Active Directory環境ではkerberos認証がデフォルトで利用されるが、ドメイン・コントローラとクライアントの時刻情報を認証に利用するために、一致した時刻情報を持っていることが前提となっている。時刻が大きく異なった場合は認証に失敗する。このため、Active Directory環境ではドメイン内のコンピュータの時刻同期は極めて重要なファクタとなっている。そこで「Windows Time」サービスという、時刻同期のためのサービスがWindows 2000以降のOSで導入された。
余談であるが、時刻同期に関する勧告の1つであるRFC2030上では、標準時刻とシステム時刻の誤差は0.5秒以内が適切とされているようだ(実際はもう少しあいまいな表現がされている)。
時刻の同期は、ネットワークで結ばれた環境下で、時刻を提供するサーバ機能(時刻同期サーバ)と時刻を取得するクライアント機能(時刻同期クライアント)を保持するサービスやアプリケーションとの間で実行される。時刻同期が必要なコンピュータは、クライアントとしてサーバに対して時刻同期のための問い合わせを行い、サーバは要求に応じてクライアントに時刻を返答する。これを図にすると次のようになる。
![]() |
時刻同期サービスの概要 |
Windows OSの「Windows Time」サービスやUNIXのデーモンは、ほかの時刻同期サーバに対して、時刻同期クライアント機能を使ってネットワーク経由で同期を行う。時刻同期アプリケーションの実装によっては、クライアント機能しか持たないものもある。 |
時刻同期のサービスは、以前から国内外の大学や研究機関などが一般あるいは研究者向けに提供しているが、最近では企業やプロバイダがより一般向けのサービスとして無償提供していることがある。例えば以下のサービスなどを利用して、基準となる時刻情報源にするとよいだろう。
Windows Timeサービスは、基本的にkerberos認証での必要要件に対応するために実装されたと考えられるが、その実装は漸次変化している。Windows 2000ではRFC 1769に準拠したSNTP(Simple Network Time Protocol)プロトコルが採用されたが、Windows XPおよびWindows Server 2003では、RFC 1305に準拠したNTP(Network Time Protocol)プロトコルが代わって採用されている(Windows TimeサービスではNTP Version 4拡張部分にも合わせて対応している)。
NTPはSNTPと互換性を持つものの、複雑で高度な動作を行うプロトコルとして位置付けられている。SNTPが単純に参照先の時刻サーバから時刻を同期するだけの動作となっているのに対して、NTPはほかの時刻サーバと連携して「最も正しいと考えられる時刻」を選択して同期できるよう適切に動作する。
![]() |
SNTPプロトコルとNTPプロトコルでの時刻同期方法の差異 |
SNTPでは、単に参照先NTPサーバからの時刻を同期するだけとなっているが、NTPでは保持する時刻の信頼度に応じて「Stratum(階層)」と呼ばれる階層が存在し、参照先NTPサーバが信頼に足る時刻情報源かどうか(有効な上位NTPサーバからの同期情報を保持しているかどうか)が重要であるため、必要に応じて参照先NTPサーバからさらなる上位NTPサーバなどに問い合わせを行っている。参照可能な上位NTPサーバすべてで問題が発生するなどで、NTPサーバが信頼に足る時刻情報を保持することができない状態となると、NTPクライアントは受け取った時刻を信頼できないものとして同期を行わない。 |
複数の時刻情報源を利用するNTPでは、もしどこかでエラーが発生しても(信頼に足る時刻情報が得られなくなっても)、代わりにほかのNTPサーバを利用して、精度の高い、信頼できる時刻情報を提供するようになっている。
![]() |
NTPプロトコルによる時刻同期の方法 |
NTPでは、例えば図のような同期関係が構成される場合、どこかで障害が発生しても適切な方法で信頼に足る時刻を持つサーバから時刻を同期できるため、全体に影響が及ばないつくりとなっている。また本来NTPは、多対多の同期関係に基づいた実装となっており、設定された各NTPサーバに対してNTPレベルでのネットワーク距離(同期距離)や時刻のずれの度合いなどから、最適な参照先をその都度自動選定するようになっている。 |
NTPではこのような構造の階層システム(stratumおよびpeer階層と呼ばれる)が独自に存在している。その頂点には、原子時計やGPSなどを基にした高度に信頼できる時刻サーバが置かれ、これを基準にした階層構造がインターネット上に実装されている。
Windows XP以降では、ワークグループ環境およびActive Directory環境で時刻サーバ(以下NTPサーバ)および同期するクライアント(以下NTPクライアント)として動作させることが可能である(ただしUNIXベースのNTPサーバとは実装が異なる。詳細は第3回で解説)。初期設定ではNTPサーバおよびNTPクライアントのどちらも稼働した状態となっている。
2.ワークグループ環境における時刻同期
時刻同期が必須となったActive Directory環境に対応するため、Windows 2000以降のOSでは標準的に実装されたWindows Timeサービスが時刻同期を行う実装となっている。ちなみに各OSの時刻同期実装は以下のとおりである。
OS | 時刻同期機能 |
Windows 9x/Me | 標準はなし。サードパーティ製アプリケーションを導入する |
Windows NT 4.0 | 標準はなし。NT 4.0リソースキットから追加導入可能 |
Windows 2000 | Windows Timeサービス(SNTPプロトコル) |
Windows XP | Windows Timeサービス(NTPプロトコル) |
Windows Server 2003 | Windows Timeサービス(NTPプロトコル) |
Windows OSごとのNTPベースでの時刻同期機能 |
同じWindows Timeサービスでも、Windows 2000とWindows XP以降ではそのサポートしているプロトコルや機能が異なる(よって設定内容も異なる)ことに注意してほしい。なお、Windows NT 4.0およびWindows 9x系ではダウンレベル(過去のバージョン)となるNTLM認証が行われるため、時刻同期は必須ではない(認証に時刻情報は不要)。また、従来Windows ネットワーク・ベースでの時刻同期の仕組みとしてnet timeコマンドを使った方法が存在するが、本題ではないため割愛する。Windows 2000環境での時刻同期の方法については、関連記事のTIPSを参考にしていただきたい。
なお、本記事ではWindow 2000の挙動の詳細については割愛するが、Windows 2000ではSNTPサーバおよびSNTPクライアントとして動作させることが可能だ。SNTPはNTPのサブセットとなっているので、参照先サーバがNTPあるいはSNTPサーバとして正常稼働していれば同期に関して問題は起こりにくい。ただし、NTP階層に組み込むような利用方法では注意が必要である(完全な機能を持つNTPサーバとしては利用できない)。
Windows XP以降では、コントロール・パネルの[日付と時刻]管理ツールを起動すると[インターネット時刻]タブが存在する(ドメインに参加したマシンには存在しない)。
![]() | ||||||||||||||||||
日付と時刻のプロパティ | ||||||||||||||||||
[コントロール パネル]の[日付と時刻]管理ツールを起動するか、タスク・バー上の時刻表示部分をダブルクリックすると表示されるダイアログ。時刻を同期させる先を設定することができる。 | ||||||||||||||||||
|
参照先のデフォルトは「time.windows.com」というサーバになっており、インターネットに接続された環境であれば、すでに時刻同期が行われた旨のメッセージが表示されているはずである。もし、同期ができなかったという場合はメッセージの内容に応じて対応する必要がある。
![]() | |||
時刻同期が失敗した場合のダイアログ(1) | |||
相手のNTPサーバから必要な応答がなかった場合には、このようにエラーとなる。 | |||
|
この場合は、相手先NTPサーバから必要な応答がなかったことを意味する。サーバに対してpingなどで生存確認ができてもNTPサーバとして機能していない、あるいは混雑しすぎている可能性が考えられる。対策としては、時間をおいてアクセスするか、ほかのNTPサーバを設定するしか方法はない。NTPサーバを自組織で管理している場合は、サーバがして正しく動作しているかを確かめる必要がある。
![]() | |||
時刻同期が失敗した場合のダイアログ(2) | |||
ローカル・コンピュータの時刻と、NTPサーバの時刻がずれすぎていても同期することはできない。 | |||
|
これは、NTP サーバとクライアント間で時刻がずれすぎているため、同期が行えなかったことを意味する。対策としては、クライアント・コンピュータの時間を現在の時刻に大まかに合わせておけばよい。場合によっては、コンピュータのバックアップ用電池の状態を確認し、必要ならば交換するなどの対策が必要である(バックアップ電池が消耗していると、電源オフ時に内蔵時計が停止してしまうことがある)。なおデフォルトでは、NTPサーバとクライアント・コンピュータの時刻が15時間以上ずれている場合にこのエラーが発生する。しかしレジストリ値の設定により、同期間隔を変更したり、ずれの量を無視して強制的に同期させたりすることも可能である。
![]() | |||
時刻同期が失敗した場合のダイアログ(3) | |||
NTPネットワーク階層の状態が不正(不安定)になるなどして、信頼できる時刻情報が得られなかった場合のエラー・メッセージの例。 | |||
|
この場合は、相手先NTPサーバが保持する時刻情報がNTPプロトコルとして「信頼に足る時刻」と認められなかったため、クライアントが時刻を同期しなかったことを意味する。NTPプロトコルでは、各NTPサーバが信頼に足る時刻を保持している必要があるため、必要に応じてNTPサーバ自身がより上位NTPサーバに時刻同期を行うことで、自身のNTP階層上の位置を確認する。この確認が成功しなかった場合、NTP階層の構造が正しくないという意味で上記のメッセージが表示される。またそのほかの原因で、信頼できる時刻情報が得られない場合にもこのようなメッセージが表示される。
対策としては、基本的には、ほかのNTPサーバ(NTP階層的に正しく設定されたもの)に設定を変更することがあるが、何らかの事情で不可能な場合、[インターネット時刻]タブを利用せずに同期を設定することができる。これは次の方法で行う。
■方法1:w32tmコマンドで設定する
コマンド・プロンプトから、以下のようにコマンドを設定する。
w32tm /config /manualpeerlist:<NTPサーバのIPアドレス>,0x8 /syncfromflags:manual |
■方法2:net timeコマンドでSNTPサーバを指定する
コマンド・プロンプトから、以下のようにコマンドを設定する。
net time /setsntp:<NTPサーバのIPアドレス>,0x8 |
■設定の確認方法
コマンド・プロンプトから、以下のようにコマンドを実行する。
w32tm
/resync |
どちらも設定内容としては同一だが、w32tmコマンドを使うと、関連するレジストリ設定なども自動的に行われる。この設定を行った後で[インターネット時刻]タブを開き、そこで[OK]や[今すぐ更新]ボタンをクリックすると、NTPサーバの設定などが変わってしまう。よって、上記のコマンドを実行した後は、[インターネット時刻]タブで設定を変更しないことが望ましい。
これらは、NTPプロトコルでの同期に関するモード(Association Mode)を変更する設定である。通常はSymmetric Active/Passive ModeというNTP階層をチェックする方法で時刻を同期するところを、Client/Server ModeというNTP階層をチェックしない方法で同期を行うことができる。この方法については以下のサポート技術情報を参照されたい。
Association Modeの詳細については、以下の情報を参照していただきたい。
Windows Server 2003やWindows XPでは、以下の3つの方法で時刻同期の状況を確認できる。
[インターネット時刻]タブのフォームに表示されるメッセージから確認する(詳細は上述したとおり)
イベント・ビューアのシステム・ログから確認する
w32timeデバッグ・ログから確認する
イベント・ビューアのシステム・ログには、時刻同期が行われると以下のログが記録され、同期の状況が確認できる。
![]() | ||||||
時刻の同期中のイベント(1) | ||||||
NTP/SNTPサーバからデータを受信した場合のイベント。 | ||||||
|
![]() | |||
時刻の同期中のイベント(2) | |||
NTP/SNTPサーバから得た時刻とシステム時刻を同期しているイベント。 | |||
|
上記のログは通常は、システム起動後に、最初に時刻同期されたときに記録されるが、時刻同期のたびごとに必ず記録されるわけではない。よって、上のログだけを見て時刻同期がいつでも正常に行われていると判断することは適切でない場合があるので注意してほしい。もちろん、時刻が同期されていない状況では警告またはエラーのログが記録されるので、そういった情報から状況は確認できる。
w32timeデバッグ・ログとは、Windows Timeサービス上での時刻同期の状況が詳細に記録されたログのことである(サービス名はWindwos Timeサービスであるが、ログにはW32Timeという名称で記録される)。本来はトラブル時に利用されるもので、解析にはNTPプロトコルに関する知識が必要である。初期設定ではw32timeデバッグ・ログは記録されないため、設定にはレジストリ値を追加する必要がある。設定方法については、まずは以下を参照願いたい。
これについては、第2回で解説する。
3.Active Directory 環境における時刻同期
Windows Server 2003のActive Directory環境では、各クライアントおよびドメイン・コントローラは時刻同期のためのプロトコルとしてNTPを利用している。しかし、その階層構造は独自のものとなっているため、SNTPに似た挙動で時刻の同期が行われる(問い合わせはSymmetric Active Modeで行われるが、応答はSever Modeにて行われる)。
Active Directoryでは、その頂点をFSMOの役割の1つであるPDCエミュレータが受け持ち、それ以外のドメイン・コントローラはPDCエミュレータあるいはほかのドメイン・コントローラから、時刻同期を行う。各クライアントは直近のドメイン・コントローラ(つまり自身がログオンするドメイン・コントローラ)から、時刻同期を行うようになっている。
サイトに分割されたActive Directory環境では、基本的には各サイト内の「信頼に足る時刻」を持つドメイン・コントローラから時刻同期を行うが、該当するドメイン・コントローラが存在しない場合、別のサイトにあるドメイン・コントローラあるいはPDCエミュレータから時刻同期を行う。
マイクロソフトの資料によると、フォレスト・ルート・ドメインのPDCエミュレータ以外のドメイン・コントローラが時刻同期を行う場合、以下の優先順序で時刻同期を行おうとする。筆者の検証でも、資料どおりの挙動がある程度は確認できた。
細かい話となるが、実際の挙動は資料と異なっている場合がある(特定の状況下で同期を行わない)ので、非常に詳細な制御が必要な場合は注意を要する。
Active Directory 環境下の時刻同期についての詳細は、以下のマイクロソフトの資料の“Domain Hierarchy-Based Synchronization”の項目を参照いただきたい。
なおNTPプロトコルの実装では、NTPサーバが自分自身を時刻同期の参照先とすることを認めていないため、例えばPDCエミュレータが時刻を同期する場合、3や6の手順は実行されない。「NTPサーバが自分自身を時刻同期の参照先とすることを認めない」は、ワークグループ環境などでも当てはまるため、覚えておくといいだろう(*)。
* Windows 2000では、同期先NTP/SNTPサーバを自分自身に設定し、自身を標準時刻を保持している時刻サーバとしたり、w32timeエラー・メッセージなどを回避する方法が一般化していたが、Windows XP以降ではこのような設定を行うことはできない。ただし別の設置絵を行うことで、自身を標準時刻とすることができる(詳細については第3回参照)。 |
ただし、フォレスト・ルート・ドメインのPDCエミュレータは、ドメイン環境での時刻同期ツリーの頂点であり、外部NTPサーバと時刻を同期させる必要があるので、ほかのドメイン・コントローラと挙動が異なる。
Active Directory環境で、Windowsのみでマシンが構成されている場合、フォレスト・ルート・ドメインのPDCエミュレータ以外のすべてのマシンは、上記の構成に基づいて自動的に最適な形で時刻同期のためのネットワークが設定されるため、特に管理者が注意することはない。しかし、フォレスト・ルート・ドメインのPDCエミュレータの時刻同期は自動設定されないため、これに対してのみ、外部のNTPサーバから時刻同期するよう設定すればよいだろう。
ドメイン・コントローラ上では、時刻同期のための[インターネット時刻]タブ(詳細は前ページ参照)は存在しない。よって、コマンドで時刻同期のための設定を行う必要がある。
コマンドを利用してPDCエミュレータが時刻同期を行う方法は、ワークグループ環境で時刻同期するためのコマンド設定と要領は同じである。なお、以下の設定では[インターネット時刻]タブでの設定と内容的には同じになる。
■方法1:w32tmコマンドで設定する
w32tm /config /manualpeerlist:<NTPサーバのIPアドレス>,0x1 /syncformflags:manual |
■方法2:net timeコマンドでSNTPサーバを指定する
net time /setsntp:<NTPサーバのIPアドレス>,0x1 |
即時に時刻同期させるには「w32tm /resync」コマンドを実行すればよい。前ページで説明したAssociation ModeをClient Modeに設定する方法と比べると、パラメータの一部が「0x8」が「0x1」となっているところだけが異なっている。このパラメータ値には以下の意味がある。
パラメータ | 意味 |
0x0あるいはパラメータ値なし | Windows端末同士を含む標準的なNTP時刻同期方法(Symmetric Active/Passive Mode) |
0x1 | Windows 上のみ実装された定間隔での同期方法 |
0x2 | ドメインおよび外部の両方から時刻を同期する(利用方法は後述する) |
0x4 | 明示的なSymmetric Active/Passive Modeによる同期方法 |
0x8 | 明示的なClient/Server Modeによる同期方法(詳細は前ページ参照) |
![]() | |
/manualpeerlistの第2パラメータ |
このパラメータ値を変更することで、同期の仕方や同期間隔に影響を与えることができる。上位となる外部NTPサーバの実装に応じて使い分けるとよいだろう。ちなみに上記の値は以下のレジストリ値に記録される。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Parameters |
![]() | |
値の名前 | NtpServer |
型 | REG_SZ |
値の内容 | time.windows.com,0x1 (初期値) |
![]() | |
NTPサーバとの同期方法を指定するレジストリ設定 |
Windows Timeサービスでの時刻同期間隔は基本的にはNTPプロトコルの時刻同期間隔に準拠している。標準的なNTPの時刻同期間隔は可変的なものであり、通常は最小同期間隔から同期の状態を確認しながら徐々に間隔が空く形で最終的には最大同期間隔で同期される。この同期間隔は以下のレジストリ値で設定されているため、値を変更することで間隔を変更することが可能だ。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEの\SYSTEM\CurrentControlSet\Services\W32Time\Config |
![]() | |
値の名前 | MinPollInterval |
型 | REG_DWORD |
値の内容 | 0xa(ワークグループ環境での初期値。10進では10。2の10乗=1,024秒) 0x6(ドメイン環境での初期値。10進では6。2の6乗=64秒) |
![]() | |
最小同期間隔のレジストリ設定 |
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEの\SYSTEM\CurrentControlSet\Services\W32Time\Config |
![]() | |
値の名前 | MaxPollInterval |
型 | REG_DWORD |
値の内容 | 0xf(初期値。10進では15。2の15乗=32,768秒) |
![]() | |
最大同期間隔のレジストリ設定 |
上記の0xaや0x6、0xfという数値は、NTPプロトコルの実装に基づき、2のべき乗を表すことに注意してほしい。例えば上記MinPollInterval値(ドメイン)は、2の6乗=64なので、64秒ごとの同期間隔となる。
上記のMinPollInterval値およびMaxPollInterval値による同期間隔の実装は、Active Directory環境でもワークグループ環境でも変わることはなく、同じように動作する。
ただし、NTPServerレジストリ値のパラメータが「0x1」となっている場合は、例外的に定間隔な同期間隔で同期が行われる。この設定はワークグループ環境での初期状態および [インターネット時刻]タブから設定したときには無条件で有効となる。この状態では、(一度も時刻同期したことがない場合)最初に時刻同期した後に、以下のレジストリ値で定められた間隔で時刻同期が実施される。必要に応じて設定の変更が可能だ。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEの\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient |
![]() | |
値の名前 | SpecialPollInterval |
型 | REG_DWORD |
値の内容 | 0x93a80(10進数では604,800秒) (ワークグループ環境での初期値)0xe10(10進数では3,600秒) (ドメイン環境での初期値) |
![]() | |
同期間隔のレジストリ設定 |
上記の値は単に秒数で設定されるため、例えばワークグループ環境であれば10進数換算で604,800秒(=7日)ごとに時刻が同期される。ドメイン環境では3,600秒、つまり1時間間隔となる。またSpecialPollInterval値で同期される場合、レジストリに前回の同期時刻が記録されるため、Windows Timeサービスの起動時ごとに同期されるわけではなく、前回同期時からカウントされる。SpecialPollInterval値による同期記録は同じキーにあるSpecialPollTimeRemaining値に記録されるため、この内容を空にしておけば記録情報を初期化できる。なお、SpecialPollInterval値は通常フォレスト・ルート・ドメイン内における、PDCエミュレータでないドメイン・コントローラや、ドメインに参加しているクライアントでは利用されないため、初期値にあるように(10進数換算で)3,600秒(=1時間)ごとに時刻を更新することはない。
SpecialPollInterval値を使った一定時間間隔での同期設定はNTPプロトコルに基づく実装ではない。だが明示的な間隔での時刻同期が設定できるため、Windows 2000でのWindows時刻同期の実装に慣れ親しんだ管理者には理解しやすいだろう。また、時刻同期を頻繁には行わせたくない場合に便利な設定であろう。
4.ドメイン内と外部NTPサーバの両方に対する時刻同期
前述したように、Active Directory環境では、フォレスト・ルート・ドメインのPDCエミュレータを頂点として時刻同期の階層が形成されており、外部NTPサーバとの時刻同期はPDCエミュレータのみが担当することになっている。しかし、状況によってはほかのドメイン・コントローラや特定クライアントが「信頼に足る時刻」を常に保持しなければならないケースもあるだろう。
例えば、フォレスト・ルート・ドメインのPDCエミュレータがダウンした場合、実装上では、ほかのドメイン・コントローラは最終的には「信頼に足る時刻」を入手することはできなくなるが、これを避けてほかのドメイン・コントローラも状況に応じて外部NTPサーバから時刻を取得できるようにする方法がある。この場合、以下のように設定を行う。
レジストリ・エディタから以下のキーおよび値を探し、以下のように変更する。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEの\SYSTEM\CurrentControlSet\Services\W32Time\Parameters |
![]() | |
値の名前 | Type |
型 | REG_SZ |
値の内容 | ALLSync |
![]() | |
同期方法のレジストリ設定 |
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Parameters |
![]() | |
値の名前 | NtpServer |
型 | REG_SZ |
値の内容 | <外部NTPサーバのIPアドレス>,0x2 |
![]() | |
NTPサーバとの同期方法を指定するレジストリ設定 |
設定を変更したらコマンド・プロンプトから「net stop w32time & net start w32time」を実行するなどしてw32timeサービス(Windows Timeサービス)を再起動し、レジストリ内容をサービスに適用させる。
上記の設定では、ドメイン環境で(ほかのドメイン・コントローラから)時刻同期を行うことに加え、外部のNTPサーバからも時刻を同期することを可能とするオプション「ALLSync」を利用している。NtpServerレジストリ値のパラメータ「0x2」は代替として外部NTPサーバから時刻同期を行わせるための設定値である。
この設定については、以下のサポート技術情報を参照していただきたい。
Windows XP以降のクライアントであれば、上記の方法をそのまま流用し設定することも可能であると考えられる。ただし、クライアント上でドメイン・コントローラでない端末と(結果的に)時刻同期した場合、kerberos認証上の問題が生じる可能性がある。よって、クライアントはドメイン・コントローラからのみ確実に時刻同期を行い、各ドメイン・コントローラの時刻同期をきちんと設定する方法をお勧めする。
まず、時刻同期そのものに関して、データベース・システム(SQL ServerやOracleなど)を稼働させているコンピュータ上では特に注意が必要な点がある。
データベース・システムではトランザクション・ログなどの記録にシステム時刻が利用されるが、この時刻に関しての整合性が満たされない場合、データベース・システムが正常に動作しないことがある。例えばコンピュータの時刻が進みすぎている場合に単に時刻同期を行うと、時刻が後戻りしたように見えるという問題が発生する。このような問題に対処するため、UNIX系の時刻同期では、「slew(スルー)モード」と呼ばれる、「時刻の進み方を(実際の時間よりも)少しずつ遅らせて」、時刻そのものは後戻りせずに、ゆっくりと同期させる方法が利用される(slewはすべらせる、ずらすという意味)。Windows Timeサービスにも似た実装は存在するが、時刻の進みが決められたしきい値以内(*)でなければ(つまり実際の時刻より遅いか、決められた時間以上進んでいる状態ならば)、時刻が一気に同期してしまう。トラブルを避けるためには、事前に基準となる時刻にNTPなどを利用して時刻同期を行ってから、構築を行うべきだろう。
* Windows 2000では3分以内のずれ(進み)で同様の動作をする実装があるが、Windows XPおよびWindows Server 2003では実装が変更され、ドメインに参加した環境では5分以内、ワークグループ環境では1秒以内となっている。詳細は以下のドキュメントの「How Windows Time Service Can Affect Users and Applications」の項目を参照されたい。 |
現在Windows Timeサービスには、ある状況下で正常に同期が行えない、同期間隔の設定が正しく行えないなどの不具合がある。詳細は以下のサポート技術情報などを参照していただきたい。
上記の問題が発生しているシステムや、時刻同期を極めて厳密にコントロールする必要がある場合は、修正プログラムの適用が必要な場合があるので注意してほしい。できれば(修正済み環境である)Windows Server 2003 Service Pack 1およびWindows XP Service Pack 2を適用した状態で運用するとよいだろう。
第2回 w32timeデバッグ・ログとw32tmコマンド
1.NTPプロトコルとw32timeデバッグ・ログ
前回は、Windows XPおよびWindows Server 2003ではNTPベースの時刻同期サービス“Windows Time”が存在し、「信頼に足る時刻」かどうかを判断したうえ、参照先NTPサーバから同期を行うこと、時刻同期のStratum(階層構造)に従い上位のNTPサーバから時刻同期を行うことなどを述べた。
今回は、w32timeのデバッグ・ログの見方とNTPプロトコル・パケットの例、およびw32tmコマンドの使用方法について解説する。
従来、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プロトコルヘッダ情報に“Leap Indicator”というフィールドが存在する。このフィールドは、応答元(つまり参照先)NTPサーバ自身の同期状態を示す内容となっている。ここで“not synchronized”(同期していない)となっていた場合、参照先NTPサーバ自身が正しい時刻同期を行っていないことを示しているので、NTPクライアントは受け取った時刻を無効と判断する。
また、上位NTPサーバから時刻同期を受けているNTPサーバでは、参照先NTPサーバがさらなる上位NTPサーバから時刻同期を行っている場合、その情報を保持しており、“Reference Timestamp”フィールドに記録される。この情報が正常に存在すれば、NTPクライアントは正しい時刻がどのように(参照先NTPサーバに)設定されたのかが分かる。併せて“Reference Clock Identifier”フィールドには、参照先NTPサーバ自身が参照した情報を持つ、NTPサーバのIPアドレスが記録される。以下はパケット・アナライザ・ソフトウェア(Etherealというフリー・ソフトウェア)で取得したパケット・キャプチャの内容である。
![]() | ||||||
同期できない場合のパケットの例 | ||||||
参照先NTPサーバが正当な時刻情報を持っていない場合のパケットの例。LI(Leap Indicator)の内容が11(2進数)となっている。 | ||||||
|
なおNTPヘッダ情報に関しては、RFC2030および下記の資料を参照いただきたい。
前回、時刻同期がうまくいっているかどうかをチェックする方法としてイベント・ビューアのシステム・ログから確認する方法のほかに、w32timeデバッグ・ログを判読する方法を紹介した。実際にNTPプロトコルがどのようにやりとりされ、内部にどう反映されているかどうか、残念ながらシステム・ログからでは詳細は分からない。そのため、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デバッグ・ログを記録すると、さまざまな情報が書き込まれるが、トラブルシュートに必要な最小限の判読方法について見ていこう。ただし、判読方法に関するマイクロソフトの資料などは存在しなかったため、筆者の推測が含まれる点は、あらかじめお断りしておく。
時刻同期のごく大まかな流れとしては、まず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プロバイダがロードされる。 | ||||||
|
2.次いで通信に必要なソケットが生成されたうえ、Windows Time Clientプロバイダのロードの完了とWindows Time Serverプロバイダ(NTPサーバ機能を提供するプログラムのコンポーネント)のロードが行われ、必要な処理の後、時刻同期のためのNTPパケットがリクエストされる。
![]() | ||||||
Windows Timeサービスの初期化2 | ||||||
Windows Time ServerプロバイダのロードとNTPサーバへの到達性の確認が行われる。 | ||||||
|
3.参照先に指定されたNTPサーバからのレスポンスの内容が確認され、必要な条件を満たしていればClientプロバイダが同期情報として取り込む。この作業が成功すると、イベント・ビューアのシステム・ログにログが記録されるが、デバッグ・ログにもその状況が記されていることが分かる。
![]() | |||||||||
NTPサーバからのレスポンスの確認 | |||||||||
参照先に指定されたNTPサーバからのレスポンスの内容が確認され、必要な条件を満たしていればClientプロバイダが同期情報として取り込む。 | |||||||||
|
4.3で取り込んだ時刻に対して、Windowsシステム時刻に反映させるための処理を行う。この作業が成功すると、イベント・ビューアのシステム・ログにログが記録されるが、デバッグ・ログにもその状況が記されていることが分かる。
![]() | |||||||||
Windowsシステム時刻の反映処理 | |||||||||
3で取り込んだ時刻に対して、Windowsシステム時刻に反映させるための処理を行う。 | |||||||||
|
w32timeデバッグ・ログの大まかな見方が分かれば、トラブルシューティングに大いに役立てることができるだろう。例えば、2の項目でWindows Time Serverプロバイダが起動していなければNTPサーバとして機能していないことが分かるし、3の項目で参照先NTPサーバからの応答状況(応答そのものがないのか、NTPヘッダ情報に問題があるのか)といったことを確認できる。4の項目で、実際に同期内容が反映されているかどうか、の確認も可能となる。
例えば典型的な事例として、参照先のNTPサーバが上位NTPサーバから時刻同期を行っていないことで信頼に足る時刻を保持していない場合、受け取ったパケットのNTPヘッダ情報のLeap Indicatorがnot synchronizedに設定され、かつReference Timestamp情報が空欄になっていることで、時刻同期が行われないことが、デバッグ・ログから判断できる。
![]() | |||||||||
同期エラーの例 | |||||||||
参照先NTPサーバが、上位NTPサーバから信頼に足る時刻情報を取得していない場合の例。 | |||||||||
|
2.w32tmコマンド
w32timeデバッグ・ログと同様に、トラブルシュート時に便利なツールとして、w32tmコマンドがある。トラブル時のみでなく、各種の設定やほかのコンピュータ間との時刻監視など、使いみちは豊富だ。以下簡単に、その機能と使い方を確認しておこう。
■Windows Timeサービスの設定を変更する
前回でも触れたが、例えばWindows
Timeサービスの参照先NTPサーバの設定はnet time /setsntpコマンドで実施することができるが、詳細な設定についてはnet
timeコマンドで行うことはできない。よってこのような場合レジストリ・エディタを利用してレジストリ値を設定することになるが、基本的な設定については、w32tm
/configコマンドから実行できる。
書式:w32tm /config
/update /manualpeerlist:[NTPサーバ名]
/syncfromflags:manual |
これを実行すると次のようになる。
C:\>w32tm /config /update
/manualpeerlist:ntp1.jst.mfeed.ad.jp /syncfromflags:manual コマンドは正しく完了しました。 |
これはワークグループ環境での参照先NTPサーバを指定するコマンドである。syncfromflagsオプションでワークグループまたはドメイン環境の別を指定し、manualpeerlistオプションで参照先NTPサーバを指定する。またupdateオプションから明示的にWindows Timeサービスに内容を反映させることができる。
書式:w32tm /config
/update /syncfromflags:domhier |
これを実行すると、以下のようになる。
C:\>w32tm /config /update
/syncfromflags:domhier コマンドは正しく完了しました。 |
上記はドメイン環境での時刻同期の設定である。syncfromflagsオプションからドメイン環境であることを指定している。なお、ドメイン環境では参照先NTPサーバは自動的に決定されるため、通常manualpeerlistオプションは設定しても意味を持たないことに注意してほしい。なお、上記に紹介した以外のオプションも存在する。
■手動で時刻同期を行う
w32tmコマンドを利用すると、明示的にNTPベースでの時刻同期を手動で行うことができる。この場合、以下のコマンドから実行できる。
書式:w32tm /resync
[/computer:[同期を行うコンピュータ名]] [/rediscover] |
実行例は次のとおり。
C:\>w32tm /resync 再同期のコマンドを送信: local computer... コマンドは正しく完了しました。 |
同期先の環境が変更されたなどで時刻同期がうまくいかなくなった場合、rediscoverオプションで修正することが可能である。なおcomputerオプションから同期を行うコンピュータをリモート操作することは可能ではあるが、Windows認証を通過する必要があるためドメイン環境以外ではあまり使いみちはない。
■ほかのNTPサーバとの時刻差を監視する
自分自身の時刻が、ほかのNTPサーバとどの程度ずれているか、確認したり監視したりすることが可能だ。この場合、w32tm
/monitorコマンドを利用する。
書式:w32tm
/monitor /computers:[NTPサーバ名] (あるいは
/domain:[ドメイン名]) |
これを例えばcomputerオプション付きで実行すると次のようになる。
C:\>w32tm /monitor
/computers:ntp1.jst.mfeed.ad.jp,ntp2.jst.mfeed.ad.jp ntp1.jst.mfeed.ad.jp [210.173.160.27]: ICMP: 22ms delay. NTP: -0.1155277s offset from local clock RefID: fs-monntp2.mfeed.ad.jp [210.173.160.86] ntp2.jst.mfeed.ad.jp [210.173.160.57]: ICMP: 30ms delay. NTP: -0.1126106s offset from local clock RefID: fs-monntp2.mfeed.ad.jp [210.173.160.86] |
また、domainオプション付きで実行すると、次のようになる。
C:\>w32tm /monitor
/domain:chabcorp chabvssv10.chabcorp.local *** PDC *** [192.168.10.40]: ICMP: 29ms delay. NTP: +0.0000000s offset from chabvssv10.chabcorp.local RefID: ntp1.jst.mfeed.ad.jp [210.173.160.27] chabvssv11.chabcorp.local [192.168.10.41]: ICMP: 27ms delay. NTP: -2.0160926s offset from chabvssv10.chabcorp.local RefID: chabvssv10.chabcorp.local [192.168.10.40] chabvssv12.chabcorp.local [192.168.10.67]: ICMP: 25ms delay. NTP: -6.3021221s offset from chabvssv10.chabcorp.local RefID: chabvssv10.chabcorp.local [192.168.10.40] chabvssv13.chabcorp.local [192.168.10.68]: ICMP: 15ms delay. NTP: -4.8590693s offset from chabvssv10.chabcorp.local RefID: chabvssv10.chabcorp.local [192.168.10.40] chabvssv14.chabcorp.local [192.168.10.99]: ICMP: 5ms delay. NTP: +3.3371971s offset from chabvssv10.chabcorp.local RefID: chabvssv10.chabcorp.local [192.168.10.40] chabvssv15.chabcorp.local [192.168.10.100]: ICMP: 7ms delay. NTP: -8.0145432s offset from chabvssv10.chabcorp.local RefID: chabvssv10.chabcorp.local [192.168.10.40] |
参照先NTPサーバは、カンマ区切りで複数指定することが可能である。domainオプションからドメイン名を指定した場合、参照可能なNTPサーバ(ドメイン・コントローラ)一覧が表示され、その時刻差が表示される。
また、特定のNTPサーバとの時刻差について、w32tm /stripchartコマンドを利用して定期的に監視が可能である。
書式:w32tm
/stripchart /computer:[NTPサーバ名] [/period:[秒]]
[/dataonly] |
このコマンドにより、指定したNTPサーバとの時刻差を1秒ごとに取得することができるが、変更も可能だ。また、アスキー・アート風の目盛り表示がデフォルトとなっているが、dataonlyオプションで非表示にすることもできる。
実際にw32tm /stripchartを実行した例を次に示しておく。最初はずれていた時刻が、Windows Timeサービスのslewモードによって(slewモードに関する詳細な設定方法は後述)、徐々に同期していく様子が分かる。
![]() |
stripchartオプションの使用例 |
stripchartオプションを利用すると、指定されたNTPサーバと、ローカルの時刻情報の差がグラフとして表示される。ローカルの時刻が指定されたNTPサーバよりも進んでいるとマイナス値(左側)、遅れているとプラス値(右側)になる。この例では、ずれている時刻が、slewモード(ずれを少しずつ修正して、一致させていくモード)によって徐々に同期していく様子が分かる。 |
そのほかにも、w32tmコマンドには豊富なオプションがあるので、詳細は以下の資料を参照してほしい。
3.Windows Timeサービスのさまざまな設定
Windows Timeサービスは、各種レジストリ値を変更することで動作をコントロールできる。以下、事例別にざっと挙げてみよう。
以下のレジストリ値に、時刻同期を行いたいサーバのFQDN(完全修飾ドメイン名)などを、半角スペースを区切り文字として続けて入力すればよい。なお、この設定ではドメインに属しているコンピュータが任意のNTPサーバからも同時に時刻同期を行うといったことはできないので注意してほしい。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Parameters |
![]() | |
値の名前 | NTPServer |
型 | REG_SZ |
値の内容 | ntp1.jst.mfeed.ad.jp,0x1 ntp2.jst.mfeed.ad.jp,0x1 |
![]() | |
複数の外部NTPサーバから時刻同期を行うためのレジストリ設定例 |
ちなみに、同期モードを設定する第2パラメータ値(詳細は第1回を参照)は、できれば同じように設定した方がよいだろう。筆者が試した限り、異なるパラメータ値で設定すると、それぞれの参照先サーバにパラメータ値固有の動作で同期を行おうとするようだが、実際は同期間隔などが想定された動作とは異なっているようにも見受けられた。
Windows Timeサービスは同期の有無や環境によって4つのタイプを設定できるが、通常は[インターネット時刻]タブやドメインへの参加時、あるいはw32tm /config /syncfromflagsコマンドなどで設定される。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Parameters |
![]() | |
値の名前 | Type |
型 | REG_SZ |
値の内容 | NoSync (同期を行わない場合:[インターネット時刻]タブの“自動的にインターネット時刻サーバと同期する”をオフにすると設定される) NT5DS (ドメイン環境内の NTP サーバのみ同期する。ドメイン・コンピュータの標準) NTP (外部NTPサーバと同期する。ワークグループ・コンピュータの標準) AllSync (ドメイン環境と外部の両方のNTPサーバを同期する) |
![]() | |
Windows Timeサービスの同期のタイプ設定 |
時刻が進みすぎている場合に時刻同期を行うと、急に時刻が後戻りすると問題が発生することがあるので、Windows Timeサービスでも後戻りをしないように徐々に時刻を同期するslewモードという機能があり(詳細は前回参照)、何秒間時刻が進んでいる状態まで適用するかを変更することができる。この時間以内のずれならばslewモードによって徐々に時間が変更されるが、この時間以上ずれていると、slewモードではなく、直ちに時刻が変更される。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Config |
![]() | |
値の名前 | MaxAllowedPhaseOffset |
型 | DWORD |
値の内容 | 0x1 (単位は秒。ワークグループ環境のデフォルト値) |
![]() | |
slewモードの有効範囲を変更するためのレジストリ設定 |
ワークグループ環境のデフォルト設定では、15時間以上参照先NTPサーバと時刻がずれていると時刻が同期されない。これも以下2つのレジストリ値で制限値を変更したり、無効とすることができる。ただしマイクロソフトの資料では、フォレスト・ルート・ドメインのPDCエミュレータでは900秒(15分)、ワークグループ環境では3600秒(1時間)以内を推奨している。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Config |
![]() | |
値の名前 | MaxNegPhaseCorrection (時刻を後戻りさせることが可能な範囲) |
型 | DWORD |
値の内容 | 0xffffffff (単位は秒。機能を無効にする場合は0xffffffffとする) |
![]() | |
値の名前 | MaxPosPhaseCorrection (時刻を進ませることが可能な範囲) |
型 | DWORD |
値の内容 | 0xffffffff (単位は秒。機能を無効にする場合は0xffffffffとする) |
![]() | |
ずれ時間の許容範囲を設定するためのレジストリ・エントリ |
Windows TimeサービスのNTPサーバ機能(Windows Time Server プロバイダ)は以下のレジストリ値で有効にしたり、無効にしたりできる。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのCurrentControlSet\Services\W32Time\TimeProviders\NtpServer |
![]() | |
値の名前 | Enabled |
型 | DWORD |
値の内容 | 0x1 (無効にしたい場合は0x0と設定する) |
![]() | |
NTPサーバ機能の有効/無効を設定するレジストリ設定 |
なおこのレジストリ値が0x0の場合、時刻同期時の同期モードは無条件でClient/Serverモード(NTPServerレジストリ値の0x8モード相当)となる。
Windows Timeサービス起動後に、参照先NTPサーバから時刻同期を行ったり、同期された時刻がシステムに反映された場合にはシステム・ログにて記録されるが(詳細は第1回参照)、この内容についてはレジストリ値で設定が可能だ。
以下のレジストリ値を変更すると参照先NTPサーバとの時刻差や転送の遅れた時間(これらは時刻の正確性や参照のしやすさに影響を与える)について記録するw32timeイベントID 51イベントログを出力させることができる。ただしこの設定はWindows Server 2003のみで有効となるようだ。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient |
![]() | |
値の名前 | EventLogFlags |
型 | DWORD |
値の内容 | 0x2 (デフォルト値は0x1) |
![]() | |
イベントID 51をログに出力するためのレジストリ設定 |
![]() | ||||||
出力されたイベントID 51のログの例 | ||||||
イベントID 51のログには、参照先NTPサーバとの時刻差や転送の遅れ時間などの情報が記録されている。 | ||||||
|
以下のレジストリ値を変更すると、同期された時刻をシステム時刻に反映する際、通常モードでダイレクトに時刻を反映した際の挙動(何秒間システム時刻がジャンプしたか)を記録するw32timeイベントID 33イベント・ログを出力させることができる。なおslewモードで同期されている場合には、時刻が反映されていても記録はされない。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Config |
![]() | |
値の名前 | EventLogFlags |
型 | DWORD |
値の内容 | 0x1 (デフォルト値は0x2) |
![]() | |
イベントID 33をログに出力するためのレジストリ設定 |
![]() | ||||||
出力されたイベントID 33のログの例 | ||||||
イベントID 33はシステム時間が変更された際の挙動を表すイベント。 | ||||||
|
これら以外にも、いくつかのNTPに関するパラメータの値を変更することで、時刻同期のうえでの設定を変更することも可能となっている。詳細については、以下のマイクロソフトの資料にあるので参考にしてほしい。
第3回 UNIXベースのNTPサーバとWindows Timeサービス
1.ネットワーク内に基準となるNTPサーバを導入する
NTPプロトコルはWindows OSのみならず、UNIX(Linux)システムにも当然取り入れられており、本来はUNIXシステム上で運用されてきた経緯がある。よってUNIXベースで稼働するNTPサーバ・デーモンとWindows Timeサービスを組み合わせて時刻同期を行わせたいシステム管理者も少なくないだろう。
第1回と第2回では、Windows環境における時刻同期サービス(Windows Timeサービス)について解説してきた。最終回となる今回は、UNIX(Linux)ベースのNTPサーバとWindows Timeサービスの間で時刻同期を行わせる方法や注意点、またシステム内で独立したNTP階層を作成する方法などについてまとめておく。ただし、筆者の手元には、いわゆる商用UNIX環境がないので、今回はRedHat系Linuxに実装されたNTPアプリケーションを利用した。実際はほかの商用UNIXを利用するケースも往々にあるだろうが、必要に応じて読み替えていただければ幸いである。
■
例えば、業務システム内に時刻同期環境を導入する場合、組織内に基準となるNTPサーバを設置し、組織内の各コンピュータはそのNTPサーバから時刻同期を行うようにする方法はよく取られる手法である。通常は、基準となるNTPサーバにはLinux(以下、特に断らない限りUNIXも含む)に含まれるntpd(古いバージョンではxntpdと呼ばれていた)、いわゆるNTPデーモン・プログラムが利用されることが一般的だが、Windows Timeサービスを利用して設置することも不可能ではない。どちらを利用するにしても、システム要件によって2つのパターンがあるだろう。
この方法の場合、外部の信頼あるNTPサーバから時刻同期を行ったコンピュータをシステム内の基準NTPサーバとして、これに対して時刻同期するよう、各コンピュータを設定すればよい。小規模なシステムであれば1つの基準NTPサーバでリソースは十分である(NTPプロトコルのパケットサイズは90bytes程度である)と考えられるが、フォールト・トレラント(耐障害性)を考える場合は、同じ設定(同じ外部参照先から同期する)のNTPサーバをもう1台加えればいいだろう。
![]() |
外部のNTPサーバを基準にする場合 |
通常社内には1つの標準NTPサーバがあれば問題ないが、フォールト・トレラント構成にしたい場合は、このように設定すればいいだろう。標準となるNTPサーバは通常、より時刻が正確な外部NTPから同期を行うと考えられるため、標準NTPサーバ間での時刻同期は特段必要ないと考えられる。 |
2台の基準NTPサーバを設置した場合、両者が保持する時刻の整合性を考慮する必要があるが、上記では両方が同じ参照先NTPサーバから時刻同期を行っているので、事実上同じ時刻を保持していると考えられる。従って、互いを同期しあうような設定は特に必要ないと筆者は考えている。
この方法の場合、Windows Timeサービスまたはntpdの設定を「権威あるサーバ(基準時刻を自身が保持するサーバ)」として設定し、これに対して時刻同期を行うよう、各コンピュータを設定する。第1回で示したように、通常NTPサーバは(信頼に足る時刻を保持する)上位NTPサーバから時刻同期をすることで自身の整合性を保っているが、閉じたネットワークで外部NTPサーバから時刻同期を行わない場合、自身が持つローカル・クロックを標準時刻とする設定を行うことで、ほかのコンピュータが時刻同期を行うことが可能となる。
![]() |
社内に設置したNTPサーバを基準にする場合 |
インターネットに接続していない環境下では、独立した権威ある NTP サーバが必要である。こちらも通常は直接時刻同期に利用すれば問題ないが、フォールト・トレラントを考慮するのであれば、図のように設定する方法はある。なお、権威ある NTP サーバを 2 台用意して、両方を同期させながら運用するといったことは実装上不可能である。 |
そのほかの注意点は1の方法と同様だが、フォールト・トレラントを考慮して複数台の基準NTPサーバを設置する場合、この方法では両者が保持する時刻の整合性を考慮する必要があるだろう。そのためには3台の基準NTPサーバを用意し、1台を最上位NTPサーバとして「権威あるサーバ」に設定し、残りの2台を最上位NTPサーバから時刻同期を行う基準NTPサーバとして設定し、各コンピュータはこの2台のNTPサーバから時刻同期する構成とするのがよいだろう。
いままでWindows Timeサーバについて述べてきたが、ここでLinuxの標準的なプログラムに含まれるntpd(NTPデーモン・プログラム)とWindows Timeサービスを時刻同期させるうえでの、考慮すべき点について述べる。
ntpdはNTPプロトコルの仕様に基づいて、ネットワーク上でほかのNTPサーバから、なるべく正確な時刻を選択同期することを念頭に置いた実装やチューニングが行われている。例えば、「ゆらぎ(分散)」という、ネットワーク上の各NTPサーバが統計学的にどの程度時刻が正確であるかを数値化する概念があるが、こういった数値を材料として、最終的に同期するNTPサーバが選択されるのがntpdである。
一方Windowsでは、Windows TimeサービスがKerberos認証の必要性から実装された背景から、Active Directory環境で最大限の機能を発揮するよう自動的にチューニングされるものと考えられ、外部の異種OS上のNTPサーバから時刻を同期するには、手動によるチューニングが別途必要な場合がある。
外部の標準時刻を取り込んで、その時刻をすべてのコンピュータに反映させるシステム構成を利用する場合、外部NTPサーバから時刻同期を継続的に行うNTPサーバを標準のNTPサーバとする必要がある。この場合は、まずは標準NTPサーバの役割を持たせるコンピュータが、外部のNTPサーバに時刻同期を行うように設定を行い、次にほかのコンピュータがその標準NTPサーバから時刻を同期するようにする。
標準NTPサーバを設定するには、WindowsでもLinuxでも通常のNTP設定方法で外部の参照先NTPサーバを指定すればよい。
WindowsのWindows Timeサービスを設定するには、NTPServerレジストリ値にて参照先サーバや同期方法を設定する。必要に応じて同期間隔なども設定すればよいだろう(詳細は第1回を参照)。
Linuxのntpdを設定するには、通常は/etc/ntp.confファイルをvi(Windowsのメモ帳に相当する、基本的なテキスト・エディタ)などで編集し、ntpdプログラムを再起動させることで反映させる。以下に設定例を示す。
※/etc/ntp.confファイルの内容 |
なおntp.confファイル内容の詳細な解説はここでは行わないので、必要に応じてインターネット検索などで確認してほしい。
インターネット環境から切り離されたシステムの場合、システム内に外部NTPサーバと同様に権威のあるNTPサーバを設定することで、標準時刻を保持するNTPサーバとして利用することができる。各NTPクライアントは、このサーバを参照先として、時刻同期を行うように設定すればよいだろう。
以下の方法で、コンピュータのローカル・クロック(Windows OS が、マザーボード上のリアルタイム・クロックなど、ハードウェアベースの時計機能から取得している時刻)を標準時刻とするNTPサーバを設定することが可能となっている。
Windows Timeサービスでは、いくつかの設定を行う必要がある。まず、下記AnnounceFlags値を設定することで、Windows Timeサービスが権威あるNTPサーバとして設定される。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Config |
![]() | |
値の名前 | AnnounceFlags |
型 | DWORD |
値の内容 | 0x5 (初期値は0xa) |
![]() | |
Windows Timeサービスを権威あるNTPサーバにするための設定 |
またほかの参照先NTPサーバに時刻同期は行わないため、これに関する項目は空欄とする必要がある。なお、自分自身のIPアドレスは指定する必要はない。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Parameters |
![]() | |
値の名前 | NTPServer |
型 | REG_SZ |
値の内容 | (空欄) |
![]() | |
ほかのNTPサーバとの同期をしないようにするための設定 |
また、自身のローカル・クロックについての分散の値(ゆらぎ値)を変更する必要がある。筆者が確認した限り(RedHat Fedra Core 4およびRedHat Linux 8.0を利用)では、下記の例以外の値では、ntpdは権威あるNTPサーバとして設定されたWindows Timeサービスから、時刻同期を行うことはなかった(ntpqコマンドで明示的に同期が行われているかどうか確認した)。これはntpdがStratum 1のNTPサーバに直接時刻同期を行うような場合、ローカル・クロックの分散の値がごく小さい場合以外、十分に精度のある時刻と見なさず、ポーリングを行っても実質同期しないためと考えられる。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Config |
![]() | |
値の名前 | LocalClockDispersion |
型 | DWORD |
値の内容 | 0x0 (初期値は0xa) |
![]() | |
ローカル・クロックの分散値の設定 |
この設定を行い、Windows Timeサービスを再起動させれば設定が反映する。また再起動直後にほかのコンピュータから時刻同期を行うと同期できないことがあるが、これはNTPプロトコルの実装上、ローカル・クロックを権威ある時刻と認めるまでに若干時間を要するためなので、特に心配する必要はないだろう。
なお上記の設定に関しては、以下の資料を参照していただきたい。
ntpdを設定する場合、ntp.confファイル上で、自身をstratum 1(NTP階層の最上位)とすればいいだろう。例を以下に示しておく。
※/etc/ntp.confファイルの内容 |
この設定は上記と同様ntpdの再起動で反映されるが、再起動後すぐには事実上反映されない。これは実装上、起動後すぐに自身のローカル・クロックへの同期結果が有効とならないためなので、若干の時間が経過すれば、問題はないはずだ。
なお、(通常われわれが利用している)コンピュータのローカル・クロックは一般的に精度が悪く、数日の間に数秒の誤差が出る場合も珍しいことではない。よって上記の設定を行っても、外部NTPサーバと同程度の精度を代替するNTPサーバを配置したことにはならない、ということに注意していただきたい。閉じたネットワーク上で高度に正確な時刻の保持や同期が必要な場合、そういった目的に特化した専用ハードウェアを別途導入する必要があるだろう。
2.Active Directory環境でNTP時刻同期を制御する
Active Directory環境では、フォレスト・ルート・ドメインのPDCエミュレータ以外は、すべて自動的に最適な時刻同期環境が設定されているため、基本的に特別な調整や制御は不要である。しかし、この恩恵が受けられるコンピュータはドメインに参加しているWindows 2000以降のOSのみであり、ワークグループ構成のWindowsやLinuxコンピュータは、手動で設定を行わなければならない。
またドメインに参加しているコンピュータ間においても、例えば複数サイトが存在する環境で、サイト間の通信を明示的に制限する必要がある場合など(セキュアなルータや、DMZを介した環境で各サイトのゲートウェイに要さいホストを設置するなど)、手動で制限を行う必要があるケースは考えられる。以下、順を追って見ていこう。
Active Directory上の時刻同期はNTP階層のそれとは異なる、と第1回で述べたが、実際のところは、NTPプロトコルに則した時刻同期は行われているため、ワークグループのWindowsやLinuxコンピュータは、Active Directory環境の任意のNTPサーバ(=ドメイン・コントローラ)から時刻を同期させることができる。
Active Directory環境であっても、Windows Timeサービスは(ntpdとは異なり)時刻同期のため接続してくるほかのコンピュータを拒否することはできない。よって、簡便な方法であればネットワーク的に直近のドメイン・コントローラを参照先に指定するか、正確性を求めるのであれば(Active Directory環境で基準となっている)フォレスト・ルート・ドメインPDCエミュレータに同期を行えばよい。
ただし、PDCエミュレータが信頼に足る時刻を保持していないと、それ以外のドメイン・コントローラも含めて時刻同期が行えないため、基本的にはPDCエミュレータが外部のNTPサーバから時刻同期を行っている必要がある。閉じたネットワーク環境で利用している場合、以下のマイクロソフトの資料にある「内部のハードウェア クロックを使用するように Windows タイム サービスを構成する」方法に基づいて、権威あるサーバとして設定しておく。ntpdで同期させたいのであれば、併せて前述したLocalClockDispersionレジストリ値を0に設定しておく必要があるだろう。
Active Directory環境では、通常は、サイト内ドメイン・コントローラ間の時刻同期は、親ドメインのドメイン・コントローラが参照先NTPサーバとなって行われるが(詳細は第1回を参照)、フォレスト・ルート・ドメイン(シングル・ドメイン含む)では親ドメインがないため、ドメイン内のすべてのドメイン・コントローラはPDCエミュレータに対して、同期を行おうとする。
サイト間での、このNTPパケットのトラフィックを最小限に抑え、かつ特定のサーバ間だけでやりとりさせたい場合は、各サイト内に権威ある時刻サーバを明示的に設定すればよい。すると、サイト内のドメイン・コントローラは、サイト内の権威ある時刻サーバに対して時刻同期を行うようになる(ほかのドメイン・コントローラにレジストリ設定を加える必要はないが、w32tm /resync /rediscover コマンドでの同期情報の初期化が必要)。そして各サイトの権威ある時刻サーバについて、明示的にPDCエミュレータを時刻同期先として設定し、PDCエミュレータが外部NTPと同期を取るようにすればよいだろう。
![]() |
サイトごとに権威ある時刻サーバを設定した例 |
Active Directory環境で時刻同期の参照先を制御するためには、各サイト内にそれぞれ権威ある時刻サーバを設定し、サイト内の各コンピュータはその時刻サーバを頂点として階層を形成するようにする。権威ある時刻サーバはPDCエミュレータに対して、明示的に時刻同期を行うように設定すれば、権威ある時刻サーバ以外は(ほかのサイト上の)PDCエミュレータに時刻同期を行わないようになる。 |
サイト内での権威ある時刻サーバを指定するためには、以下のレジストリ値を、権威を与えたいドメイン・コントローラにそれぞれ設定する。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Config |
![]() | |
値の名前 | AnnounceFlags |
型 | DWORD |
値の内容 | 0x5 |
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Parameters |
![]() | |
値の名前 | Type |
型 | REG_SZ |
値の内容 | NTP |
![]() | |
値の名前 | NTPServer |
型 | REG_SZ |
値の内容 | <PDCエミュレータのIPアドレス> |
![]() | |
サイト内での権威ある時刻サーバを指定するための設定 |
AnnounceFlagsレジストリ値の意味であるが、マイクロソフトの資料および筆者が検証した限りでは、値の内容は4bit相当の構成となっていると考えられる。それぞれのbitはフラグとして機能し、時刻サーバとしての機能の公開と時刻サーバとしての権威の有無について、以下のような意味を持っている。
値 | 意味 |
0(全bitが0) | 自身を時刻サーバとして公開しない |
1(1bit目が1) | 明示的に、自身を時刻サーバとして公開する |
2(2bit目が1) | (Windows Timeサービスの設定に応じて)自動的に、自身を時刻サーバとして公開するかどうか決定する |
4(3bit目が1) | 明示的に、自身の時刻サーバに権威があると公開する |
8(4bit目が1) | (Windows Timeサービスの設定に応じて)自動的に、自身の時刻サーバに権威があると公開するかどうか決定する |
![]() | |
AnnounceFlagsレジストリ値の意味 | |
bit位置は、最下位bitが1bit目、その隣が2bit目、……と数える。 |
例えば明示的に権威を保持し、かつ明示的に時刻サーバとして動作させる必要があるコンピュータは、AnnounceFlagsレジストリ値を“0x5(16進数)=0101(2進数)”と設定することになる。上記 AnnounceFlags値の設定の詳細については、マイクロソフトの以下の資料を参照していただきたい。
ちなみに、上記の設定を行った状態でw32tm /monitor /domainコマンドを実行すると、“RefID”項目より、それぞれのNTPサーバの実際の参照先が確認できる。
※これは、ドメイン・コントローラchabvssv10をPDCエミュレータとする3サイトの構成となっており、chabvssv12およびchabvssv14が各サイトの権威あるNTPサーバとなり、chabvssv11、chabvssv13、cahbvssv15が各サイト内の権威ある
NTP サーバから時刻同期を行う設定となっている。 |
また、上記の応用例として、NTPServerレジストリ値に、(PDCエミュレータの代わりに)同一の外部NTPサーバ名を参照先として設定することで、サイト間のNTPパケットのやり取りを行わせず、サイト単位でそれぞれ、外部NTPサーバにある時刻を取り込むこともできる。さらに以下の設定を併用すれば、サイト間のNTPパケットを完全に抑止することもできるだろう。
Active Directory環境では、通常自身が属するサイト内の(接続するコンピュータにとって)権威あるドメイン・コントローラから時刻同期を行おうとする(詳細は第1回を参照)。これが仮に失敗した場合、デフォルトではサイト外の任意の(参照が可能な)ドメイン・コントローラから時刻同期を行うが、これを行わせない運用も可能だ。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient |
![]() | |
値の名前 | CrossSiteSyncFlags |
型 | DWORD |
値の内容 | 0x0 (デフォルト値は0x2:任意のドメイン・コントローラに対して時刻同期を行う) |
![]() | |
サイト外のドメイン・コントローラに同期させないための設定 |
ちなみに、上記の値の内容を0x1とした場合、(サイト外にある)PDCエミュレータに対して明示的に時刻同期が行われる。
なお、Windows Timeサービスに関するレジストリの設定は、ほかの項目と同じくグループ・ポリシーを利用して設定することもできる。
グループ・ポリシー・エディタを使って、[コンピュータの構成]−[管理用テンプレート]−[システム]−[Windows タイム サービス]項目を編集すれば、コンピュータ・オブジェクトに対して各種の設定ができる(詳細は連載第1回の「3.Active Directory 環境における時刻同期—Windows Timeサービスでの時刻同期間隔について」や連載第2回の「3.Windows Timeサービスのさまざまな設定」を参照)。例えば、ドメイン環境下でのすべてのコンピュータの時刻同期間隔を変更したければ、[グローバル構成設定]にあるMinPollIntervalおよびMaxPollIntervalレジストリ値を設定したポリシーを“ドメイン”コンテナに直接リンクすれば、一括で再設定させることができるだろう。
![]() | |||||||||
Windows Timeサービス関連のグループ・ポリシー・オブジェクト | |||||||||
これらの項目を設定することにより、Windows Timeサービスに関する設定を行うことができる。 | |||||||||
|
ポリシー設定の詳細については特にここでは列挙しないので、実際のグループ・ポリシーの説明項目を参照いただきたい。
3.Windows Timeサービスに関するそのほかのトピック
状況によっては、ほかのコンピュータから時刻同期の提供を受けたいが、自身の時刻の提供は明示的に行いたくない場合もあるだろう。このような場合、Windows TimeサービスではTime Serverプロバイダ(NTPサーバ機能を提供しているコンポーネント)を無効とすることで、NTPクライアントとしてのみ利用することができる。このためには、次のようにレジストリ値を変更する。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer |
![]() | |
値の名前 | Enabled |
型 | DWORD |
値の内容 | 0x0 (0x1はONの状態となっている) |
![]() | |
NTPサーバ機能を無効にする設定 |
NTPクライアントのみを利用する環境では、参照先NTPサーバから必要時に時刻同期が行われていれば、それ以上に要件を求められないことが少なくないので、こういったときには、必要な一定時間間隔で時刻同期を行わせればいいだろう。この場合、NTPServerレジストリ値を0x1モードで動作させ、SpecialPollIntervalレジストリ値に必要な秒数を設定させればよい。
項目 | 内容 |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Parameters |
![]() | |
値の名前 | NTPServer |
型 | REG_SZ |
値の内容 | <NTPサーバのIPアドレス>,0x1 |
![]() | |
キー | HKEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient |
![]() | |
値の名前 | SpecialPollInterval (ポーリング間隔) |
型 | DWORD |
値の内容 | 0xe10 (単位は秒。0xe10秒=3600秒=1時間) |
![]() | |
一定時間間隔でNTPサーバに同期するための設定 |
上記Enabledレジストリ値の設定を0x0とした場合、NTPプロトコルの同期方法はNTPServerレジストリ値の第2パラメータの値によらず、すべてClient/Serverモードで同期されるため、時刻同期についての問題が発生することは、通常よりは少なくなるだろう。
なお、LinuxのNTPクライアント・アプリケーションとしてntpdateというコマンドがある。これは上記と同じく、指定したNTPサーバから強制的に時刻同期を行わせるコマンドである(オプションによりslewモードで同期させることもできる)。ただしWindows Timeサービスとは異なり、デーモン(サービス)ではないため、定期的に同期させるためには、cron(Windowsのタスク・スケジューラに相当する機能)を利用して繰り返し実行させる必要があるだろう。
本稿では、Windows Timeサービスを利用した時刻同期について述べてきたが、実はWindows NTベースで動作するntpd互換プログラムが以前から存在し、多くのユーザーに利用されている。入手方法は以下のWebページを参照いただきたい。
このプログラムはUNIX上で動作するntpdなどのNTPプログラムを移植した内容であるため、ほぼUNIX上のものと同様に動作する。UNIXやLinux環境にWindowsを投入した際の時刻同期に関する問題が起こりにくく、使い勝手がUNIX上のそれと同様なため、UNIX管理者を中心に重宝されるプログラムである。
このプログラムはWindows上ではサービスとして登録したうえで利用することとなるが、Windows Timeサービスが動作している環境では、そのままでは利用ポートが衝突してしまい、サービスが動作しない。そのためこのプログラムを利用する際には、Windows Timeサービスを事前に停止させておく必要がある。
Windows XPおよびWindows Server 2003上のWindows Timeサービスは機能が拡張され、UNIX/LinuxのNTP環境に組み込んで利用することもある程度は可能となった。このプログラムが実装される以前は、同様の実装が必要であれば、移植版のntpdを導入するより方法がなかったことを考えれば、こういった実装が組み込まれたことは、システム管理上非常に有用と考えられ、大いに歓迎すべきことである。
ただしマイクロソフトでは、Windows Timeサービスを、ドメイン環境での利用に最適化した実装を行っているようにも見受けられ、その設定を管理者自身がきちんと把握/構成するには、NTPプロトコルの実装に沿った形でマイクロソフトの資料を読み下す必要がある。そのうえで、調査と検証を行う必要があることを考えると、Windows Timeサービスを自由自在に取り扱いたいと考えるなら、それなりの心構えと準備が必要となるだろう。
また、マイクロソフトのサポート技術情報にあるように、OSリリース時のWindows Timeサービスはいくつかの不具合を抱えているため、機能を正常に使うためには、どうしても最新のサービスパックないしは必要な修正プログラムを適用させなければならない。最新のサービスパックや修正プログラムを適用することがちゅうちょされる環境であれば、相応に実績のある移植版のntpdなどを利用する手法も検討されてよいだろう。