Windows Server 2008 R2 の旧ドメイン コントローラー（DC1）から Windows Server 2016 の新ドメイン コントローラー（DC2）へ FSMO を移行したのに、DomainDnsZones の fSMORoleOwner が旧DCを指したまま／w32tm /query /source でも旧DCが返る――。このズレは「5つのFSMO」と「DNSアプリケーション パーティション側の“別枠の役割”」に加え、Windows Time（W32Time）の設定・反映タイミングが絡んで起きます。撤去前に安全に整える手順を、確認コマンド付きでまとめます。
症状の整理：何が“正しくて”、何が“危険信号”なのか
まず、今回の現象は大きく2系統に分かれます。
| 系統 | 代表的な症状 | 結論（要点） |
|---|---|---|
| FSMO表示のズレ | netdom query fsmo は DC2 なのに、CN=Infrastructure,DC=DomainDnsZones,... の fSMORoleOwner が DC1 | 「5つのFSMO」ではなく、DNSアプリケーション パーティション（DomainDnsZones/ForestDnsZones）側の“インフラ役割”が旧DCを指している可能性が高い |
| 時刻同期のズレ | w32tm /query /source が DC1 を返す（DC2を基点にしたい） | 端末やメンバーサーバーが DC1 を参照するのは必ずしも異常ではない。重要なのは「PDC エミュレーター（DC2）が外部NTPへ同期し、他はドメイン階層（NT5DS/DOMHIER）へ戻っている」こと |
ポイント
“表示が旧DCになっている＝即アウト”ではありません。ただし、旧DCを降格・撤去する段階になると、DomainDnsZones/ForestDnsZones のfSMORoleOwnerが旧DCのままだと、降格処理（DCPROMO/ADDS削除）や ADPREP が止まる典型パターンがあります。撤去予定なら先に直しておくのが安全です。
最初にやるべき前提チェック：レプリケーションとDC健全性
FSMOや時刻同期の話に入る前に、ADが「普通に健康か」を確認します。ここが崩れていると、転送や設定変更をしても反映されない／“見え方だけ”が変になるためです。
| 確認 | コマンド例 | 見るべき観点 |
|---|---|---|
| DC診断 | dcdiag /v | DNS/広告/サービス/レプリケーションの致命的エラーがないか |
| レプリケーション概要 | repadmin /replsummary | 失敗率、遅延、相手DCが欠落していないか |
| レプリケーション詳細 | repadmin /showrepl | 各パーティション（DomainDnsZones/ForestDnsZones含む）が同期できているか |
| DNSの基本 | イベントログ（DNS Server/Directory Service）確認 | AD統合DNSゾーンの読み込み失敗、SRV登録失敗などがないか |
ここで赤が出る場合は、FSMOやW32Timeをいじる前に原因（名前解決、サイト/サブネット、ファイアウォール、NTDS/DFS関連など）を潰すのが近道です。
FSMOの再確認：PDC エミュレーターだけは特に厳密に
netdom query fsmo で5役すべてが DC2 なら基本はOKですが、時刻同期の軸になるのは PDC エミュレーターです。ここだけは「本当に DC2 か」「反映が行き渡っているか」を二重で確認します。
確認コマンド例（どれか1つではなく、複数でクロスチェックすると安心です）:
netdom query fsmo
# PowerShell（RSAT/ADモジュール）
Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster
Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster補足（反映タイミング）
役割の新オーナーは、対象パーティションの“受信レプリケーションが一巡してから”本格稼働に入る挙動があります。移行直後やレプリケーションが不安定なときは、「コマンド上はDC2」でも、周辺が追従していないケースがあります。
もしPDCだけ移っていない／疑わしい場合
旧DCが稼働していて通信可能なら「転送」を、旧DCが故障/撤去済みなら「奪取」を検討します。手順は Microsoft のガイド（転送/奪取）に沿って実施し、実施後はレプリケーションの完了を待ってから再確認します。
代表的な方法（概要）:
- GUI（ADユーザーとコンピューター/ドメインと信頼関係/スキーマなど）
ntdsutilによる transfer / seize- PowerShell（
Move-ADDirectoryServerOperationMasterRole）
“奪取”は最終手段です。特に RID マスターの奪取は運用上の注意点があるため、旧DCが復帰しないことを確実にした上で実施してください。
時刻同期の正しい考え方：w32tm /query /source が旧DCでも即異常とは限らない
ADドメインの時刻同期は、基本的に「ドメイン階層」で動きます。重要なのは“全員がPDCを直接見ていること”ではなく、“階層が正しくつながっていること”です。
| 対象 | 期待する同期元（概念） | よくある誤解 |
|---|---|---|
| 端末/メンバーサーバー | 任意のDC（ドメイン階層） | 「必ずPDCを指すべき」ではない |
| ドメイン内の他DC | PDC エミュレーター | 「どのDCでもOK」ではない（DC同士はPDCへ収束させたい） |
| （ルートドメインの）PDC エミュレーター | 外部NTP（または信頼できる上位時刻源） | 「ドメイン階層（NT5DS）で十分」ではない（上位がいない） |
つまり、端末で w32tm /query /source を打って DC1 が出ても、そのDC1が最終的にDC2（PDC）→外部NTPへつながっていれば正常系です。一方で、DC2（PDC）自身が DC1 を見ている／外部NTPに出られていない、という状態は是正したいケースが多いです。
W32Timeの通信要件：UDP 123 を忘れない
Windows Time（W32Time）は NTP に準拠し、時刻同期は UDP 123 を使います。外部NTPへ同期させる場合は、DC2（PDC）から外部への UDP 123 が通るか（FW/UTM/プロキシ配下など）も合わせて確認してください。
手順：PDC エミュレーター（DC2）を外部NTPへ同期させ、信頼できる時刻源にする
ここでは「DC2がPDCである」前提で、PDC側のW32Time設定を整えます。まず現状確認から入ると、直すべきポイントが見えます。
現状確認（DC2で実施）
w32tm /query /status
w32tm /query /source
w32tm /query /configuration次に設定を入れ直します。外部NTPは社内標準があるならそれを使い、なければ複数のNTPサーバーを指定して冗長化します。
外部NTPの設定例（DC2で実施）
REM 外部NTP（例）を指定して、PDCを信頼できる時刻源として宣言
w32tm /config /manualpeerlist:"0.pool.ntp.org,0x8 1.pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update
net stop w32time
net start w32time
w32tm /resync /force
w32tm /query /source
w32tm /query /status※,0x8 は「Client」モードです。環境によってはポーリング間隔などの設計も絡むため、組織の標準がある場合はそれに合わせてください。
設定が壊れている疑いがある場合の“リセット”例
サービス登録が壊れている、過去の設定が混線している、といった場合の切り分けとして、W32Timeの再登録を行う方法もあります（影響が出る可能性があるのでメンテナンス時間推奨）。
w32tm /unregister
net stop w32time
w32tm /register
net start w32timeその後、外部NTP設定→再起動→再同期→確認、の順で進めます。
手順：他のDC/サーバー/端末を「ドメイン階層（DOMHIER/NT5DS）」へ戻す
“PDCを外部NTPへ”ができたら、他のサーバーが独自に外部NTPを見ていたり、旧DC固定になっていたりする状態を解消して、「ドメイン階層へ戻す」方が運用が安定します。
非PDCのDC／メンバーサーバーの基本設定（例）
w32tm /config /syncfromflags:domhier /reliable:no /update
net stop w32time
net start w32time
w32tm /resync /force端末も基本は同様です（GPOで統制するのが一般的）。過去に「特定NTPを手動指定」していた環境ほど、この“ドメインへ戻す”作業が効きます。
確認のコツ：見るべきは「source」より「status」
w32tm /query /source は「今たまたまどこを見ているか」を返しがちです。次の観点で status を併用すると“系統として正しいか”が判断しやすくなります。
- Stratum が極端に高くないか（外部へ出られず階層が崩れていないか）
- Last Successful Sync Time が更新されているか
- リーフ（端末）→DC→PDC→外部NTP、の流れが成立しているか
本題：DomainDnsZones/ForestDnsZones の fSMORoleOwner が旧DCを指す“理由”
ここが一番混乱しやすいポイントです。
netdom query fsmo が表示するのは「よく知られている5つのFSMO（Schema / Domain Naming / PDC / RID / Infrastructure）」です。一方、AD統合DNSを使っている環境では、DNSのアプリケーション ディレクトリ パーティション（DomainDnsZones / ForestDnsZones）にも、インフラ（Infrastructure）オブジェクトと fSMORoleOwner が存在します。
このため、次のような“ズレ”が起こり得ます。
netdom query fsmo：5役はすべて DC2（正しい）CN=Infrastructure,DC=DomainDnsZones,...：DNSパーティション側の役割所有者が DC1（旧DC）
さらに厄介なのは、旧DCを強制降格した／メタデータ クリーンアップしたなどの履歴があると、fSMORoleOwner が “削除済みNTDS Settings（0ADEL…）” を指したまま残ることがある点です。これが将来、DC降格や ADPREP（/RODCPREP）時に問題を起こします。
確認コマンド：DNSパーティション側の fSMORoleOwner を見る
Microsoftが案内している確認方法の一つが ldifde です。例:
ldifde -f Infra_DomainDNSZones.ldf -d "CN=Infrastructure,DC=DomainDnsZones,DC=example,DC=com" -l fSMORoleOwner
ldifde -f Infra_ForestDNSZones.ldf -d "CN=Infrastructure,DC=ForestDnsZones,DC=example,DC=com" -l fSMORoleOwnerまた、質問文にあるように dsquery で属性を読む方法でも確認できます（DNは環境に合わせてください）。
修正方法：ADSI Edit で DomainDnsZones / ForestDnsZones の fSMORoleOwner を付け替える
注意
ADSI Edit はADの中身を直接編集します。誤ると影響が大きいため、実施は「レプリケーション健全」「バックアップ/復旧手順確認」「作業ウィンドウ確保」を前提にしてください。
手順の全体像はシンプルで、やることは「CN=Infrastructure の fSMORoleOwner に、稼働中DC（通常はDC2）の NTDS Settings のDNを設定する」です。
手順（概要）
- 正しいNTDS Settings DN（DC2の識別子）を取得
ADSI Edit で「Configuration」へ接続し、CN=Sites→CN=（サイト名）→CN=Servers→CN=DC2→CN=NTDS Settings
のdistinguishedNameを控えます（コピー）。 - DomainDnsZones へ接続して編集
ADSI Edit の「Connect to…」で接続先をDC=DomainDnsZones,DC=example,DC=com
にし、CN=Infrastructureを開いてfSMORoleOwnerを編集します。 - ForestDnsZones も同様に編集
接続先をDC=ForestDnsZones,DC=example,DC=com
に変え、同じくCN=InfrastructureのfSMORoleOwnerを更新します。 - レプリケーションを待つ（必要なら同期）
変更はレプリケーションで全DC（対象パーティションを持つDC）へ行き渡ります。急ぐ場合はrepadmin /syncallなどで同期を促し、反映後に再確認します。
どのDCを指すべきか（実務的な判断）
基本は「今後も稼働し続けるDNSサーバー/DC」を指すようにします。多くの移行では、新DC（DC2）がDNSも担うため DC2 で問題ありません。
また、Microsoftの事例では「元オーナーの直接レプリケーション パートナーだった稼働中DCへ付け替え、変更が対象DCへ受信レプリケーションされるのを待つ」ことが推奨されるケースがあります。環境のサイト構成やレプリケーション経路によっては、この観点が効きます。
もう一つの選択肢：KBのスクリプト（fixfsmo.vbs）で修正する
DomainDnsZones/ForestDnsZones の fSMORoleOwner が “削除済み（0ADEL…）” を指している場合、MicrosoftのKBでは fixfsmo.vbs のサンプルが提示されています。使い方は次のようなイメージです。
cscript fixfsmo.vbs DC=DomainDnsZones,DC=example,DC=com
cscript fixfsmo.vbs DC=ForestDnsZones,DC=example,DC=com注意点として、このスクリプト例は「fSMORoleOwner が削除済み（0ADEL）を含む場合に付け替える」ロジックです。旧DCがまだ生きていて単に“旧DCを指しているだけ”のケースでは、手動での付け替えが必要になることがあります。
旧DC（DC1）を降格・撤去する前のチェックリスト
撤去フェーズで躓かないための、実務向けチェックリストです。
| チェック項目 | OKの目安 | 確認例 |
|---|---|---|
| FSMO 5役 | 全て DC2（意図通り） | netdom query fsmo |
| PDCの時刻同期 | DC2 が外部NTPを参照し、同期成功している | w32tm /query /source, /status |
| 他DC/メンバーの時刻同期 | ドメイン階層（NT5DS/DOMHIER）に収束している | w32tm /query /configuration |
| DomainDnsZones の fSMORoleOwner | 稼働中DC（通常DC2）を指す | ldifde / ADSI Edit |
| ForestDnsZones の fSMORoleOwner | 稼働中DC（通常DC2）を指す | ldifde / ADSI Edit |
| レプリケーション | 重大な失敗がなく収束している | repadmin /replsummary |
よくある「なぜそう見える？」を潰しておく
端末の w32tm /query /source がDC1のままなのはダメ？
端末やメンバーサーバーは「任意のDC」を参照するため、DC1がまだ稼働している間は表示がDC1になることがあります。ここで重要なのは、DC1が最終的にPDC（DC2）へ収束しているかです。端末の表示だけで“失敗”と判断しない方がよいです。
DC2（PDC）で source がDC1になるのは？
これは是正対象になりやすいです。PDCは外部NTPへ同期させるのが原則で、ドメイン内の他DCを参照してしまうと「時間の根」が曖昧になります。上で紹介した手順で PDC の設定（manualpeerlist / reliable）を見直してください。
設定変更したのに反映されない
多くは次のどれかです。
- W32Time サービス再起動や
/updateを入れていない - GPOで上書きされている（ローカル設定が戻される）
- UDP 123 が通っていない（外部NTPに出られない）
- ADレプリケーションが不健全で「役割/属性の更新」が行き渡っていない
コメント