ADのドメインコントローラーのIPを引き継いだ移行(交換)と、機能レベルを上げる作業の手順・流れ

Active Directoryのドメインコントローラーを、IPを引き継いだ状態で別のサーバーに移行したい！

Active Directory(以下ADと表記)では、中核となる多くの機能を提供するドメインコントローラーはとても重要です。
そのため、ドメインコントローラーのサーバー筐体は予防保守※を目的とし、導入後3～5年が経過したら交換する、といった方針の環境も多いでしょう。

※消耗が起きやすい機材や障害時の影響が大きい機材について、経年劣化による突然の障害発生を未然に防ぐため、規定の利用期間や利用回数が経過した時点で、正常に稼働している状態であっても新しい(消耗していない)機材に交換するなどの保守対応を行うこと。

正常に動作している状態のドメインコントローラーであれば、移行作業はそれほど難しい作業ではありません。

ですが作業手順が多く、手順を間違えると、追加の作業が発生してしまうことがある。
また多くの場合、頻繁に行う作業ではなく数年ごとに行う作業であるなどの理由から、作業手順の一部を忘れてしまった、なんとなく不安だ…。
といった方もいらっしゃるんじゃないでしょうか。

幸いなことに、ドメインコントローラーの移行については、すでにネット上でたくさんの技術情報が公開されています。
そのため、個々の作業については情報が不足していてよく分からない…というケースは少ないでしょう。
しかし機能レベルの更新を含めた作業の手順や流れについては、少し情報が少ない印象です。

またドメインコントローラーはDNSサーバーとしても動作しているケースが多く、IPアドレスを引き継ぎたい！
新旧のドメインコントローラーで同一のIPアドレスを使用したい！IPアドレスを変更したくない！※というケースもまた多いでしょう。

そこで今回は、機能レベルの更新を含め、IPを引き継いだ状態で、ADのドメインコントローラーを別のサーバーに移行(交換)する手順・流れをご紹介します！

※DNSサーバーは多数のクライアントPCやネットワーク機材などから参照されているため、DNSサーバーのIPアドレスが変わると、DHCPを使っていない機材に対し、変更を手動で反映する手間が発生します。(DHCPを使っている機材は、DHCPサーバーの設定変更をするだけで良い。)

はじめに

これからご紹介するドメインコントローラーの移行手順は、以下環境で確認を行っています。

• シングルフォレスト・シングルドメインである。
• AD、ドメインコントローラーの機能は、すべて正常に動作している。
• 移行元のドメインコントローラーは複数あり、Windows Server 2012 R2 Standard。
  ホスト名はそれぞれdc1、dc2、dc3とし、dc1がFSMOの機能をすべて保持している。
• 移行先のドメインコントローラーのOSは、Windows Server 2019。
  ホスト名はそれぞれdc11、dc12、dc13とし、dc1からdc11にFSMOの機能をすべて移行する。
• フォレスト・ドメインの機能レベルは、ともにWindows Server 2012 R2からWindows Server 2016に上げる。※
• PDCエミュレーターの機能を担当しているドメインコントローラーは、任意の外部NTPサーバーに時刻を同期している。
• すべてのドメインコントローラーは、DNSサーバーを兼務しており、ゾーンの種類がActive Directory 統合である。

※本エントリー執筆時点の最新の機能レベルはWindows Server 2016です。そのためWindows Server 2019のドメインコントローラーであっても、機能レベルは最高でWindows Server 2016となります。

移行元のドメインコントローラーのバージョンが異なる、移行元のドメインコントローラーで障害が発生している。
ADの機能の一部が正常に動作していないなど、上記環境と異なる場合では、追加の作業が発生したり作業手順の一部が変わるかもしれませんこと、あらかじめご了承ください。

また本エントリーでは作業の手順・流れの紹介に重きを置いており、個々の作業の詳細についてはふれていません。
実際に作業をする際は、他の技術情報も参考にして作業を行うことをおすすめします。

機能レベルの更新を含め、IPを引き継いだ状態で、ADのドメインコントローラーを別のサーバーに移行(交換)する手順・流れ

IPを引き継いだ状態で、ADのドメインコントローラーを別のサーバーに移行(交換)する際は、以下の手順・流れで作業を行います。

AD、ドメインコントローラーの機能が正常に動作していることを確認する

ADやドメインコントローラーの機能が正常に動作していない場合、移行作業が正常に完了しない可能性があります。
そのため、まずはADやドメインコントローラーの機能が正常に動作しているかを、確認しておくと良いでしょう。

参考：ADのドメインコントローラーの正常性を確認する代表的な方法

先に書いたとおり、機能が正常に動作していない場合では、追加の作業が発生したり作業手順の一部が変わります。
したがって障害や問題が起きている場合には、その内容に応じた作業についても情報を収集し、適切な対処を行ってください。

旧ドメインコントローラーの優先DNSサーバーのIPアドレスを、自身以外のドメインコントローラーのIPアドレスに変更する

今回の作業手順では、旧ドメインコントローラーのIPアドレスを新しいドメインコントローラーが引き継ぎます。(最終的に新ドメインコントローラーが、旧ドメインコントローラーと同一のIPアドレスを使用する。)
その過程で新旧ドメインコントローラーのIPアドレスを変更します。

このとき、特定の条件に合致していると、Active Directoryの複製の孤立(DNSサーバーの孤立)という問題が発生するため、注意が必要です。

Active Directoryの複製の孤立は、ドメインに複数のDNSサーバーが存在しており、ゾーンの種類が”Active Directory 統合”である。
さらにドメインコントローラーがDNSサーバーを兼務しており、ドメインコントローラーの優先DNSサーバーが自分自身(自身のIPアドレス)である。
といった場合に、そのドメインコントローラーのIPを変更することで発生します。

この問題の回避方法について、Microsoftさんは以下のように言及しています。

Active Directory 統合ゾーンをご利用の場合は Active Directory の複製の孤立を防ぐために、以下の手順を実施する前に各 DC 兼 DNS サーバーの IP 設定の優先 DNS サーバーおよび代替 DNS サーバーを確認し、互いに参照し合うように設定してください。

(Microsoft – TechNet ドメイン コントローラーの IP アドレス変更より引用)

“互いに参照し合う”という記述が少し分かりにくいですが、要は各ドメインコントローラーの優先DNSサーバーのIPアドレスを、自身以外のドメインコントローラー(DNSサーバー)のIPアドレスに設定しておけば良い、ということです。

したがって今回の例では、以下のように設定しておくと良いでしょう。

• dc1の優先DNSサーバー：dc2のIPアドレス
• dc2の優先DNSサーバー：dc3のIPアドレス
• dc3の優先DNSサーバー：dc1のIPアドレス

Active Directoryの複製の孤立(DNSサーバーの孤立)については、以下ページでもくわしく書かれているため、併せて参考になさってください。

Microsoft – ドメイン コントローラが _Msdcs.ForestDnsName ドメイン用に自身をポイントすると、DNS サーバーが孤立する

新ドメインコントローラーとなるサーバーをADに参加させる

新しいサーバー(dc11、dc12、dc13)を新しいドメインコントローラーとするためには、まずはADに参加させ、メンバーサーバーとする必要があります。
これは、通常のメンバーサーバーやクライアントPCと同じ手順でADに参加させればOKです。

メンバーサーバーとしてADに参加させる際は、新ドメインコントローラーの優先DNSサーバーは、旧ドメインコントローラー(DNSサーバー)のいずれかを指定する必要があります。
したがってこの時点では、Active Directoryの複製の孤立(DNSサーバーの孤立)についての考慮は不要です。

さらにこの時点では、新ドメインコントローラーのIPアドレスは、旧ドメインコントローラーのIPアドレスと異なる任意のIPアドレスで構いません。
といいますか、そうしないとIPアドレスの重複が発生し、正常な通信ができない状態となります。

メンバーサーバーである新ドメインコントローラーを、ドメインコントローラーに昇格する

新しいドメインコントローラーとなるサーバーをADに参加させ、メンバーサーバーとしたら、次にドメインコントローラーに昇格させましょう。

ドメインコントローラーの昇格については、特に注意点はありません。
Active Directory ドメインサービス構成ウィザードの手順にしたがい、昇格作業を進めてください。

旧ドメインコントローラーのFSMOの機能を、すべて新ドメインコントローラーに移行する

ドメインコントローラーの中には、以下FSMO(Flexible Single Master Operation)の機能を持っているサーバーがいます。

• スキーママスター：フォレスト内で1台のみ
• ドメイン名前付けマスター：フォレスト内で1台のみ
• RIDマスター：ドメイン内で1台のみ
• PDCエミュレーター：ドメイン内で1台のみ
• インフラストラクチャマスター：ドメイン内で1台のみ

参考：Microsoft – FSMO配置とActive Directory ドメインコントローラーの最適化

これらの機能を担当しているドメインコントローラーを、新しいドメインコントローラーに交換する場合、機能をすべて新しいサーバーに移行する必要があります。

新規にフォレスト・ドメインを作成する際は、最初のドメインコントローラーがFSMOの機能をすべて保持しています。
したがってFSMOの機能を別のサーバーに移行していなければ、最初のドメインコントローラーがFSMOの機能をすべて持っているはずです。

現在FSMOを保持しているサーバーを調べたいときは、コマンドプロンプトかPowerShellを起動し、以下コマンドを実行してください。

FSMOの機能を移行する方法は、GUIを使う方法とCUI(コマンド)操作を使う方法があります。

CUI操作を使用する場合は、『ntdsutil』コマンドを使って移行作業を実施します。

参考：Microsoft – Ntdsutil.exe を使用して別のドメイン コントローラーに FSMO の役割を移行または強制移行する

GUIを使う場合は、『Active Directory スキーマ』スナップインや、[Active Directory ドメインと信頼関係]スナップイン、[Active Directoryユーザーとコンピューター]スナップインから設定を行います。

FSMOの各機能の移行はGUIとCUIのどちらでも構いませんが、作業に慣れている場合は、CUIを使った方がスピーディーに作業可能でしょう。

GUI操作の場合は、以下のような画面を操作しながらFSMOの機能を移行するため、CUI操作が苦手な方におすすめです。

GUI操作、またはCUI操作によりFSMO機能の移行が完了したら、念のため『netdom /query fsmo』コマンドを実行し、FSMO機能が新しいドメインコントローラーに移行しているか、確認しておきましょう。

新ドメインコントローラー(PDCエミュレーター)で、同期先NTPサーバーの設定を行う ※必須ではない

Active Directoryドメイン環境では、ドメインコントローラーとメンバーサーバー、メンバーコンピューター(クライアントPC)の時刻が同じである必要があります。
これは、Kerberos認証を行うために必須です。(初期設定状態では5分以上のズレがあると、認証に失敗します。)

シングルフォレスト・シングルドメイン環境では、1台しか存在しないPDCエミュレーターの機能を持ったドメインコントローラーの時刻を使って、他のドメインコントローラーが自身の時刻を同期。
そしてメンバーサーバーやメンバーコンピューターは、ドメインコントローラーの時刻を使って自身の時刻を修正・同期します。

FSMO機能の移行操作により、PDCエミュレーターを移行したとしても、PDCエミュレーターの時刻同期設定は移行されません。
そのため、旧PDCエミュレーターの時刻同期の設定を初期設定状態から変更していた場合には、同様の設定を新PDCエミュレーターにも手動で行う必要があります。

※時刻同期の設定を初期設定状態から変更していなければ、本作業は不要であるため、必須の作業ではありません。

ドメインの時刻を任意の外部NTPサーバーと同期する方法

ドメインの時刻を任意の外部NTPサーバーと同期したい場合は、たとえば以下のようなコマンドを、新PDCエミュレーターで実行します。

NTPサーバーの設定コマンドを実行したら、以下コマンドを実行し、即時同期を行います。

さらにNTPサーバーの同期先を確認する際は、以下コマンドを実行してください。

実行結果の『ソース』がmanualpeerlistで指定した外部NTPサーバーとなっており、『最終正常同期時刻』が『w32tm /resync』を実行した時刻となっていれば、正常に外部NTPサーバーと時刻同期ができています。

尚、『w32tm /query /status』コマンドをPDCエミュレーターではないドメインコントローラーで実行した場合、『ソース』はPDCエミュレーターのコンピューター名となっているのが正常です。(PDCエミュレーターではないドメインコントローラーは、PDCエミュレーターの機能を持つドメインコントローラーの時刻に同期するため。)

参考：
Microsoft – Windows Time サービスにおける時刻同期の仕組み
Microsoft – TechNet FSMO の役割を転送した後の PDC エミュレーターの時刻同期の設定について

新旧ドメインコントローラー(FSMO)のDNSサーバーやIPアドレスを確認、変更する

繰り返しとなりますが今回ご紹介している手順では、IPアドレスを引き継ぎます(新旧のドメインコントローラーで同一のIPアドレスを使用する、ドメインコントローラーのIPアドレスを変更しない)。
そのためFSMOの各機能の移行が完了したら、旧ドメインコントローラーのIPアドレスを新ドメインコントローラーが使用するように、新旧ドメインコントローラー(FSMO)のIPアドレスを変更しましょう。

ですがIPアドレスを変更する前に、先に説明したActive Directoryの複製の孤立(DNSサーバーの孤立)が起きないよう、各ドメインコントローラー(兼DNSサーバー)の優先DNSサーバーを再度確認。
必ず互いに参照し合う設定となっていることを確認してください。

※旧ドメインコントローラーについてはすでに確認しているはずですが、新ドメインコントローラーについては未確認であるため。

IPアドレスの変更は重複を防ぐため、以下の手順で実行します。

1. 以前FSMO機能を保持していた旧ドメインコントローラーのIPアドレス(A)を、現在使われていない任意のIPアドレス(C)に変更する。
2. 現在FSMO機能を保持している新ドメインコントローラーのIPアドレス(B)を、旧ドメインコントローラーが使っていたIPアドレス(A)に変更する。
3. (IPアドレスを入れ替えたい場合のみ、)以前FSMO機能を保持していた旧ドメインコントローラーのIPアドレスを、CからBに変更する。

手順３は、新旧ドメインコントローラーのIPアドレスを入れ替えたい場合のみ、実行してください。

IPアドレスの変更が終わったら、DNSサーバーに変更が反映されるまで15分ほど待つ。
または、ただちに設定が反映されるよう、コマンド操作を実行してください。

Active Directory 統合ゾーンを利用している場合、該当のゾーンを持つ他の DNS サーバーに新しい IP アドレスが反映されているか確認します。

DNS サーバーは既定で 15 分毎に Active Directory データベースから情報を読み取るため、他の DNS サーバーに反映されるまでにはしばらく時間がかかります。
直ぐに反映させるためには、以下を実行してください。

• repadmin.exe /syncall /A
• DNS Server サービスの再起動

(Microsoft – TechNet ドメイン コントローラーの IP アドレス変更より引用)

IPアドレスを変更後に、新旧ドメインコントローラーに対してリモートデスクトップ接続を実行した際、『接続したリモートコンピューターが指定されたものではないため、接続を完了できません。これは、DNSキャッシュ内の古いエントリが原因で発生する場合があります。名前の代わりにコンピューターのIPアドレスの使用を試してください。』というエラーメッセージが表示され、正常にリモートデスクトップ接続ができないことがあります。

このメッセージが表示された場合の対応方法については、以下ページを参照ください。

接続したリモートコンピューターが指定されたものではないため接続を完了できません。と表示されたときに試してほしい対処法

新旧ドメインコントローラー(非FSMO)のDNSサーバーやIPアドレスを確認、変更する

新旧ドメインコントローラー(FSMO)のDNSサーバーやIPアドレスの確認・変更が完了したら、FSMOの機能を持っていない他のドメインコントローラー(非FSMO)についても、同様の手順でDNSサーバーやIPアドレスの確認・変更作業を行ってください。

再度AD、ドメインコントローラーの機能が正常に動作していることを確認する

新旧ドメインコントローラーのIPアドレスの変更(引き継ぎ)が完了したら、再度AD、ドメインコントローラーの機能が正常に動作していることを確認しておきましょう。

参考：ADのドメインコントローラーの正常性を確認する代表的な方法

もし何か問題が起きていた場合には、旧ドメインコントローラーの降格・機能レベルのアップグレード前であるこのタイミングで対処してください。

NPSなど、他の機能を設定・移行する ※必須ではない

旧ドメインコントローラーが、ネットワークポリシーサーバー(NPS)※1やAzure AD Connectサーバー※2など、他の機能を兼務しているケースがあります。
こういった場合には、既存のドメインコントローラーを降格する前に、これら機能の設定・移行と動作確認を行ってください。

※1 ネットワーク機材のIEEE802.1X認証や、L2TP/IPSecの認証などに使用する外部RADIUSサーバーとして、ADのNPSを使用するケースがあります。
参考：ヤマハRTXルーターのL2TP/IPSecによるリモートアクセスVPNの認証を、ADユーザーの認証情報で行う方法

※2 Azure AD Connectサーバーは、ドメインコントローラーとの同居は可能ですが、非推奨です。
参考：サーバー筐体交換などのため、Azure AD Connectサーバーを別のサーバーに移行する手順

旧ドメインコントローラーをメンバーサーバーに降格する

新ドメインコントローラーにFSMOの機能をすべて移行し、AD・ドメインコントローラーの機能、NPSなどのその他機能が正常に動作していれば、旧ドメインコントローラーは不要となります。
そのため正常に動作していることを確認したら、旧ドメインコントローラーをメンバーサーバーに降格してください。

ドメインコントローラーの降格手順については、以下Microsoftさんの解説ページの内容を参考にすると良いでしょう。

Microsoft – TechNet ドメイン コントローラー降格手順 (Windows Server 2012)

フォレスト・ドメインの機能レベルを上げる(アップグレードする)

フォレストとドメインの機能レベルは、各機能レベルごとに存在できるドメインコントローラーのサーバーOSのバージョンが決められています。
シングルフォレスト・シングルドメイン環境で、OSのバージョンが異なる複数のドメインコントローラーが存在する場合は、一番古いOSバージョンのドメインコントローラーに対応している機能レベルまでアップグレードが可能です。

したがって、まずは古いバージョンのOSで動作しているドメインコントローラーをすべて降格。
そしてアップグレード後の機能レベルに対応しているドメインコントローラーだけの状態にしてから、機能レベルのアップグレードを行います。

フォレストやドメインの機能レベルはアップグレードを行うことで、新しいActive Directoryの機能を利用できるようになります。
そのため以前の機能レベルを使い続けなければならない特段の理由がないかぎりは、機能レベルを上げられるときは上げた方が良いでしょう。

Windows Server 2019のドメインコントローラーではそれぞれ、Active Directory管理センターの『ドメインの機能レベルの昇格』と、『フォレストの機能レベルの昇格』というメニューボタンから実行可能です。

MicrosoftさんはTechNetで以下のように、通常は機能レベルのアップグレードで影響が出ることはない(が、不測の事態に備えて事前のバックアップ取得を推奨)、としています。

通常は機能レベルを上げることで影響がでることはありませんが、不測の事態に備えて、作業前にドメイン コントローラーでシステム状態のバックアップを取得することを推奨します。

(Microsoft – TechNet Active Directory の機能レベルを上げる際の影響についてより引用)

また、(基本的には)ドメインやフォレストの機能レベルは一度上げると元に戻すことはできません。

一部のパターンを除き、基本的にドメインやフォレストの機能レベルを上げると元に戻すことはできません。

(Microsoft – TechNet Active Directory の機能レベルを上げる際の影響についてより引用)

そのため実行する際は、事前に以下資料を確認しておくと良いでしょう。

Microsoft – TechNet Active Directory の機能レベルを上げる際の影響について

ここまでにご紹介した手順・流れで作業を行えば、IPを引き継いだ状態で、ADのドメインコントローラーを別のサーバーに移行(交換)でき、機能レベルのアップグレードを完了できますので、ぜひ参考になさってくださーい！