古いドメインコントローラー（DC）を新しいOSのサーバーに入れ替えるとき。あるいは、DCが故障して起動しなくなり、ハードウェアごと処分してしまったと後で気づいたとき。どちらでも、手を止めて確かめることがあります。そのDCが、FSMO（操作マスター）の役割を持っていなかったかです。

ADのDCはどれでもユーザーを作り、パスワードを変えられます。ただし5つの仕事だけは、フォレストかドメインの中で1台のDCが受け持っています。その1台を、役割を移さないまま消すと、しばらくは何も起きないのに、ある日スキーマの拡張や新しいDCの追加、パスワードの変更が引っかかり始めます。

この記事は、メンバー限定動画「Active Directory入門 Part 9：FSMO」を中心に、同じシリーズの「診断コマンド16選」「複製ロジック」、無料動画「ドメインコントローラー構築時の落とし穴」を素材に、役割を移すときの判断をまとめたものです。手順の公式の説明は2026年10月28日時点のMicrosoft Learnで確認しました。先に結論を書きます。

  1. 最初に、誰が持っているかを確かめる。 撤去や故障の話が出た時点で netdom query fsmo を流す
  2. 持ち主が動いているなら「転送」する。 撤去の前に、行き先を自分で選んで移す
  3. 「強制移動（seize）」は、元の持ち主を二度とDCとして戻さないと決めたときだけ。 戻すならOSから作り直す
  4. 急ぐのはPDCエミュレーターだけ。 ほかの4つは、持ち主が戻る見込みがあれば待てる
  5. PDCエミュレーターを移したら、外部の時刻源の設定も移す

5つの役割と、止まったときに困ること

動画は24秒から、5つの役割を「フォレストで1台」と「ドメインごとに1台」の2種類に分けて説明しています。公式の「AD DC での柔軟なシングル マスター操作 (FSMO) の配置と最適化」が、それぞれがいつオンラインである必要があるかを書いているので、合わせて表にします。

役割 範囲 何をしているか いつ動いている必要があるか
スキーママスター フォレストに1台 スキーマの更新（adprep /forestprep、Exchangeの導入など） スキーマを更新するとき
ドメイン名前付けマスター フォレストに1台 ドメインやアプリケーションパーティションの追加・削除 ドメインを足す・消すとき
RIDマスター ドメインごとに1台 各DCへ、SIDの末尾に使う番号の束（RIDプール）を配る 新しいDCを昇格するとき、DCの手持ちの番号を補充するとき
PDCエミュレーター ドメインごとに1台 パスワード変更の受け取り、パスワードが合わない認証の照会先、グループポリシー編集の既定の接続先、時刻の基準 常に（公式は「1日24時間、週7日」と書いている）
インフラストラクチャマスター ドメインごとに1台 他ドメインのオブジェクトへの参照を更新 複数ドメインの環境で参照を更新するとき

RIDの意味は、画面で見るとすぐ分かります。動画の2分37秒からでは、AdministratorとGuestの objectSid 属性を並べ、前半（ドメインのSID）が同じで、末尾だけが500、501と違うことを確かめています。どのDCでもユーザーを作れるので、この末尾の番号が重複しないように束で配る係が要る。それがRIDマスターです。

この表から分かるのは、止まった影響がすぐ出るのはPDCエミュレーターだけだということです。スキーママスターが落ちていても、スキーマを拡張しない限り誰も気づきません。気づかないまま半年たち、Exchangeの更新やDCの入れ替えで初めて止まる。役割を移し忘れる事故が厄介なのは、この時間差のせいです。

インフラストラクチャマスターには配置の注意があります。動画の6分4秒からでも触れているとおり、複数ドメインのフォレストで、グローバルカタログではないDCがドメインに残っている場合、この役割はグローバルカタログではないDCに置きます。ドメインが1つだけのフォレスト、またはドメイン内のすべてのDCがグローバルカタログなら、どこに置いてもかまいません（公式の同じページ）。

まず、誰が持っているかを確かめる

netdom query fsmo

5つの役割と持ち主のDCが1行ずつ並びます。メンバー限定の「診断コマンド16選」の4分53秒からは、このコマンドを紹介し、dcdiag /v の出力からでも分かるが、そちらは見づらいので、持ち主だけ知りたいときは netdom query fsmo のほうがすんなり分かる、と使い分けを話しています。

dcdiag /v で見る場合の読み方は、FSMOの回の7分21秒からにあります。出力のどこに「Role Schema Owner」などの行が出るか、それがどのパーティションの話なのかを、実際の出力で追っています。9分25秒からは、サブドメインのDCで同じ確認をして、上の2つはフォレストのルートのDC01、下の3つはそのドメインで最初に作ったDCが持っている、と見分ける場面です。複数ドメインの環境で「どのドメインの、どの役割を誰が持っているか」を初めて整理するなら、この場面を自分の出力と見比べるのが早道です。未参加の場合はリンク先にメンバーシップの案内が出ます。

役割の持ち主は、何もしなければ最初に作ったDCのままです。2台目を足しても自動では動きません（2台目のドメインコントローラーを追加する記事で扱いました）。「1台目＝全部持っている」を前提に、撤去の計画を立てるのが安全です。

持ち主が動いているなら「転送」する

動画は6分26秒から、OSを新しいバージョンに入れ替えるときに、役割を理解しないまま古いDCを消してしまうのがいちばんやってはいけないことだ、と強調しています。そうならないために、撤去の前に役割をほかのDCへ転送します。

公式の「Active Directory ドメイン サービスでの操作マスター役割の転送または奪取」によると、役割を持つDCを降格ウィザードで正常に降格すれば、持っている役割はフォレスト内の既存のDCへ自動で割り当て直されます。それでも先に自分で転送しておく理由は、行き先を自分で選べるからです。同じ公式ページは、行き先の候補として、前の持ち主と同じドメインにあり、役割のパーティションの最新の複製を持つDCを挙げています。スキーママスターなら、フォレストのルートドメインで、今の持ち主と同じサイトにあるDCが最適だ、という例も書かれています。

「同じサイト」が効く理由は、メンバー限定の「複製ロジック」の5分31秒からで確かめられます。サイトが分かれると、サイト間の複製は既定で60分に1回になる、と画面で見せている回です。遠いサイトのDCは、直前の変更をまだ受け取っていないことがあります。

管理ツールで転送する

転送は、役割の種類ごとに使う管理ツールが違います。動画はこれを順に見せています。

  • スキーママスター: 「Active Directoryスキーマ」スナップイン（11分13秒から）
  • ドメイン名前付けマスター: 「Active Directoryドメインと信頼関係」（14分14秒から）
  • RID・PDC・インフラストラクチャ: 「Active Directoryユーザーとコンピューター」の「操作マスター」。3つのタブが並ぶ（15分31秒から）

3つのツールに共通するつまずきが、先に行き先のDCへ接続し直すことです。動画の12分40秒からでは、DC01に接続したまま開くと「転送するには、そのDCに接続してください」という趣旨の表示が出て、「ドメインコントローラーの変更」でDC02につなぎ直してから、ようやく変更ボタンが意味を持つ流れを見せています。管理ツールは、開いたサーバーではなく、いま接続しているDCの中身を見ています。この点は「複製ロジック」の3分6秒からでも、DCごとにデータベースは別物なので、接続先を明示して確かめるように、と念を押しています。

PowerShellで転送する

複数の役割をまとめて移すなら、PowerShellのほうが確実です。公式の「Move-ADDirectoryServerOperationMasterRole」の例に沿って、5つをDC02へ転送する場合はこうなります。

Move-ADDirectoryServerOperationMasterRole -Identity "DC02" `
  -OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster

このコマンドレットは、ADのPowerShellモジュールが入ったドメイン参加済みのコンピューターから実行できる、とリファレンスに書かれています。スキーママスターとドメイン名前付けマスターを動かすにはEnterprise Admins、ドメインごとの3つにはそのドメインのDomain Adminsのメンバーである必要があります（公式の転送・奪取のページ）。

転送が終わったら、もう一度 netdom query fsmo を流し、全部が新しいDCに移ったことを確かめてから、古いDCを降格します。

「強制移動（seize）」は、元の持ち主を戻さないと決めたときだけ

転送は、元の持ち主と行き先の両方が動いていて、オンラインで受け渡す操作です。動画の16分43秒からはこの前提を確かめたうえで、17分1秒から、「よく分からないままDCを1台壊してしまった、ハードウェアも処分した、でもそのDCが役割を持っていた」という場面を挙げています。元の持ち主がいないので、受け渡しはできません。ここで使うのが強制移動です。

動画では17分30秒から ntdsutil を起動し、roles で「fsmo maintenance」に入ってから、transfer と並ぶ seize を「転送ではなく、無理やり上書きする」コマンドとして紹介しています（19分23秒から）。続けて20分3秒から、なるべくやらないほうがよい操作だ、と念を押しています。

公式の手順は次のとおりです。役割を割り当てる予定のDCにサインインして実行するのが勧められています。

ntdsutil
roles
connections
connect to server DC02
q
seize schema master
seize naming master
seize rid master
seize pdc
seize infrastructure master
q
q

PDCエミュレーターは seize pdc、ドメイン名前付けマスターは seize naming master と、名前が少し違う点に注意します。動画の21分24秒からは、この公式ページの手順を読みながら、connect to server から transfer／seize の書き方までを確かめる場面です。動画では20分54秒から、日本語版はコマンドまで訳されていて読みづらいので、英語版を横に開いて確かめるよう勧めています。2026年10月28日時点の日本語版でも、connect to server <servername> が「サーバー <servername に接続>」のように訳されている箇所が残っています。コマンドを打つ前に、英語版の「Transfer or seize Operation Master roles in Active Directory Domain Services」と見比べると安全です。

PowerShellなら、転送と同じコマンドに -Force を付けます。リファレンスによると、-Force を付けてもまず通常の転送を試み、できなかったときに強制移動する動きです。

Move-ADDirectoryServerOperationMasterRole -Identity "DC02" `
  -OperationMasterRole RIDMaster,PDCEmulator,InfrastructureMaster -Force

強制移動した元のDCは、そのまま戻さない

強制移動のいちばん重い約束がこれです。公式の転送・奪取のページは、前の持ち主がドメインに戻らない場合にだけ強制移動するよう勧めています。そして、強制移動した後に元のコンピューターを修理できたとしても、DCとして戻すなら、ディスクをフォーマットしてWindowsを入れ直すか、メンバーサーバーへ強制的に降格し、ほかのDCでメタデータを掃除してから昇格し直す、という手順を挙げています。バックアップから戻すことは勧めていません。戻したDCは、自分がまだ持ち主だと思っているからです。

同じページの表によると、持ち主が2台いると問題が起きるのは、スキーママスター、ドメイン名前付けマスター、RIDマスターの3つです。特にRIDは、2台が同じ番号を配れば、別のユーザーに同じSIDが付く事故につながります。

もう1つ、RIDマスターの強制移動は番号を大きく消費します。 公式ページによると、重複を避けるため、強制移動のときに次に配るRIDの値が引き上げられます。Move-ADDirectoryServerOperationMasterRole では3万、ntdsutil では1万です。何度も繰り返すとドメインで使えるRIDの範囲を無駄に減らすので、公式は「今のRIDマスターを戻せないと確かめたときだけ」強制移動するよう書いています。

急ぐのはPDCエミュレーター。ほかは待てる

故障したDCが「修理すれば戻るかもしれない」状態なら、5つ全部をすぐ強制移動する必要はありません。配置のページは、オフラインのDCが持つ役割は、その役割に依存する操作をするときにだけ転送または強制移動すればよく、その役割が必要になる前に持ち主を復旧できるなら、強制移動を遅らせてよい、としています。ただし同じページで、PDCエミュレーターは常にオンラインである必要があるとも書いています。

判断を表にすると、こうなります。

状況 取る方法
撤去予定で、持ち主はまだ動いている 行き先を選んで転送してから降格する
持ち主が故障したが、数日で戻る見込み PDCエミュレーターだけ近くのDCへ移し、ほかは復旧を待つ。戻ったら転送で元に戻すか、配置を決め直す
持ち主はもう戻らない（処分した、OSを入れ直した） 残る役割を強制移動し、メタデータを掃除する。元のサーバーをDCに戻すなら作り直す

メタデータの掃除と、役割の行き先

戻らないDCの記録は、ADの中に残り続けます。公式の「AD DS サーバー メタデータをクリーンアップする」によると、「Active Directoryユーザーとコンピューター」の「Domain Controllers」OUからそのDCのコンピューターアカウントを削除すると、メタデータの掃除が自動で行われます。

ここで知っておきたいのは、この掃除も、消したDCが持っていた役割を移そうとすることです。同じページによると、削除の途中で役割を持っていたことが表示され、OKを押すと、画面に出ているDCへ役割が移ります。そして、このDCは変更できない、と書かれています。別のDCに置きたいなら、掃除が終わった後に改めて移す必要があります。行き先を自分で決めたいなら、先に seize で移してから掃除する順番のほうが、二度手間になりません。

PDCエミュレーターを移したら、時刻の設定も移す

役割を移して netdom query fsmo の結果が変わっても、まだ終わりではありません。時刻です。

公式の「権限のある時刻を構成する」によると、ドメイン内のすべてのDCは、PDCエミュレーターを持つDCを時刻の相手にします。そして、フォレストのルートにあるPDCエミュレーターが、組織全体の時刻の基準になります。外部の時刻源と同期させる設定をするのは、このDCです。無料動画「ドメインコントローラー構築時の落とし穴」の37分3秒からも、この階層と、PDCエミュレーターに外部のNTPを設定するのがセオリーで、時刻が狂うと認証まわりが相当まずいことになる、と説明しています。

ところが、外部のNTPの設定はPDCエミュレーターの役割に付いて動くわけではなく、そのサーバーに入れた設定です。役割だけを新しいDCへ移すと、新しい基準のDCは外部の時刻源を知らないまま、組織の時刻を配り始めます。

公式の「Windows タイム サービス ツールと設定」に載っている w32tm の形で、移した後にそろえておきます。

rem 新しくPDCエミュレーターになったDCで（NTPサーバー名は自組織のものに置き換える）
w32tm /config /manualpeerlist:"ntp.example.jp" /syncfromflags:manual /reliable:yes /update

rem 元のPDCエミュレーターがまだDCとして残る場合、そちらはドメインの階層に戻す
w32tm /config /syncfromflags:domhier /update

rem どちらでも、同期の相手を確かめる
w32tm /query /source

元のDCを降格して撤去するなら、2つ目は要りません。新しいDCで w32tm /query /source が意図した外部の時刻源を返すことを確かめれば、移行は完了です。

移す前後のチェックリスト

いつ 確かめること 見るもの
撤去・故障の話が出たとき 役割の持ち主 netdom query fsmo
移す前 行き先のDCが最新の複製を持っているか 行き先のDCで repadmin /showrepl
移す前 権限 スキーマと名前付けはEnterprise Admins、ほかはDomain Admins
移した直後 全部が行き先に移ったか もう一度 netdom query fsmo
強制移動した後 元のDCを戻さない段取り メタデータの掃除。戻すならOSから作り直す
PDCエミュレーターを移した後 外部の時刻源 新しいPDCエミュレーターで w32tm /query /source
最後 DCごとの診断 残るDCすべてで dcdiag /v（結果の読み方はdcdiagのエラーの見方）

まとめ

  • FSMOの5つの役割は、何もしなければ最初に作ったDCにある。撤去や故障の話が出たら、まず netdom query fsmo
  • 持ち主が動いているなら転送する。管理ツールは、先に行き先のDCへ接続し直してから。複数ならPowerShellでまとめて
  • 強制移動は、元の持ち主を戻さないと決めたときだけ。戻すならOSから作り直し、メタデータを掃除する。RIDマスターの強制移動は番号を大きく消費する
  • 急ぐのはPDCエミュレーター。ほかの4つは、持ち主が戻る見込みがあれば待てる
  • PDCエミュレーターを移したら、外部の時刻源の設定も新しいDCへ移す

FSMOの事故は、消した日ではなく、何か月も後に別の作業で表に出ます。だから、DCを消す計画を立てたときが、役割を確かめるいちばん安い瞬間です。降格のボタンを押す前に netdom query fsmo を1回流す。 それだけで、この記事の後半に書いた強制移動の手順は、たいてい使わずに済みます。