Windows Serverの時刻が同期しないときは、PDCエミュレーターかどうかと、実際の同期元・最終成功時刻を確認します。ADではすべてのサーバーへ外部NTPを設定するわけではありません。レジストリをまとめて変更する前に、フォレストルートのPDC、その他のドメイン参加端末、スタンドアロンを分けてください。
Active Directoryの時刻同期とPDCの役割
通常、ドメイン参加端末はNT5DSでドメイン階層に従います。階層の最上位となるフォレストルートドメインのPDCエミュレーターは、組織が承認した外部または上位の時刻源へ同期する構成を検討します。単に「DCだから」「PDCの名前が出たから」とすべてを手動NTPへ変更しないでください。
| 対象 | 基本の確認方向 |
|---|---|
| フォレストルートのPDCエミュレーター | 設計された上位時刻源と配布状態 |
| それ以外のドメイン参加端末・DC | ドメイン階層、管理ポリシー、想定の同期元 |
| スタンドアロン端末 | その環境で指定された時刻源 |
| 仮想マシン | ゲストのW32Timeとホスト側の時刻供給設定 |
タイムゾーンが違う表示と、UTCとしての時刻がずれている状態も別です。タイムゾーンを変えて見た目だけ合わせても、同期障害の修復にはなりません。認証やログの前後関係に影響するため、変更前の状態を記録します。
最初に実行する読み取りコマンド
管理者の端末で実行します。各結果を同じ日時の記録として残してください。
netdom query fsmo
w32tm /query /source
w32tm /query /status
w32tm /query /configuration
w32tm /query /peers
sc.exe query w32time
tzutil /gnetdomはADの管理ツールが必要な場合があります。フォレスト全体のPDCを確認するときは、現在のドメインで表示されたPDCがフォレストルートのものかも確認します。取得できないからといって、その端末をPDCと推定しないでください。
| 出力 | 読み方 |
|---|---|
| Source | 現在選択されている時刻源。設定した候補一覧とは別 |
| Last Successful Sync Time | 最後に成功した時刻。更新が止まっていないか |
| Type / NtpServer / 設定元 | NT5DSかNTPか、ローカルかポリシー由来か |
| Peerの状態 | 候補の認識状態。全候補が採用されるわけではない |
| Local CMOS Clock等 | 意図した上位時刻源かを確認。外部同期成功とは扱わない |
UDP 123とstripchartの結果を混同しない
NTPの通信はUDP 123を使います。TCPポートの疎通確認だけではNTPの成功は分かりません。ファイアウォール・NAT・上位サーバー側のアクセス条件を確認し、対象ホストと送受信方向をそろえます。
w32tm /stripchart /computer:ntp01.example.com /samples:5 /dataonlyntp01.example.comは説明用です。組織で承認された実際のNTP名へ置き換えます。stripchartは一時的なUDP送信元ポートを使い、通常のW32Timeクライアントは送信元UDP 123を使います。そのためstripchartだけ成功しても、サービス本体の経路が通っている証拠にはなりません。
設定変更は役割とポリシーを確認したあとに行う
上位時刻源の変更が必要なフォレストルートPDCでは、現在の設定を保存し、管理ポリシーと整合する方法で変更します。次は承認済みの時刻源を指定する構文例で、そのまま全端末へ配るものではありません。
w32tm /config /manualpeerlist:"ntp01.example.com,0x8 ntp02.example.com,0x8 ntp03.example.com,0x8" /syncfromflags:manual /update名前は必ず実際の設計値へ置き換えます。0x8はクライアントモードの指定です。信頼できる時刻源として広告する設定、サーバー機能、ポーリング間隔は役割と運用設計に応じて決めます。AnnounceFlagsの特定値を入れれば、未同期の時計が正確になるわけではありません。
一般のドメイン参加クライアントを手動指定から階層へ戻す場合には、w32tm /config /syncfromflags:domhier /updateという方法があります。ただし対象と設定元を確認し、適用されるGPOで上書きされるなら管理元で修正します。フォレストルートPDCへ無条件に適用しないでください。
再同期要求の後に、成功したことを確認する
変更内容に応じて公式手順でサービス再起動等を行い、影響を確認して再同期を要求します。再起動は監視や稼働条件を考慮して実施してください。
w32tm /resync /rediscover
w32tm /query /status
w32tm /query /source/nowaitを付けたコマンドは同期完了を待たず戻ります。コマンドが受理されたことを成功判定に使わず、Source、最終成功時刻、時刻差、イベントを確認します。失敗コードが出たら、その時刻と前後のW32Timeログを残して原因へ戻ります。
大幅な時刻ずれを強制補正する前に
MaxPosPhaseCorrectionやMaxNegPhaseCorrectionを、1日以上の値へ一律に広げる復旧方法は避けます。大きな時刻移動は認証、証明書、データベース、ジョブ、監査ログへ影響します。正しい時刻源の確認、アプリ担当との調整、作業時間帯と復旧方法を決めてから修正してください。
再同期を繰り返しても変わらない場合は、補正制限だけを疑わず、名前解決、通信、サーバーのNTP応答、グループポリシー、仮想化基盤からの時刻供給を順に確認します。過去の特定月から停止したというだけで、広域のWindows障害とは断定できません。
外部NTPが使えない環境
閉域では、組織が用意する内部の信頼できる時刻源を設計します。外へ出られないという理由だけで未同期のローカル時計を基準として配布すると、ドメイン全体が同じ誤った時刻へ寄る可能性があります。可用性と精度の要件を決め、監視する対象を明確にしてください。
復旧後に監視すること
- 時刻差と最終同期成功からの経過時間を、別々に監視する。
- PDCの役割移動後、上位同期先と広告設定が設計どおりか確認する。
- 候補時刻源の停止時にも、想定どおり継続できるか変更計画内で確認する。
- 仮想化基盤・GPO・更新で設定が変わった場合は差分を記録する。
- 複数端末の認証やログ時刻まで確認し、設定値だけで完了扱いにしない。
構文と設定の意味はWindows Timeのツールと設定、階層と選択の考え方はWindows Timeサービスの仕組みを参照してください。
コメント