Windows Server 2008 R2 の旧ドメインコントローラー（旧DC）から Windows Server 2012 の新DCへ移行する場面で、net time や w32tm を見ると「まだ旧DCを参照している」ように見えて不安になることがあります。旧DCを降格（demote）しても影響が出ないか、新PDCが旧PDCを見ているように見える理由、VPN拠点端末の切り分けまで、実務目線で整理します。
結論：端末が NT5DS（ドメイン階層）なら、旧DC降格後も自動で同期先は切り替わる
最初に結論です。ドメイン参加クライアント／メンバーサーバーが 時刻同期方式（Type）が NT5DS で動作しているなら、Windows Time サービス（W32Time）は ドメイン階層（domhier）に従って自動的に別のDCへ同期先を選び直す ため、旧DCを降格しても通常は致命的な問題になりません。
一方で、次のような状態が混ざっていると、旧DCを降格した瞬間から同期失敗が続き、Kerberos エラーやログオン失敗、証明書・ファイルサーバー接続の不調などに波及することがあります。
- 端末やサーバーが 固定NTP（manualpeerlist） で旧DC名／旧IPを指定している
- 新PDCエミュレーターが 外部NTPに正しく同期できておらず、結果としてドメイン内の別DC（旧DCなど）を参照している
- VPN拠点から UDP 123（NTP） が遮断されている／DNS が適切に引けていない
つまり「旧DCを降格しても大丈夫か？」の答えは、“端末が NT5DS で、PDC だけが外部同期できている状態” を作れているかで決まります。
まずは整理：Active Directory の時刻同期は「階層構造」で動く
AD環境の時刻同期は、ざっくり言うと「ドメイン全体の基準時計があり、そこから下流へ配る」構造です。Windows の認証（Kerberos）は時刻ずれに厳しく、一般的に 5 分程度の差でログオンやサービスチケット取得に失敗し始めます。DC移行のタイミングは、サーバー構成が変わるだけでなく “ドメインの基準時計（PDCエミュレーター）” が変わるので、ここを外すと影響が大きくなります。
| 役割 | 推奨される同期方式 | 主な同期先 | ポイント |
|---|---|---|---|
| ドメイン参加クライアント（Windows 10/11 など） | NT5DS | 同一ドメインの任意のDC（自動選択） | “固定NTP”にしないのが基本。ADサイトにより近いDCが選ばれやすい。 |
| メンバーサーバー（ファイル/アプリ/DBなど） | NT5DS | 同一ドメインの任意のDC（自動選択） | 本番サーバーほどGPOで設定ブレを潰す価値が高い。 |
| ドメインコントローラー（PDC以外） | NT5DS（domhier） | PDCエミュレーター（実質的にPDCへ収束） | “自分で外部NTPを見ない”のが基本。上位（PDC）に追従する。 |
| PDCエミュレーター（ドメインで1台） | NTP（manual） | 外部NTP（NTPアプライアンス／上位時計／社内NTP） | ドメインの基準時計。外部同期できないとドメイン全体が不安定になる。 |
この構造を前提にすると、旧DC降格前に不安を消すためにやるべきことはシンプルです。
- 新PDCエミュレーターが外部NTPに同期できている（そして reliable 扱いになっている）
- それ以外のDCと端末は NT5DS（固定NTPをやめる）
時刻ずれが引き起こす具体的なトラブル例
「時刻同期は後で直せばいい」と軽く見られがちですが、AD環境では時刻がズレると影響が連鎖します。旧DC降格前の不安を“根拠を持って”解消するために、代表的な影響範囲を押さえておきます。
| 症状 | 現場での見え方 | 根本原因として多いもの | 優先度 |
|---|---|---|---|
| ドメインログオン／Kerberos 認証失敗 | ログオンできない、資格情報が拒否される、サービス起動に失敗 | クライアントとDCの時刻差が許容範囲を超過 | 高 |
| ファイルサーバー/共有アクセスの不安定 | 時々アクセス拒否、再接続で直る | Kerberosチケットの検証失敗、時刻差によるセッション不整合 | 高 |
| 証明書/HTTPS/署名のエラー | 証明書が期限切れ扱い、署名検証に失敗 | 端末時刻が未来/過去に寄っている | 中 |
| 監査ログや運用ログの時系列が崩れる | インシデント調査が困難、相関が取れない | 端末ごとに時計が割れている | 中 |
| ジョブスケジューラ/バッチの実行が前後する | 実行時刻がズレる、二重実行に見える | 各サーバーがバラバラな時刻基準で動く | 中 |
イベントログでの確認ポイント：W32Time の“失敗連発”を見逃さない
コマンドだけだと「いまはたまたまOK」に見えることがあります。降格前後は、イベントビューアで W32Time（Windows Time） の警告・エラーを併せて確認すると安心です。
見る場所は、基本的に イベントビューア > Windowsログ > システムです（環境によっては専用ログが出る場合もあります）。フィルターでソースを W32Time に絞ると追いやすくなります。
| 観点 | チェック内容 | 判断のコツ |
|---|---|---|
| 同期成功が定期的に出ているか | 同期完了/時刻修正の情報ログ | 「成功が止まり、失敗だけが増える」状態は危険信号。 |
| 外部NTPへ到達できているか（PDC） | NtpClient の到達不可/再試行の警告 | 外部へ UDP123 が許可されていないと、PDCが内部へフォールバックしやすい。 |
| 急激な時刻修正が発生していないか | 大きな時刻変更の記録 | 急なジャンプはアプリ影響が出やすい。外部同期が不安定なサイン。 |
ポイントは、イベントIDを暗記することではなく、「成功が継続しているか」「失敗が連発していないか」の2点に絞ることです。降格作業の前後は、DC（特にPDC）と、拠点代表端末のログを優先的に確認してください。
仮想環境の落とし穴：ハイパーバイザーの時刻同期と二重取りしない
DC移行と同時に仮想基盤（Hyper-V/VMwareなど）を使っている場合、もう一つよくある罠が “ハイパーバイザー側の時刻同期”です。ゲストOSのW32Timeと、ホスト（または統合サービス）が同時に時刻を触りに行くと、意図しない揺れが出ることがあります。
| 状況 | 起きやすいこと | 実務的な対策 |
|---|---|---|
| DCが仮想マシンで、ホスト同期が有効 | W32Timeが合わせた直後にホストが戻す、などの揺れ | 運用方針として“どちらを正とするか”を決め、DCではW32Time優先に寄せる。 |
| PDCも仮想で、外部NTP同期が不安定 | ドメイン全体がじわじわズレる | PDCの外部NTP疎通（UDP123）と、NTPサーバー冗長（複数指定）を見直す。 |
仮想化の時刻同期は“便利”ですが、ADの基準時計に関しては、設計として一貫性を持たせるのが重要です。特にPDCは、外部NTPに安定して同期できる構成を優先してください。
複数ドメイン/フォレスト環境の場合の補足
単一ドメインなら「PDC＝外部NTP」という整理で十分ですが、フォレスト配下に複数ドメインがある場合は、一般的に フォレストルートドメインのPDCエミュレーターが外部同期し、子ドメインは階層的に追従する設計になります。どのドメインのPDCを外部同期の基準にするかは、環境構成と運用（監査要件、NTPアプライアンスの配置）に合わせて決めてください。
「net time では旧DCに見える」の正体：表示のクセと“途中経過”を理解する
現場でよく起きる誤解が、net time の結果＝「いま同期しているNTPサーバー」だと思い込むことです。実際には net time は用途によって動きが変わり、以下のような“紛らわしさ”が出ます。
- 最後に時刻合わせに使った相手が表示され続ける（次の同期までは更新されない）
- 名前解決やDCロケーターの結果で、たまたま旧DCが選ばれて表示される
- そもそも
net timeはSMB/NetBIOS寄りの文脈で使われ、W32Timeの実状態を見るにはw32tmの方が適している
そのため、旧DC降格判断の材料としては、net time だけを見て結論を出さず、必ず w32tm の情報で“方式（Type）”と“最終同期”を確認するのが安全です。
最初に実施する切り分け：見るべきコマンドと判断ポイント
クライアントでもDCでも、まずは次のコマンドをセットで実行し、スクリーンショットやテキストで残しておくと後から比較しやすくなります。
| コマンド | 目的 | 見るべき項目 | 判断の目安 |
|---|---|---|---|
w32tm /query /source | 現在の時刻ソースを確認 | Source | 端末：DC名ならOK。PDC：外部NTP名（またはNTPアプライアンス名）が理想。 |
w32tm /query /status | 同期状態を確認 | Last Successful Sync Time / Stratum / Leap Indicator | 最終成功時刻が古すぎる、Stratumが異常、などは要調査。 |
w32tm /query /configuration | 同期方式（Type）を確認 | Type / ManualPeerList / SyncFromFlags | 端末・非PDC：Type: NT5DS が基本。固定NTPになっていないかを見る。 |
netdom query fsmo | FSMO役割（PDC含む）を確認 | PDC Emulator | “いま誰がPDCか”が全ての起点。 |
w32tm /monitor | DC群の同期状態を一覧 | Offset / Source | DCが新PDCへ収束しているかを俯瞰できる。 |
w32tm /stripchart /computer:対象 /samples:5 /dataonly | NTP疎通とズレを簡易確認 | 時刻差（ms） | VPN越しで届くか、UDP123が通るかの切り分けに便利。 |
出力例（端末側のイメージ）です。環境により表示は多少異なりますが、注目するのは Type と Source と 最終成功です。
w32tm /query /configuration
[TimeProviders]
NtpClient (Local)
DllName: C:\Windows\system32\w32time.dll
Enabled: 1
InputProvider: 1
CrossSiteSyncFlags: 2
AllowNonstandardModeCombinations: 1
ResolvePeerBackoffMinutes: 15
ResolvePeerBackoffMaxTimes: 7
SpecialPollInterval: 3600
Type: NT5DSw32tm /query /source
DC2012-01.example.localこのように Type: NT5DS になっていれば、“いま旧DCが見えている/いない”よりも 旧DCを消したときに自動で追従できる設計に乗っていることが重要です。
旧DCが表示されるパターン別：原因と対処を早見表で確認する
「旧DCを参照しているように見える」といっても、状況は複数あります。ここを切り分けないまま闇雲に設定変更すると、かえって収束しません。典型例を表にまとめます。
| 症状 | よくある原因 | 確認ポイント | 推奨アクション |
|---|---|---|---|
net time で旧DCが出るが、w32tm は NT5DS | 表示のクセ／次回同期まで旧情報が残る | w32tm /query /configuration の Type | 基本は放置でOK。降格前に不安なら w32tm /resync で更新。 |
w32tm /query /source が旧DC、Typeは NT5DS | たまたまそのタイミングの自動選択先が旧DC | 同一サイトに旧DCが残っていないか | 旧DC降格後は別DCへ自動遷移する想定。急ぐなら /resync /rediscover。 |
| Type が NTP で ManualPeerList に旧DC名/IP | 過去の手動設定、スクリプト、GPOの名残 | ManualPeerList / 適用GPO | GPOで NT5DS に戻す。旧DC降格前に必ず是正。 |
| PDCが旧PDC（旧DC）を Source と表示 | 外部NTP設定が未完了／入力ミス／外部に到達できずフォールバック | PDCの Type、イベントログ、UDP123疎通 | PDCのみ外部NTPを正しく設定し、/reliable:yes。疎通確認も実施。 |
Source が Local CMOS Clock / Free-running System Clock | 同期が失敗して自己時計に退避 | w32tm /query /status の最終成功時刻 | ネットワーク/UDP123/名前解決を確認し、設定を NT5DS（端末）へ戻す。 |
新PDCが旧PDCを見ているように見える理由と、正しい収束先
DC移行のタイミングでよくあるのが「PDC役割は新DCへ移したはずなのに、新PDCが旧DCを見ているように見える」という現象です。これは“変なことが起きている”というより、設定が完成する前の途中経過であることが多いです。
代表的な理由は次の3つです。
- FSMO（PDCエミュレーター）の移行は済んだが、W32Timeの設定はまだ domhier のまま
→ 新PDCがNT5DSのままだと、ドメイン階層のどこか（旧DC含む）を参照する可能性があります。 - 外部NTPの manualpeerlist を入れたつもりが、書式ミスで反映されていない
→ 引用符の付け方、サーバー名の区切り、フラグ（0x8など）の不足で、設定が意図通りになっていないケースが多いです。 - 外部NTPへ到達できず、結果として別のソースへフォールバックしている
→ 社内FWやプロキシ環境で、PDCから外部への UDP 123 が通らないと同期できません。
新PDCの理想形は「外部NTP（または社内NTPアプライアンス）」を Source にしつつ、ドメイン内へ “reliable” な時計として配布する状態です。逆に言うと、PDCだけは例外的に NT5DS のままにしないのが定石です。
推奨の是正手順：PDC・その他DC・クライアントで“やること”を分ける
時刻同期は、全端末に同じ設定を入れるほど危険です。ポイントは 「PDCだけを特別扱い」し、その他はドメイン階層へ戻すことです。
| 対象 | 狙い | 推奨設定 | 備考 |
|---|---|---|---|
| 新PDCエミュレーター（Windows Server 2012） | ドメイン時刻の基準を作る | 外部NTPに同期（Type: NTP）＋ reliable | 外部NTPは社内規約に沿って選定。到達性（UDP123）を必ず確認。 |
| その他DC（旧DC含む） | PDCへ追従 | domhier（Type: NT5DS）へ戻す | “外部を見ない”。PDCへ収束させる。 |
| クライアント／メンバーサーバー | DCへ追従（自動選択） | Type: NT5DS | 固定NTPを残さない。GPOで統制するとブレない。 |
新PDCで実施する代表的なコマンド例
以下は “新PDCが外部NTPを参照する” ための代表例です。外部NTP名は自社ポリシーに合わせて置き換えてください（社内NTPがあるならそれが最優先です）。
netdom query fsmo
w32tm /config /manualpeerlist:"ntp.nict.jp,0x8 0.pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update
net stop w32time
net start w32time
w32tm /resync /force
w32tm /query /source
w32tm /query /statusよくあるミスは manualpeerlist の書式です。カンマ区切りとフラグ（0x8）が欠けている、引用符が途中で切れている、全角スペースが混ざる、などで意図した設定にならないことがあります。設定後は必ず w32tm /query /configuration で反映を確認してください。
その他DC（旧DC含む）で実施する代表的なコマンド例
w32tm /config /syncfromflags:domhier /reliable:no /update
net stop w32time
net start w32time
w32tm /resync /force
w32tm /query /sourceここで 旧DCを含む“その他DC”を domhier に戻すのが重要です。旧DCがまだ稼働している間にこの状態を作っておくと、降格後の混乱が減ります。
クライアント／メンバーサーバーで実施する代表的なコマンド例
単体で手直しするなら以下ですが、台数があるなら後述の GPO を推奨します。
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time
w32tm /resync /rediscover端末側で “旧DC固定” を解除したいのに直らない場合、GPOで上書きされている、または別のスクリプト／運用ツールが定期的に設定を戻していることが多いです。gpresult /r や rsop.msc で適用ポリシーも確認しておくと、再発防止に繋がります。
GPOで統制するのが最終的に一番ラク：設定ブレを無くす設計
“一部端末だけ旧DCを見える”問題は、根っこを辿ると「いつ誰が何を設定したか分からない」状態が原因になりがちです。DC移行は良い機会なので、時刻同期を GPO で統制しておくと、数年後の更改でも同じ悩みを繰り返しません。
代表的なポリシーの場所（OSにより多少表示名が違うことがあります）:
- コンピューターの構成 > ポリシー > 管理用テンプレート > システム > Windows Time Service
- コンピューターの構成 > ポリシー > 管理用テンプレート > システム > Windows Time Service > Time Providers
| 適用対象 | ポリシー設計の考え方 | 設定の方向性 | 注意点 |
|---|---|---|---|
| ドメイン参加端末・メンバーサーバー | “ドメイン階層に任せる”を強制 | NTPクライアント：有効、Type=NT5DS | ここで手動NTPを配ると、将来のDC移行でまた詰む。 |
| ドメインコントローラー（PDC以外） | PDCへ追従させる | NTPクライアント：有効、Type=NT5DS | PDC用の設定と混ぜない。OU分離・WMIフィルター等で切り分け。 |
| PDCエミュレーターのみ | 外部NTPを参照する“例外” | NTPクライアント：有効、Type=NTP、NTPサーバー指定、reliable | PDCが変わる（FSMO移行）と適用先も変わる。運用手順に組み込む。 |
実務では、「Domain Controllers OU」にリンクするGPOと、「PDC専用のGPO」を分け、PDC専用GPOはセキュリティフィルタリング（対象コンピューターのみ）や WMI フィルターで絞る構成が扱いやすいです。
VPN拠点端末が旧DCを指して見えるとき：ルータ設定より先に見るべきこと
「VPNで繋いでいる拠点端末が旧DCを見ている。ルータ側で時刻設定が必要？」という相談は多いのですが、ドメイン参加端末の時刻同期は基本的に 端末の Windows Time サービスが DC と通信して行うため、ルータのNTP設定をいじって解決する話ではないことがほとんどです。
拠点端末が旧DCを見続ける場合、優先度が高いチェックポイントは次の通りです。
| チェック | 狙い | 確認コマンド例 | よくある原因 |
|---|---|---|---|
| DNSがAD DNS（DC）を向いているか | DCロケーターが正しく動く前提 | ipconfig /all | 拠点端末がローカルルータDNSやISP DNSを参照している。 |
| どのDCに割り当てられているか | “近いDC”選択の妥当性 | nltest /dsgetdc:example.local | ADサイト/サブネット未登録で遠隔サイト扱いになっている。 |
| UDP 123 が通るか | NTP通信の疎通 | w32tm /stripchart /computer:DC2012-01 /samples:5 /dataonly | VPNポリシーやFWで UDP123 が落ちている。 |
| 端末が固定NTPになっていないか | 設定起因の切り分け | w32tm /query /configuration | 過去の設定・GPO・スクリプトが旧DCを固定。 |
VPN越しで問題が出るときは、“名前解決（DNS）” と “NTPのUDP123”のどちらかが欠けていることが多いです。逆にここが成立していて Type が NT5DS なら、旧DCが降格されても自動的に新DCへ収束する可能性が高いです。
旧DC降格の前後でやると安心なチェックリスト
「理屈では大丈夫」と分かっていても、降格は怖いものです。事前・事後の確認を“作業手順”として残しておくと、夜間作業でも判断がブレません。
| タイミング | チェック項目 | 確認方法 | OKの目安 |
|---|---|---|---|
| 降格前 | PDCエミュレーターが新DCになっている | netdom query fsmo | PDC Emulator が新DC名 |
| 降格前 | 新PDCが外部NTPに同期できている | w32tm /query /source / w32tm /query /status | Source が外部NTP、最終成功が最近 |
| 降格前 | その他DCが新PDCへ収束している | w32tm /monitor | Source が新PDC相当、Offset が極端でない |
| 降格前 | クライアントが NT5DS である | w32tm /query /configuration | Type: NT5DS |
| 降格直後 | 旧DCのDNSレコードが引けない/古い参照が減る | nslookup 旧DC名 / DNS管理 | 不要なA/SRVが残らない |
| 降格直後 | クライアントが新しい同期先へ遷移 | w32tm /query /source | 別DC名へ変わる（即時でなくても良い） |
| 降格後 | イベントログに同期失敗が増えていない | イベントビューア（System / W32Time） | 失敗が連発しない |
なお、降格直後に“全端末が一斉に新DCへ切り替わる”とは限りません。NT5DS は自動選択なので、端末ごとに次回同期タイミングで順次収束していくイメージです。どうしても急ぐ場合は、対象端末で w32tm /resync /rediscover を実行する、または W32Time サービス再起動で再探索を促す方法があります。
よくある質問
旧DCを降格したら、時刻同期が止まってログオンできなくなりますか？
端末が Type: NT5DS のままなら、同期先は自動で別DCへ切り替わるのが通常です。危険なのは、旧DCを 手動NTPで固定している端末・サーバーです。降格前に w32tm /query /configuration で Type を確認し、固定が混ざっていたらGPO等で是正しておくのが安全です。
PDCだけ外部NTPにするのはなぜですか？ 全部外部NTPにすれば早いのでは？
ドメイン内の時計を “一本化” するためです。全台が外部NTPを見始めると、通信断や外部遅延の影響を各サーバーが個別に受け、ドメイン内で微妙に時刻が割れることがあります。PDCだけを外部同期にして、他はPDCへ追従させると、ドメインとして時刻が揃いやすくなります。
VPN拠点ではルータのNTP設定を変更すべきですか？
ドメイン参加端末の時刻同期の観点では、ルータの時刻設定は基本的に別問題です。優先すべきは 拠点端末のDNS設定と、DCとの UDP 123 の疎通、そして端末の Type が NT5DS になっているかです。
新PDCに設定した外部NTPが正しいか不安です
次の3点をセットで確認すると確度が上がります。
w32tm /query /sourceが外部NTP名になっているw32tm /query /statusの最終成功が更新されるw32tm /stripchartで外部NTPへの疎通とズレが極端でない
社内FWの都合で外部NTPが許可されない環境もあります。その場合は、社内で許可されたNTPサーバー（上位時計、監視対象のNTPアプライアンス等）を使う設計に切り替えるのが現実的です。
まとめ：降格の不安は「Type」と「PDC外部同期」を押さえれば消せる
旧DCを降格する前に net time や w32tm で旧DCが見えると焦りますが、重要なのは「いま一瞬どこを見ているか」よりも、ドメイン階層同期（NT5DS）に正しく乗っているかです。新PDCを外部NTPに同期させ、その他は domhier に戻し、端末設定はGPOで統制する。この形を作れれば、旧DC降格は“時刻同期の観点では”大きなリスクになりにくくなります。
コメント