Windows2000 での時間同期
Windows 2000 Active Directory ドメインでは、ログオン時にドメインに対して自動的にタイム サービス(サービス名：W32Time)がクラスタ構成でも実行されます。なので、Windows NT クラスタで必要だったタイムリソースサービスは不要になります。（逆にタイムリソースサービスが動いていると、CPUなどの資源が使われます。）
また、Windows 2000ドメインの標準機能として、クラスタ サービスのチェックも定期的に行われるので、この情報を利用して定期的にノード間を同期します。
但し、クラスタを構成しているノードのそれぞれが、異なるドメインの場合、それぞれのドメインに時間の同期を取るので、ノード間の時間が異なってくる可能性があります。（通常は、それぞれのノードが異なるドメインと言うことは無いと思いますが。）
Windows 2000 では、新しい時間同期サービスが使用され、Windows 2000 ベースのネットワーク上で動作しているコンピュータの日時が同期されます。デフォルトの認証プロトコル (MIT Kerberos Version 5) が、認証チケット生成プロセスの一部としてコンピュータ時刻を使用するため、Windows 2000 では時刻を同期することは重要になります。
Microsft社曰く、W32Time (Windows Time Synchronization サービス) は、SNTP に完全準拠した実装だそうです。（
NTP ではない ）
W32Time の動き
時刻統一の階層構造
すべてのクライアントは、タイム ソースとして、認証しているドメイン コントローラを選択します。このドメイン コントローラが使用できなくなった場合は、クライアントはドメイン コントローラに対する要求を再発行します。
ドメイン内のすべてのドメイン コントローラは、次の 3 つのいずれかの方法で時間を同期します。
- 親ドメイン内の信頼できるタイム サービス （優先）
- 現在のドメイン内の信頼できるタイム サービス (必須)
- 現在のドメインの PDC 返されたこれらの DC のいずれか 1 つがタイム ソースとして選択されます。
フォレストのルートにある PDC の FSMO(Flexible Single Master Operation Role:Active Directoryドメイン･コントローラのうち１台だけが受け持っている特定の役割) には権限があり、外部のタイム ソース (NTPサーバ)に時間同期の設定をすることができます。但し、時間を合わせるプロトコルがSNTPの為、信頼性が足りないと思われます。
また、FSMOが外部のタイム ソースと同期していない場合、クライアントが UNIX などの NTP クライアントだと、FSMO に上位サーバと時間同期した情報が無い為、クライアント側では信頼できないとしてエラーとしてしまう場合があります。回避策としては
- FSMOサーバの時間同期の上位のサーバとして、自分自身を設定する。
（実際の時間とは、ずれが生じる可能性が高い。）- UNIX などのクライアント側の時間同期するサーバとし FSMO ではなく、その配下の PDC に時間同期させる。（FSMO が時間同期していないため、ドメイン全体として、UTCの時間とは、ずれが生じる可能性が高い。）
- UNIX などの NTP クライアント/SNTP,NTP サーバを立ち上げ、外部のタイム ソースと同期さる。FSMO はその NTP クライアント/SNTP,NTP サーバと同期させる。
（この方法が一番よいかと思います。但し、よくても NTP サーバは Stratum 2、FSMO は Stratum 3 になってしまいますが信頼性は高いかと思われます。私は Stratum 3 のサーバを立ち上げていますが、精度の問題は発生していません。）
参考： Microsoft社 Windows Time サービスの基本処理