Windows Server の時刻が 2025年1月以降まったく同期されない状態を放置すると、Kerberos 認証エラー、ログの時刻ズレ、証明書や署名の検証失敗など、ドメイン全体に波及するトラブルへ発展しがちです。この記事では、対象サーバーが Active Directory ドメイン コントローラーで PDC エミュレーター役割を持つ前提で、W32Time（Windows Time サービス）の設定・復旧手順と、失敗しやすいポイントの切り分けまでをまとめます。
時刻同期が止まると何が困るのか（症状の具体例）
「時刻の同期ができていない」問題は、単に時計がズレるだけではありません。特に Active Directory ドメインでは、時刻の整合性がセキュリティ機構の前提になっています。代表的な影響は次のとおりです。
- Kerberos 認証が失敗する（既定の許容差は数分程度。ズレが大きいとログオンや共有アクセスが不安定になる）
- ドメイン参加・GPO 適用・レプリケーションなどで断続的なエラーが出る
- イベントログのタイムスタンプが信用できず、障害調査が難航する
- 証明書の有効期間（NotBefore/NotAfter）に引っかかり、TLS 通信や署名検証が失敗する
- バックアップ・監視・ジョブスケジューラの実行時刻が狂い、二次障害に繋がる
「2025年1月以降ずっと同期されていない」という状況は、ズレが蓄積している可能性が高いので、まずはドメイン内の“時刻の親”を正し、その後に末端へ波及させるのが最短ルートです。
Active Directory の時刻同期の仕組み（PDC エミュレーターが基準）
ドメイン環境では、時刻同期は階層構造になっています。重要なのは、PDC エミュレーター（PDC）役割を持つドメイン コントローラーが、事実上の「時刻の基準」になる点です。
基本方針は次のとおりです。
- フォレスト ルート ドメインの PDC：外部（信頼できる NTP サーバー）と同期する
- 同一ドメイン内の他の DC：ドメイン階層（通常は PDC）から同期する
- メンバーサーバー／クライアント：ドメイン階層から同期する
| 役割 | 推奨する同期元 | よく使う設定（概要） | やりがちなミス |
|---|---|---|---|
| フォレスト ルートの PDC エミュレーター | 外部 NTP（社内標準／ISP推奨／公的） | W32Time を NTP モード、信頼できる時刻ソースとして告知 | 外部 NTP に出られない（FW/ルーティング/DNS）まま放置 |
| 同一ドメイン内の他 DC | ドメイン階層（通常は PDC） | NT5DS（ドメイン階層） | 各 DC をバラバラの外部 NTP に同期させてズレが拡散 |
| メンバーサーバー／クライアント | ドメイン階層 | 自動（通常は触らない） | ローカルで NTP を固定してドメインとズレる |
今回の状況（対象が PDC の可能性が高い）では、まず PDC が外部 NTP と正しく同期できる状態を作ることが最優先です。PDC が正しくなれば、ドメイン内の他の端末は通常の階層同期で自然に揃っていきます。
作業前のチェックリスト（原因の当たりを付ける）
いきなりレジストリを触る前に、最低限ここだけは確認しておくと、復旧が速くなります。特に「実は PDC じゃなかった」「外部 NTP に通信できていなかった」の見落としが多いです。
| 確認項目 | コマンド／場所 | 正常の目安 | 異常の例 |
|---|---|---|---|
| PDC エミュレーターか | netdom query fsmo | PDC がこのサーバー名になっている | 別サーバーが PDC（役割移動済み） |
| 現在の同期元（時刻ソース） | w32tm /query /source | 外部 NTP 名が出る（PDCの場合） | Local CMOS Clock / VM IC Time Synchronization Provider 等 |
| W32Time サービスの状態 | sc query w32time | RUNNING（動作中） | STOPPED、または無効化 |
| タイムゾーン設定 | 設定画面／tzutil /g | 運用の想定どおり（例：Tokyo Standard Time） | タイムゾーンが別地域になっている |
| NTP 宛の通信可否 | w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly | 遅延(ms)が表示される | タイムアウトや名前解決失敗 |
| FW / NW機器で UDP 123 が通るか | Windows Firewall / 社内FW | UDP 123 が許可 | 2025年1月頃に FW 変更、以後ブロック |
| 仮想環境の「時刻同期」機能 | Hyper-V / VMware の設定 | PDC ではホスト同期が干渉しない | ホスト時刻に引っ張られて NTP と競合 |
ここで「PDC ではない」ことが判明した場合、この記事の“PDC向け設定”を入れると、ドメインの時刻階層を壊すことがあります。PDC 以外の DC／メンバーサーバーは、基本的にドメイン階層（NT5DS）に戻すのが先です（後半で戻し方を解説します）。
PDC エミュレーターで外部 NTP と同期させる復旧手順（レジストリ編）
ここからは「対象が PDC エミュレーターである」前提で、W32Time を外部 NTP 同期へ戻す手順です。レジストリ変更を伴うため、事前にバックアップ（システム状態／レジストリのエクスポート等）を取ってから進めてください。
設定全体のゴール
- PDC が外部 NTP を参照して自分の時刻を正す
- PDC がドメイン内へ「自分が信頼できる時刻ソースである」ことを告知する
- ドメイン内の他の DC／クライアントは、通常の階層同期で PDC に追従する
レジストリで変更する主要項目一覧
どこを何にするのかが見えると安心して作業できます。以下は今回触ることが多い値の一覧です。
| キー | 値名 | 設定例 | 意味／狙い |
|---|---|---|---|
| HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters | Type | NTP | PDC が外部 NTP と同期するモードにする |
| HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config | AnnounceFlags | 0xA | このサーバーを信頼できる時刻ソースとして告知しやすくする |
| HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer | Enabled | 1 | NTP サーバー機能（配布側）を有効にする |
| HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient | Enabled | 1 | NTP クライアント機能（取得側）を有効にする |
| HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters | NtpServer | time.windows.com,0x1 time.nist.gov,0x1 0.pool.ntp.org,0x1 | 参照する外部 NTP を指定する |
| HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config | MaxPosPhaseCorrection | 3600（例） | 進む方向の補正許容値（秒） |
| HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config | MaxNegPhaseCorrection | 3600（例） | 遅れる方向の補正許容値（秒） |
補足として、NtpServer 値に付ける 0x1 は「SpecialPoll（一定間隔でのポーリング）」として扱う構成でよく使われます。環境によっては 0x9（0x1 と 0x8 を併用）などが使われることもありますが、まずは社内標準の指定があるかを優先してください。
手順：Type を NTP に変更する（PDC を外部同期モードへ）
- レジストリエディター（regedit）を管理者権限で起動します。
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters を開きます。
- Type をダブルクリックし、値のデータを NTP に変更します。
この設定が「PDC はドメイン階層（NT5DS）ではなく、外部 NTP を見に行く」という意味合いの核になります。
手順：このサーバーを権威あるタイムサーバーとして扱わせる
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config を開きます。
- AnnounceFlags を 0xA に設定します。
AnnounceFlags は「このサーバーが時刻ソースとしてどう振る舞うか」に影響します。PDC がドメイン内の基準になる以上、ここが曖昧だとクライアント側が別のソースを参照したり、階層が不安定になったりします。
手順：NTP サーバー機能（配布側）を有効にする
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer を開きます。
- Enabled を 1 に設定します。
PDC は「自分が外部同期する」だけでなく、「ドメイン内へ時刻を配る」側でもあります。ここが無効化されていると、PDC は同期していてもドメイン全体に広がりにくくなります。
手順：NTP クライアント機能（取得側）も有効にする
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient を開きます。
- Enabled を 1 に設定します。
稀に、ハードニングや誤設定で NtpClient 自体が無効になっているケースがあります。この場合、NtpServer を有効にしても「外部へ取りに行けない」ので復旧しません。
手順：外部 NTP サーバーを指定する
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters に戻ります。
- NtpServer を編集し、参照したい NTP を設定します。
設定例：
time.windows.com,0x1 time.nist.gov,0x1 0.pool.ntp.org,0x1運用上のポイント：
- 複数指定しておくと、片方が落ちても同期が継続しやすい
- 社内に NTP サーバー（GPS 受信機や NTP アプライアンス）があるなら、まずそれを優先する
- 名前解決が不安定な環境では、暫定的に IP アドレス指定で切り分けするのも有効
- pool.ntp.org を使うなら、地域に合わせた pool（例：jp.pool.ntp.org 系）を検討するとレイテンシが安定しやすい
手順：時刻補正の許容範囲を見直す（大きくズレている環境向け）
「2025年1月以降ずっと同期されていない」なら、数分どころか数時間単位でズレている可能性があります。W32Time は設定によっては“大きなズレを補正しない”動作になるため、復旧時はここがボトルネックになりがちです。
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config を開きます。
- MaxPosPhaseCorrection（進む方向）と MaxNegPhaseCorrection（遅れる方向）を適切に設定します。
| 目的 | 設定例（秒） | 考え方 | 注意点 |
|---|---|---|---|
| 復旧を最優先（ズレが大きい可能性） | 86400（24時間）〜 172800（48時間） | まずは同期させて正しい時刻へ戻す | 復旧後に、運用ポリシーに沿って見直す |
| 通常運用（大きな跳ねを避けたい） | 3600（1時間）など | 急激な時刻ジャンプを抑制する | ズレが大きい状態だと同期が成立しないことがある |
復旧段階では大きめに許容し、同期が安定してから必要なら絞る、という二段階にすると失敗しにくいです。
サービス再起動と同期の強制（必ず実施）
レジストリを変更しただけでは、W32Time が古い設定のまま動いていることがあります。サービスの再起動と明示的な再同期までセットで実行してください。
Windows Time サービスの再起動
net stop w32time
net start w32time時刻同期の手動実行
w32tm /resync /nowait同期状態の確認（最低限ここまで）
w32tm /query /status
w32tm /query /source
w32tm /query /peers確認時に見るべきポイントは次のとおりです。
- /query /source が外部 NTP（指定した名前）になっているか
- /query /status の「Last Successful Sync Time（最終成功時刻）」が更新されるか
- Stratum が極端におかしくないか（常に 16 のまま等は未同期のサイン）
「同期できているか」をもう一段確実にする検証方法
見た目上は同期しているようでも、実際は参照先が変わっていない／一定時間後に落ちる、というケースがあります。次の確認で「通信できているか」「ズレが収束しているか」を確認します。
NTP へ到達できているか（stripchart）
w32tm /stripchart /computer:time.windows.com /samples:10 /dataonlyタイムアウトせず、差分が数十ms〜数百ms程度で揺れるのは一般的です（回線品質や距離で変動します）。ここがまったく返らない場合、DNS／FW／ルーティングの問題を疑います。
ドメイン内の複数機でズレを俯瞰する（monitor）
w32tm /monitorドメイン内の DC 間で大きなオフセットが出ている場合、PDC 以外の DC が別ソースに引っ張られている、仮想基盤の時刻同期が干渉している、などが典型です。
イベントログ（W32Time）の確認
コマンドで状況が掴めないときは、イベントログが一番確実です。
- イベント ビューアー → Windows ログ → システム
- ソース（例）：Time-Service / W32Time などでフィルター
「NTP サーバーに到達できない」「同期できない理由」が文章で出るため、切り分けが一気に進みます。
よくある失敗パターンと切り分け（2025年1月以降止まったケースで多い順）
| 症状 | 原因の候補 | 確認方法 | 対処 |
|---|---|---|---|
| /query /source が Local CMOS Clock のまま | Type が NTP になっていない／設定反映前 | w32tm /query /configuration | Type を NTP、サービス再起動、/resync |
| /resync しても「同期できない」系のメッセージ | UDP 123 がブロック／NTP へ出られない | w32tm /stripchart ... | FW/NW機器で UDP 123 を許可、DNS 解決確認 |
| 一瞬同期するが、しばらくするとズレる | 仮想基盤の時刻同期が干渉（ホスト時刻に上書き） | /source が VM IC Provider などになる | PDC では仮想基盤の時刻同期機能を見直す |
| ズレが大きすぎて同期しない | 補正許容範囲が小さい／ポリシーで制限 | MaxPos/MaxNeg を確認 | 復旧時は許容値を大きく、必要なら手動で概ね合わせてから再同期 |
| 2025年1月頃から急に止まった | ネットワーク変更、FW更新、DNS変更、GPO変更 | 変更履歴／イベントログ | まず通信経路と名前解決を復旧し、次に W32Time 設定を整える |
| 対象が PDC ではなかった | FSMO 役割が別 DC に移っている | netdom query fsmo | 本当の PDC に外部 NTP を設定し、対象は NT5DS へ戻す |
PDC 以外だった場合：ドメイン階層（NT5DS）へ戻す手順
「このサーバーが PDC だと思っていたが違った」場合は、まず正しい PDC を特定し、そちらに外部 NTP を設定してください。対象サーバー（PDC ではない DC／メンバーサーバー）は、基本的にドメイン階層から時刻を取る設定（NT5DS）に戻します。
コマンドでドメイン階層同期に戻す（推奨）
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time
w32tm /resync /nowait戻ったか確認
w32tm /query /source
w32tm /query /statusPDC 以外では、/source がドメイン内の上位（多くは PDC）を指す形になれば概ね OK です。
外部 NTP がどうしても使えないときの現実的な落としどころ
セキュリティ要件やネットワーク設計で「サーバーからインターネットへ UDP 123 を出せない」環境は珍しくありません。その場合は、次のいずれかを検討します。
- 社内ネットワーク上に NTP 中継（内部 NTP サーバー） を立て、PDC はそこへ同期する
- 境界で NTP を許可するのが難しいなら、監視・運用チームと合意できる“時刻の出どころ”（閉域内の基準）を設ける
- どうしても外部と切り離すなら、少なくともドメイン内だけは PDC を基準に揃えて、Kerberos の安定性を優先する
この場合でも、PDC が「信頼できる時刻ソースとして告知する」設定（AnnounceFlags 等）は意味があります。
復旧後にやっておくと強い：再発防止の運用ポイント
NTP サーバーは複数指定し、優先順位と冗長性を持たせる
単一の NTP に依存すると、相手が落ちた瞬間に同期が止まります。社内標準がない場合でも、最低 2〜3 個は指定しておくと安定します。
監視に組み込む（「ズレの検知」と「同期できていない検知」を分ける）
監視は「時刻がズレている」と「同期が成立していない」を分けると、誤検知が減ります。たとえば次の観点です。
- w32tm /query /status の最終同期時刻が一定時間更新されない
- イベントログに W32Time のエラーが継続して出ている
- ドメイン内の代表サーバー同士で時刻差が閾値を超えた
PDC が仮想環境の場合は「ホスト同期」との競合に注意
Hyper-V や VMware などの仮想化基盤には「ホストとゲストの時刻を合わせる」機能があります。一般的なゲストでは便利ですが、PDC はドメインの基準になるため、外部 NTP と競合して時刻が不安定になることがあります。PDC が仮想で運用されている場合は、仮想基盤側の時刻同期ポリシーを一度見直してください（ただし、基盤や運用ルールによって最適解は変わるため、むやみに一律オフにせず“競合しているか”を事実ベースで確認するのが安全です）。
最終チェック：復旧できたと言い切れる状態
最後に、次の条件を満たしていれば「同期が復活した」と判断しやすいです。
- PDC の w32tm /query /source が外部 NTP を指している
- PDC の w32tm /query /status の最終同期時刻が更新される
- ドメイン内の他 DC／メンバーが ドメイン階層（PDC 方向） を時刻ソースとしている
- ドメイン内の主要サーバー間の時刻差が、運用上許容できる範囲に収束している
- W32Time のイベントログに継続的なエラーが出ていない
もし PDC 側を直してもドメイン内のズレが残る場合は、「他の DC やサーバーが独自 NTP に固定されている」「仮想基盤の時刻同期が残っている」「GPO で W32Time を上書きしている」など、末端側の要因が残っていることが多いです。まずは PDC の基準を固め、次に“例外設定になっている端末”を潰していく順序が最も安全です。
コメント