Microsoft-Windows-Time-ServiceのイベントID 129は、時刻同期の相手となるドメインピアを設定できなかった記録です。最初に確認するのは、ログのソースと本文、同期先の構成です。このログ単独で原因を断定できないため、すぐにファイアウォールやレジストリの設定を変えないでください。
この記事は、MicrosoftのWindows Server向け資料に載っているドメイン環境の例を扱います。個人用Windows 11のワークグループ環境でも同じ原因・対処になる、という説明ではありません。
Time-Serviceの129が意味すること
参照資料には、手動の時刻同期でデータを利用できず、再同期できなかった場面が示されています。そこで記録されるイベント例の1つが、Microsoft-Windows-Time-Serviceの129です。
イベント本文の NtpClient was unable to set a domain peer という部分は、NtpClientが時刻同期先として使うドメインピアを設定できなかったことを表しています。資料の例では、その理由として探索時のエラーが記録されています。
129は他のソースにも使われ得る番号なので、「129が出た」という情報だけでこの記事の手順を選ばないでください。ここで扱うのはTime-Serviceの記録であり、ディスクや別のドライバーが出す同じ番号のイベントではありません。
全般・詳細を読む前に、129と134を分ける
Microsoftの資料に掲載された129の例は、ログ名が System、ソースが Microsoft-Windows-Time-Service、レベルが Warning です。手元の表示とこの組み合わせを照合し、発生時刻とイベント全文を保存します。
資料の例には 0x800706E1 が載っています。ただし、手元のイベントにも同じ値が入ると決めつけず、実際に表示されたエラーコードを記録してください。詳細タブのXMLを共有する場合も、コードやコンピューター名を別のイベントから取り違えないことが重要です。
同じ資料には134の例も掲載されています。こちらは手動設定された同期先についてのDNS名前解決エラーで、例のコードは 0x80072AF9 です。129のドメインピアの探索失敗と、134のDNSエラーを同じものとして扱うと、最初からDNS設定だけに調査を絞ってしまいます。
資料中のコンピューター名やユーザー名はログの一例です。すべての環境で同じ値になるわけではありません。番号とソースを確認したうえで、自分の環境の本文を読む順番にします。
原因の候補は、同期先・通信・サーバー側の3方向
Microsoftは、時刻同期要求に対する適切なNTP応答を得られない状況について、複数のシナリオを示しています。これは129の番号だけから原因を決定する表ではありません。イベント本文や調査結果を、次のどの確認へつなげるかを整理するものです。
| 確認したい状況 | 確認するもの | その情報で分かる範囲 | 次に依頼する調査 |
|---|---|---|---|
| 同期先を見つけられない | 設定されたNTPサーバー名・IPアドレス、DNS構成 | 設定の誤記や名前解決の問題がないか | 正しい同期先を管理者と確認する |
| NTPの応答が得られない | UDP 123の要求と応答を含む通信記録 | 要求が送られていないのか、送信後に応答がないのか | 通信を止めている箇所を確認する |
| 同期先が時刻サーバーとして応答しない | ドメインの時刻同期階層と各DCの同期状態 | 同期先側の状態に調査を進める必要があるか | ドメイン管理者が上流から確認する |
「応答がないからUDP 123を開放する」とは、まだ決められません。送信側、途中の通信、同期先の状態を分けて確認する必要があります。
設定を変えずに残す情報と、管理者が行う調査
同期先の設定を照合する
まず、現在どこを同期先として使う構成なのかを管理者に確認します。参照資料は、NTPServerの設定値についてサーバー名やIPアドレスの正確さを確認し、対象名を解決できるDNS構成か調べるよう案内しています。
ここではレジストリの書き換え手順は載せていません。ドメイン全体の構成を確認する前に、端末ごとに別の同期先へ変更すると、元の設定で何が起きていたかを追いにくくなります。問い合わせには、現在値と正しい構成のどちらが確認済みかも添えてください。
通信記録は「要求が出ているか」「応答があるか」を分ける
資料はUDP 123の通信を取得し、NTP要求と応答を見る方法を示しています。要求が見えない場合と、要求は出ているが応答が戻らない場合では、調べる場所が異なります。ただし、その観測だけで特定の機器が原因と確定するわけではありません。
資料中の w32tm /resync /rediscover は、時刻の再同期を要求する操作です。読み取りだけの診断コマンドではないため、この記事では確認用としてそのまま実行するようには案内しません。実施するなら、時刻同期の操作を行ってよい環境かを管理者が確認し、通信の記録と組み合わせて判断する段階です。
ファイアウォール全体を無効化する手順や、根拠を確認せずに送受信の許可ルールを足す手順も載せていません。調査のために必要な操作は、対象機器の管理者と範囲を決めます。
ドメインコントローラー側は、時刻同期の上流から見る
同期先がドメインコントローラーの場合、公式資料はPDCから始めて時刻同期の階層を確認し、各DCが同期元から時刻を受け取れているか調べるよう案内しています。
その確認後に、DCとしての通知状態や設定値を調べる流れです。ある診断が不合格だったという理由だけで、掲載されたレジストリ値へ一律に書き換える流れではありません。この記事ではDCの設定変更やサービス再起動の実行手順を省き、公式資料と組織の構成に基づく管理者の作業に分けています。
相談時は、番号だけでなく「どこまで確認済みか」を渡す
利用者側で管理権限や構成情報がない場合は、イベント全文、発生日時、実際の時刻ずれ、同期先の確認状況をまとめて管理者へ渡します。129と134がある場合は、両方の本文を別々に残してください。
変更が必要になった場合も、まず対象範囲と影響を確認し、現在の設定やバックアップ、戻し方を管理者が確かめてから進めます。同期要求が1回成功しても、それだけで元の原因が一時的だったと確定するわけではありません。実際の時刻同期と、その後のイベントの状況をあわせて確認する必要があります。
参考情報
- Microsoft：w32tm /resyncで時刻データを利用できず再同期に失敗する問題 — Windows Serverを対象とする公式資料。129・134のログ例と、同期先・UDP 123・時刻同期階層の切り分けを参照しました。