最近まで現役だったWindows 2000 Serverで稼働しているActiveDirectory環境をまるっと最新のWindows Server 2019に移行しました。
世の中の企業で、いまだにWindows 2000 ServerでActiveDirectoryを稼働させている企業はあまりいないと思われ、需要も少ないかと思いますが、この作業が非常に大変だったこともあり、記念にブログの記事に残そうと思います。
もしご興味があればお付き合いください。
- 今回の移行作業における移行方式概要
- 移行対象の環境と移行後の環境
- 移行作業の工程と具体的な手順
- 1.新ADサーバー初期構築
- 2.DC移行用中間サーバー初期構築
- 3.現行ADサーバーのバックアップ
- 4.現行ADサーバーのスキーマ拡張
- 5.DC移行用中間サーバーをドメインに追加
- 6.DC移行用中間サーバーをDCに昇格
- 7.DC移行用中間サーバーをネットワークから分離
- 8.DC移行用中間サーバーをFSMO強制昇格
- 9.DC移行用中間サーバーの旧DC情報を削除
- 10.DC移行用中間サーバーのDNS旧DC情報を削除
- 11.DC移行用中間サーバーのフォレスト機能レベル変更
- 12.新ADサーバーをDC移行用中間サーバーのドメインに追加
- 13.DC移行用中間サーバーのSYSVOLをDFSRに変更
- 14.新ADサーバーをDCに昇格
- 15.DC移行用中間サーバーのFSMOを新サーバーに転送
- 16.DC移行用中間サーバーをDCからメンバーサーバーへ降格
- 17.新ADサーバーをネットワークから切断し本番IPアドレスを適用
- 18.現行ADサーバー(旧サーバー)を新ADサーバーへ切り替え
- 19.切り替え後の残作業
- 最後に
今回の移行作業における移行方式概要
今回実施した作業において、移行方式の概要を箇条書きで記載します。
- ActiveDirectory環境は新規構築せず、既存環境から最新環境へ「移行」する。
- 新ADサーバー構築作業では可能な限り本番環境の既存サーバーに影響を与えない。
- 新ADサーバーの構築は既存ネットワークから切り離して行う。
- 旧ADサーバーの本番切り替え時には最小のダウンタイムで行う。
- 本番切り替え時に問題があれば、容易且つ安全に切り戻しができるようにする。
- 最新のドメインに対応していないレガシーメンバサーバはドメインから外す。
- 2000から2019(2016)への直接移行は対応しておらず移行用中継サーバーを構築する。
上記の移行方式の概要のなかで重要なのは、「本番切り替え時のダウンタイム最小化」と「本番切り替え作業時の安全な切り戻し」です。
この部分は今回の古いAD環境からの移行といった特殊なケースだけではなく、一世代間での一般的なAD移行であっても同様に考慮すべきポイントであり、参考にしていただけるかと思います。
移行対象の環境と移行後の環境
今回のAD移行対象となるサーバー環境と、移行後の環境も紹介しておきます。
| 筐体種類 | OS | 備考 | |
|---|---|---|---|
| 旧AD環境 | |||
| プライマリ | タワー型物理筐体 | Windows 2000 Server SP4 | FSMO |
| セカンダリ | タワー型物理筐体 | Windows 2000 Server SP4 | |
| 新AD環境 | |||
| プライマリ | ラックマウント型物理筐体 | Windows Server 2019 | FSMO |
| セカンダリ | Hyper-V仮想環境 | Windows Server 2019 | 当記事では移行手順は割愛 |
移行前と移行後のイメージ図は以下です。
移行作業における大まかな流れ
今回の移行作業のポイントは、Windows 2000 Serverで稼働しているDCを、本番切り替え直前まで一切に停止させることなく稼働させることができるところ。
既存ADサーバーは稼働させつつ、平行して既存ADサーバーのデータをいったんWindows Server 2008 R2に移行して、その2008 R2を中継してWindows Server 2019に移行しているところ。
また、作業の途中から、中継用のWindows Server 2008 R2と新ADサーバーとするWindows Server 2019は既存のネットワークから切り離して移行作業を進めるところです。
この様に移行作業を進めることで、以下の利点があります。
- Windows2000ServerからWindowsServer2019へのAD環境のデータ移行は本来できないが、中間サーバを中継することでそれを可能にする。
- 本番環境に影響を一切与えることなく新ADサーバーの構築作業が行える。
- 新ADサーバー構築時に既存のADサーバーと同じIPアドレスとホスト名にすることで、LANケーブルの差し替えだけで本番切り替えが可能。
- Windows2000ServerのADには殆ど影響を与えずに作業をすることで、切り替え後に問題があっても確実に切り戻しが可能。
今回の移行作業の大まかな流れのイメージは以下です。
今回の移行では、2000から2019という世代の離れた環境への移行でしたが、これがフォレスト間の互換性のある近い世代での移行であっても、特に以下の移行方式は有効です。
- ネットワークを分離して新ADサーバーを構築する。
- 中継用サーバーを利用して新ADサーバーを本番機と同じホスト名とIPアドレスで構築。
- 本番機の切り替え時には、LANケーブルを差し替えるだけで済む。
手間が大きくても、安全に切り替え作業をしたい場合や、確実に切り戻しができるようにしておきたい場合は、今回の作業を参考にしていただくと良いかと思います。
移行作業の工程と具体的な手順
当項では、今回の移行作業における全行程の紹介と、具体的な手順を解説していきます。
尚、作業工程が非常に多いので、個々の工程の作業内容は大事なポイントに絞って記載します。
まず、今回の作業で実施した移行作業の工程は以下です。
- 新ADサーバー初期構築
- DC移行用中間サーバー初期構築
- 現行ADサーバーのバックアップ
- 現行ADサーバーのスキーマ拡張
- DC移行用中間サーバーをドメインに追加
- DC移行用中間サーバーをDCに昇格
- DC移行用中間サーバーをネットワークから分離
- DC移行用中間サーバーをFSMO強制昇格
- DC移行用中間サーバーの旧DC情報を削除
- DC移行用中間サーバーのDNS旧DC情報を削除
- DC移行用中間サーバーのフォレスト機能レベル変更
- 新ADサーバーをDC移行用中間サーバーのドメインに追加
- DC移行用中間サーバーのSYSVOLをDFSRに変更
- 新ADサーバーをDCに昇格
- DC移行用中間サーバーのFSMOを新サーバーに転送
- DC移行用中間サーバーをDCからメンバーサーバーへ降格
- 新ADサーバーをネットワークから切断し本番IPアドレスを適用
- 現行ADサーバー(旧サーバー)を新ADサーバーへ切り替え
- 切り替え後の残作業
この作業工程には、本番DC(FSMO)切り替え後に実施するセカンダリーDCの追加作業は含んでいません。
切り替えさえ完了すれば、セカンダリーDCの追加は大した作業ではないので、上記の作業工程や具体的な手順の解説からは割愛しています。
では早速次の項から順に工程を解説していきます。
先は長いな・・・。
1.新ADサーバー初期構築
まずは新しく購入したラックマウントサーバーの初期構築を実施します。
以降の作業工程では通常の社内ネットワークから分離して独立したネットワークに配置しますが、初期構築段階では社内ネットワークに接続させて一般的なWindows Serverの基本設定を実施していきます。
この時点ではネットワークに繋げれば良く、ActiveDirectoryのインストールはしません。
また、後から移行作業用で用意したネットワーク内でドメイン参加をさせることになるため、この時点ではドメイン参加もしません。
この辺りの設定内容は以前に当ブログの別の記事で紹介しておりますため、良ければこちらもご参照ください。
尚、コンピューター名もIPアドレスも後から変えてしまうので、現在の社内のネットワーク内で重複の無い適当な値で設定しています。
WindowsUpdateだけはしっかり忘れずに実施しておきましょう。
2.DC移行用中間サーバー初期構築
次に、DCを2000環境から2008環境に移行するためのDC移行用中間サーバーを初期構築を実施します。
当作業も前項の「新ADサーバーの構築」と同様に、まずはWindowsServerの基本的な設定のみの実施です。
移行用中間サーバーは「Windows Server 2008 R2」を使用します。
当サーバーはあくまで移行工程上で一時的に使用するだけなので、Microsoftが公開している評価用のISOをダウンロードしてインストールしました。
また、WindowsServer2008R2をインストールできる物理筐体が無かったため、Hyper-V上の仮想サーバーで用意します。
今回のケースのように、Windows 2000 ServerからWindows Server 2019への移行については、そのバージョン間では互換はありません。
よって、2000形式のドメインで互換のある、2008形式のドメインにいったん移行したあとに、2008から2019(2016)に移行します。
移行作業が全て終わればAD移行用中間サーバーは削除します。
今回の移行作業におけるポイントの一つです。
尚、現時点では、現行ADサーバー自体の構成は変わらず、新しく構築した二つのサーバーは現行ADと同じネットワークには接続していますが、ドメインには参加していない状態です。
以下の構成になります。
3.現行ADサーバーのバックアップ
Windows 2000 Serverで稼働している現行のFSMO側ADサーバーのバックアップを実施します。
次項の作業で、現行ADサーバーのドメインをWindows Server 2008環境まで対応させるための「スキーマ拡張」を実施します。
万が一のトラブルに備えて、何か問題が発生したら元の環境に戻せるように、必ずバックアップを取っておきましょう。
尚、バックアップはWindows 2000 Server標準で使用できる「NTBackup」を使用します。
4.現行ADサーバーのスキーマ拡張
今回の移行作業における最初の重要作業である「スキーマ拡張」を実施します。
このスキーマー拡張作業を実施しないと、Windows 2000 Serverをドメインコントローラーで稼働させているドメイン環境に、それよりも新しいWindows Server 2003や2008のサーバーをドメインコントローラーに加えることはできません。
【補足】「スキーマ拡張」ってなにさ？
Active Directoryでは「Microsoft Active Directoryスキーマ」と呼ばれる、AD内のオブジェクトを定義している仕組みがあります。
詳しくは以下のMicrosoftのリファレンスページをご参照ください。
WindowsServerのバージョンが上がるごとにActiveDirectoryの機能が追加されたり変更されるのですが、その際には当然「Active Directoryスキーマ」のなかで扱うオブジェクトも仕様が変わったり追加されていきます。
今回の作業の例では、Windows 2000 Serverで稼働させているADのフォレストは「Windows 2000混合」と呼ばれる機能レベル(ドメイン自体のバージョン)です。
そのフォレストに対して、より新しいWindows Server 2003やWindows Server 2008をドメインコントローラーに昇格させることはできません。
昇格させようとするとエラーになります。
古いフォレスト環境に対して、それより新しい機能レベルのWindowsServerをドメインコントローラーに加える場合は、その新しい機能レベルまで古いフォレストのスキーマを拡張(バージョンアップ)させる必要があります。
この「スキーマ拡張」では、フォレストの機能レベルを拡張できる世代が決まっており、Windows 2000 Serverで稼働するWindows 2000形式のフォレストであれば、拡張に対応しているのはWindows Server 2008 R2の機能レベルまでです。
よって、例えば今回のWindows 2000 Serverのフォレストに対して、Windows Server 2016形式の機能レベルまでフォレストを拡張することはできません。
この制約があることから、前項で初期セットアップを実施した「AD移行用中間サーバー」が必要になります。
尚、この機能レベルごとの互換性については、以下のMicrosoft公式のページにて詳しく紹介されています。
私もこのページは何度も確認して移行方法を検討しました。
紹介しておきます。
古いフォレストに対して「スキーマ拡張」が必要なのは、そのフォレストに対してより新しいWindowsServerをドメインコントローラーに追加させるときであり、そのフォレストのドメインに参加させて「メンバーサーバー」とするだけであれば、古いフォレストのままで問題ありません。
例えば、今回のWindows 2000 Serverの古いフォレスト環境で、Windows Server 2019をドメインに参加させてメンバーサーバーとすることは可能です。
※古いフォレストはsmb1.0を使用しており、近年のWindows Serverではsmb1.0は脆弱性が存在しているために既定で無効化されています。その有効化が必要です。
スキーマ拡張の具体的な手順
今回の現行ADサーバーのフォレストは「Windows 2000 混在モード」でした。
これは、Windows2000よりさらに古いOSが混在する環境でも使用できる最も古い互換状態のドメインです。
このモードではスキーマ拡張はできないため、このモードを「Windows 2000 ネイティブモード」に変更します。
このモードは前述の「Windows 2000 混在モード」の上位モードです。
これはWindows 2000 ServerのGUIで変更が可能であり、さすがにWindows2000相当より古い環境は社内にはないので、さっさと変更してしまいます。
ActiveDirectoryの「スキーマ拡張」を実施する場合、まずは拡張するフォレストの機能レベルに対応したWindows Serverのインストールメディアが必要になります。
今回の作業で言えば、Windows Server 2008まで機能レベルを拡張するため、Windows Server 2008か、2008 R2のインストールメディアが必要です。
尚、当方の環境では、そのバージョンの正規のインストールメディアは保有していませんでしたが、Microsoftが提供している評価版のWindows Server 2008 R2 SP1のISOでもスキーマ拡張処理は実施可能です。
【注意】2020年2月更新
このリンク先のISOでは、後述する「adprep32.exe」がいつの間にか無くなっていました。
64bit用の「adprep.exe」しか入っていないため、32bitのWindows2000Serverのスキーマ拡張が出来なくなっています。
よって、当記事の手順を試す為には、ヤフオクなどでWindowsServer2008又は2008Rのインストールメディアを入手する必要があります。
実際の2000→2008へのスキーマ拡張手順は以下です。
2.同サーバーのコマンドプロンプトを起動し以下のコマンドを実行
インストールメディアの以下のパスにカレントディレクトリを移動します。
※CD/DVDドライブのドライブレターがEの場合
※32bit環境からWindows2008R2のメディアを使って拡張する場合
cd /d e:\support\adprep
3.adprep32.exeを実行してフォレストの拡張を実行
adprep32.exe /forestprep
4.adprep32.exeを実行してドメインの拡張を実行
adprep32.exe /domainprep /gpprep
この処理を実行することで、ADサーバーのOS自体はWindows 2000 Serverですが、ADのスキーマは2008 R2まで対応できる状態になりましま。
これで、Windows Server 2008を同じフォレストのドメインコントローラーとして追加することが可能になります。
5.DC移行用中間サーバーをドメインに追加
DC移行用中間サーバーをWindows 2000 Serverで稼働している現行のドメインに参加させます。
尚、当作業は特別な考慮は不要です。
普通にWindows Server 2008 R2のサーバーをドメインに参加させるだけであり、細かい手順については割愛します。
6.DC移行用中間サーバーをDCに昇格
現行のWindows 2000 Serverで稼働しているADのフォレストに対して、Windows Server 2008 R2のインストールメディアを使用してスキーマ拡張を実施したことで、「Windows 2000 ネイティブ」の機能レベルのドメイン内に、Windows Server 2008 R2のサーバーをドメインコントローラーとして追加できるようになりました。
スキーマ拡張を実施しないと、後述する「Active Directory ドメイン サービス インストール ウィザード」の途中で失敗します。
こちらも特に特別な作業はなく、一般的なドメインコントローラー追加作業を実施します。
- 「枠割の追加」から「Active Directory ドメインサービス」のインストール
- コマンドプロンプトを起動し dcpromo を実行
- Active Directory ドメインサービスインストールウィザード」でDCに昇格
7.DC移行用中間サーバーをネットワークから分離
ここからが少し構成がややこしくなります。
DC移行用中間サーバーを現行のADサーバーを配置している社内ネットワークから切り離します。
切り離すと言っても、当サーバーのホスト側のHyper-Vや、このHyper-V上で稼働している他の仮想マシンに関しては、別の業務で使用しているため、ネットワークの切断はできず、ADサーバーと同じネットワークセグメントに配置しておく必要があります。
そのため、Hyper-Vの設定にて、DC移行用中間サーバーの仮想スイッチの接続先ネットワークを「無し」に変更することにしました。
物理的にNICからLANケーブルを抜くのと同じ状態になります。
その後、独立したセグメントのIPアドレスを当サーバーに振り直します。
今回の例では192.168.2.0/24のIPアドレスを設定します。
当項の作業でネットワークを分離してIPアドレスを別のセグメントに付け替えています。
わざわざIPアドレスを付け替えているのは、今回の作業で使用するDC移行用中間サーバーを物理サーバーでは用意できずに、Hyper-Vの仮想マシンで用意したことが原因です。
もし中間サーバーを物理サーバーで用意できていたなら、単純にLANケーブルを中間サーバーと新ADサーバーに挿して物理的に独立したネットワークを作り出せる為、既存ネットワークと同じセグメントをIPアドレスに割り当てて作業を進めることができます。
当環境のHyper-Vでは、他にも業務上で必要なサーバーが稼働しており、ホストやその他のゲストは既存ネットワークに接続されている必要があります。
また、Hyper-Vでは、ゲストOSがホストの物理NICを直接使用させることができますが、その場合はそのゲスト専用の物理NICが必要になり、空いているNICはありませんでした。
そのために、いったんDC移行用中間サーバーや新ADサーバーのIPアドレスを独立したセグメントに変更して、論理的に両サーバー間しか通信できないネットワーク環境を構築したというのが理由です。
8.DC移行用中間サーバーをFSMO強制昇格
当項も今回の作業のポイントです。
ActiveDirectoryのドメインコントローラでは、主機器があり、副機器をいくつか構築して冗長化構成を取ります。
その主機器としての役割が「FSMO」です。
今回の作業では、この「FSMO」の役割を、既存のネットワークから切り離したDC移行用中間サーバーに対して強制的に付与します。
因みに、FSMOのドメインコントローラから副機器である通常のドメインコントローラに対してFSMOの役割を移すだけなら、ADが元々用意している機能で簡単に行えますが、今回は副機器側である通常のドメインコントローラを自らFSMOに強制的に昇格させるため、少し特殊な作業になります。
このFSMOの強制昇格は、主にFSMOの役割を持ってたドメインコントローラが故障して起動できないケースなどで実行するのが一般的です。
「ntdsutil」を使用したFSMO強制昇格
今回のドメインコントローラのFSMO強制昇格では、AD管理用コマンドツールの「ntdsutil」を使用します。
コマンドプロンプトを起動し、ntdsutilと入力してntdsutilを起動します。
尚、以下のコマンド操作例では、DC移行用中間サーバーのホスト名を「migrate_host.example.local」とし、現行のWindows 2000 ServerのDCのホスト名が「dc_host1.example.local(FSMO)」と「dc_host2.example.local」で作られている想定です。
※以下コマンド例の：以降を入力します。
C:\Users\Administrator.example.local>ntdsutil ntdsutil: roles fsmo maintenance: connections server connections: connect to server migrate_host.example.local migrate_host.example.local に結合しています... ローカルでログオンしているユーザーの資格情報を使って migrate_host.example.localに接続しました。 server connections: quit
ここまでで、ntdsutilを起動し、FSMOメンテナンスモードでDC移行用中間サーバーに接続しています。
fsmo maintenance: seize schema master 強制前に schema FSMO の安全転送を試みています。 ldap_modify_sW エラー 0x34(52 (利用できません). Ldap 拡張エラーメッセージ 000020AF: SvcErr: DSID-03210397, problem 5002 (UNAVAILABLE), data 8524 Win32 エラー 0x20af(要求された FSMO の操作に失敗しました。現在の FSMO の所有者に接続できませんでした。) ) エラー コードにより、接続、LDAP、または役割の転送エラーを示すことがあります。 schema FSMO の転送に失敗しました。強制処理 (seize) 中です... サーバー "migrate_host.example.local" は 5 個の役割を認識しています スキーマ - CN=NTDS Settings,CN=migrate_host,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local 名前付けマスター - CN=NTDS Settings,CN=dc_host1,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local PDC - CN=NTDS Settings,CN=dc_host1,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local RID - CN=NTDS Settings,CN=dc_host1,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local インフラストラクチャ - CN=NTDS Settings,CN=dc_host1,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local
まずはスキーママスターの役割をseizeで強制的に付与します。
出力メッセージの最初にエラーが発生していますが、これはメッセージにあるように、強制処理前に必ず正規の役割の転送処理ができるかを試みる処理が動いているからです。
正規の転送処理を実行しようとしても、当然元のFSMOとはネットワークが分断されており、通信ができないためにエラーになります。
その後、役割の強制移譲処理が動きます。
fsmo maintenance: seize naming master ※以下省略 fsmo maintenance: seize pdc ※以下省略 fsmo maintenance: seize rid master ※以下省略 fsmo maintenance: seize infrastructure master ※以下省略 fsmo maintenance: quit ntdsutil: quit
続いて、他の役割も強制的に移していきます。
・ドメイン名前付けマスター
・PDC エミュレーター
・RID マスター
・インフラストラクチャ マスター
実行後に出力されるメッセージはどれも同じような内容なので省略します。
これで、DC移行用中間サーバーに対して、FSMOの役割を持たせることができました。
尚、ntdsutilのseizeの詳しい内容については、Microsoftの以下の記事をご参照ください。
9.DC移行用中間サーバーの旧DC情報を削除
前項でDC移行用中間サーバーをFSMOに強制的に昇格しました。
次に、ネットワーク分離前に元にWindows 2000 ServerのFSMOから同期した他のドメインコントローラーの情報をDC移行用中間サーバーから削除します。
旧ドメインコントローラー情報を綺麗に削除しておかないと、新ADサーバーは最終的に元のFSMOと同じホスト名でドメインコントローラーに昇格させますから、その際にエラーになります。
今回のドメインコントローラー情報の削除では、AD管理用コマンドツールの「ntdsutil」を使用します。
コマンドプロンプトを起動し、ntdsutilと入力してntdsutilを起動します。
尚、以下のコマンド操作例では、DC移行用中間サーバーのホスト名を「migrate_host.example.local」とし、現行のWindows 2000 ServerのDCのホスト名が「dc_host1.example.local」と「dc_host2.example.local」で作られている想定です。
※以下コマンド例の：以降を入力します。
C:\Users\Administrator.example.local>ntdsutil ntdsutil: metadata cleanup metadata cleanup: connections server connections: connect to server migrate_host.example.local host_name.example.local に結合しています... ローカルでログオンしているユーザーの資格情報を使って migrate_host.example.localに接続しました。 server connections: quit
ntdsutilを起動し、メタデータクリーンアップモードでDC移行用中間サーバーに接続しています。
metadata cleanup: select operation target select operation target: list domains 1 個のドメインを検出しました 0 - DC=example,DC=local select operation target: select domain 0 現在のサイトがありません ドメイン - DC=example,DC=local 現在のサーバーがありません 現在の名前付けコンテキストがありません
メタデータ削除対象を絞り込んでいきます。
この例では対象のDCで管理しているドメインは一つなので、1個のドメインを検出しています。
一つしか無いので、番号は0番です。
それを「select domain」で選択しています。
select operation target: list sites 1 個のサイトを検出しました 0 - CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local select operation target: select site 0 サイト - CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local ドメイン - DC=example,DC=local 現在のサーバーがありません 現在の名前付けコンテキストがありません
次に絞り込んだドメイン内のサイトを絞り込みます。
この例ではサイトも一つしかありません。
「select site」で0番を選択しています。
select operation target: list server in site
3 個のサーバーを検出しました
0 - CN=dc_host1,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local
1 - CN=dc_host2,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local
2 - CN=migrate_host,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local
select operation target: select server 0
サイト - CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local
ドメイン - DC=example,DC=local
サーバー - CN=dc_host1,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local
DSA オブジェクト - CN=NTDS Settings,CN=dc_host1,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local
DNS ホスト名 - dc_host1.example.local
コンピューター オブジェクト - CN=dc_host1,OU=Domain Controllers,DC=example,DC=local
現在の名前付けコンテキストがありません
select operation target: quit
次に、絞り込んだサイト内のドメインコントローラーを絞り込みます。
今回の例では、dc_host1とdc_hodt2が削除対象のドメインコントローラーです。
まずは「select server」で0番を指定します。
サーバーを指定したら、いったんquitで抜けます。
metadata cleanup: remove selected server 選択されたサーバーから FSMO 役割を転送/強制処理しています。 選択されたサーバーのために FRS メタデータを削除しています。 "CN=example,OU=Domain Controllers,DC=example,DC=local" 下で FRS メンバーを検索しています。 FRS メンバー "CN=example,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=example,DC=local" を削除しています。 "CN=example,CN=Domain System Volume (SYSVOL share),CN=File Replication Service, CN=System,DC=example,DC=local" 下のサブツリーを削除しています。 "CN=example,OU=Domain Controllers,DC=example,DC=local" 下のサブツリーを削除しています。 CN=example,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local 上の FRS 設定の削除に失敗しました。原因は次のとおりです: "要素が見つかりません。"; メタデータのクリーンアップは続行されます。 "CN=example,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local" をサーバー "migrate_host.example.local"から削除しました metadata cleanup: quit ntdsutil: quit
冒頭の「remove selected server」を入力すると、以下のメッセージが表示されます。
このメッセージで「はい」を押下すると、選択したドメインコントローラーを削除します。
出力されたメッセージを見ると、一部エラーが出ていますが、一応削除はされていました。
尚、metadata cleanupの詳しい内容については、Microsoftの以下の記事をご参照ください。
尚、ドメインコントローラはプライマリとセカンダリの二つ存在するので、上記と同様の操作でセカンダリ側のDC情報も削除します。
10.DC移行用中間サーバーのDNS旧DC情報を削除
前項ではコマンドツールの「ntdsutil」を使用してドメインコントローラー側の不要な情報を削除しましたが、DNS側でも現行のドメインコントローラーの情報が残ってしまっているので、同様に削除します。
尚、DNS側では「ntdsutil」のようなツールは存在しないので、「DNSマネージャー」を起動して、関連するレコードを一件ずつ削除していきます。
「前方参照ゾーン」と「逆引き参照ゾーン」が対象です。
11.DC移行用中間サーバーのフォレスト機能レベル変更
DC移行用中間サーバーのフォレスト機能レベルをWindows 2000 ネイティブからWindows Server 2008 へ変更します。
DC移行用中サーバーの「Active Directory ドメインと信頼関係」を右クリックして、「フォレストの機能レベルの昇格」を選択し、「Windows 2000 ネイティブ」から「Windows Server 2008」に変更します。
※フォレストを上げると、自動的にドメインの機能レベルも同等に上がります。
12.新ADサーバーをDC移行用中間サーバーのドメインに追加
新ADサーバーを、DC移行用中間サーバーのドメインに参加させてメンバーサーバーにします。
尚、前述の「7.DC移行用中間サーバーをネットワークから分離」にて、DC移行用中間サーバーは仮想スイッチからネットワークと切断しており、更に社内ネットワーク用のセグメントから変更しています。
よって、以下の作業を併せて実施します。
- DC移行用中間サーバーの仮想スイッチを再度ネットワークに接続
- 新ADサーバーのIPアドレスのセグメントをDC移行用中間サーバーのセグメントに変更
- 新ADサーバーのホスト名を現行ADサーバーのプライマリ機と同じ名前に変更
- 両サーバー間で通信ができるのを確認したうえで、新ADサーバーをドメイン参加
ドメインに参加させる作業手順については、一般的なドメイン参加手順と同じなので割愛します。
尚、新ADサーバーのIPアドレス設定時の参照先DNSは必ずDC移行用中間サーバーのIPアドレスに向けておかないとドメイン参加時にエラーになるので注意してください。
13.DC移行用中間サーバーのSYSVOLをDFSRに変更
次の作業では、新ADサーバーをドメインコントローラーに昇格させますが、その前にDC移行用中間サーバーのSYSVOLをFRSからDFSRに変更しておく必要があります。
Windows Server 2008 R2で新しくActiveDirectoryを作成する場合、SYSVOLの既定のレプリケート方式は「DFSR」です。
ただ、今回の作業のように、更に古いドメインコントローラーから移行してきた場合は、SYSVOLのレプリケート方式は「FRS」が設定されています。
Windows Server 2019の場合「FRS」には対応しておらず、新しいWindow Serverをドメインコントローラーに昇格させる場合はSYSVOLのレプリケート方式を必ず「DFSR」に変更する必要があります。
SYSVOLとレプリケーション方式について
「SYSVOL」とは、ドメインコントローラー間で共有するファイルを格納するための専用共有フォルダです。
このSYSVOLにグループポリシーファイルやログオンスクリプトファイルなどを格納し、別のドメインコントローラーに複製しています。
また、そのレプリケーション方式についても種類があり、古いドメイン機能レベルでは「FRS (File Replication System)」が使われており、新しいドメイン機能レベルでは「DFS-R (Distributed File System Replication)」が使われています。
FRS：ファイル単位での同期処理で転送量が大きい。
DFS-R：ファイルのブロック単位の差分のみの同期処理で転送量が少なく効率的。
FRSからDFSRへの変更手順
今回の作業では、DFSレプリケーションサービスの移行ツールである dfsrmig.exe を使用します。
DC移行用中間サーバーのコマンドプロンプトを起動して、以下のコマンドを順次実行していきます。
C:\Users\Administrator.EXAMPLE>dfsrmig /createglobalobjects DFSR の現在のグローバル状態: '開始' 成功しました。
dfsrmigで処理が開始できる状態にします。
dfsrmig /setglobalstate 1 DFSR の現在のグローバル状態: '開始' 新しい DFSR のグローバル状態: '準備完了' '準備完了' 状態に移行します。DFSR サービスによって SYSVOL が SYSVOL_DFSR フォルダーにコピーされ ます。 いずれかの DC で移行を開始できない場合は、手動ポーリングを試行してください。 または、/CreateGlobalObjects オプションを指定して実行してください。 移行は 15 分から 1 時間までの任意の時点で開始できます。 成功しました。
グローバル移行状態を「準備済み」に設定します。
C:\Users\Administrator.EXAMPLE>dfsrmig /GetMigrationState
すべてのドメイン コントローラがグローバル状態 ('準備完了') に移行しました。
移行状態が、すべてのドメイン コントローラ上で整合性のとれた状態になりました。
成功しました。
今回の作業ではドメインコントローラーは自身だけなのですぐに「準備完了」になります。
一応 GetMigrationState で準備完了になったかを確認し、準備完了になるまで待ちます。
※複数DCが存在する場合は、各DCへの処理の伝達に時間が掛かります。
C:\Users\Administrator.EXAMPLE>dfsrmig /setglobalstate 2 DFSR の現在のグローバル状態: '準備完了' 新しい DFSR のグローバル状態: 'リダイレクト済み' 'リダイレクト済み' 状態に移行します。SYSVOL 共有が、 DFSR を使用してレプリケートされた SYSVOL_DFSR フォルダーに変更されます。 成功しました。
状態を「リダイレクト済み」に設定します。
C:\Users\Administrator.EXAMPLE>dfsrmig /GetMigrationState
すべてのドメイン コントローラがグローバル状態 ('リダイレクト済み') に移行しまし
た。
移行状態が、すべてのドメイン コントローラ上で整合性のとれた状態になりました。
成功しました。
GetMigrationState でリダイレクト済みになったかを確認し、リダイレクト済みになるまで待ちます。
C:\Users\Administrator.EXAMPLE>dfsrmig /setglobalstate 3 DFSR の現在のグローバル状態: 'リダイレクト済み' 新しい DFSR のグローバル状態: '削除済み' '削除済み' 状態に移行します。このステップを元に戻すことは できません。 いずれかの RODC が長時間にわたって '削除済み' 状態になって いる場合は、/DeleteRoNtfrsMembers オプションを指定して実行してください。 成功しました。
状態を「削除済み」に設定します。
C:\Users\Administrator.EXAMPLE>dfsrmig /getmigrationstate
すべてのドメイン コントローラがグローバル状態 ('削除済み') に移行しました。
移行状態が、すべてのドメイン コントローラ上で整合性のとれた状態になりました。
成功しました。
GetMigrationState で削除済みになったかを確認し、削除済みになるまで待ちます。
これで「DFSR」への変更処理が完了です。
変更されているかを確認してみましょう。
C:\Users\Administrator.EXAMPLE>net share
共有名 リソース 注釈
-------------------------------------------------------------------------------
C$ C:\ Default share
IPC$ Remote IPC
ADMIN$ C:\Windows Remote Admin
NETLOGON C:\Windows\SYSVOL_DFSR\sysvol\example.local\SCRIPTS
Logon server share
SYSVOL C:\Windows\SYSVOL_DFSR\sysvol Logon server share
コマンドは正常に終了しました。
net share コマンドで自環境の共有フォルダを確認できます。
NETLOGONとSYSVOLのリソースのパスが「SYSVOL_DFSR」になっているのが確認できます。
これで成功です。
尚、今回使用したdfsrmigに関する詳しい仕様については以下のMicrosoftのリンクをご参照ください。
14.新ADサーバーをDCに昇格
新ADサーバーをドメインコントローラーに昇格させます。
尚、手順としては「機能と枠割の追加」からActive Directory ドメインサービスのインストールして、その後「Active Directory 構成ウィザード」を起動して処理を進めます。
一般的な、既存ドメインに対するドメインコントローラーの追加手順なので、細かい手順は割愛します。
15.DC移行用中間サーバーのFSMOを新サーバーに転送
これは「8.DC移行中間サーバーをFSMO強制昇格」で実施した強制的なFSMO昇格ではなく、通常のFSMO転送処理です。
各ドメインコントローラーが正常に稼働している状態で、ネットワークで両ドメインコントローラーが接続できている状態であれば、安全にFSMOの役割を異なるDCに移行することができます。
FSMOの転送では、FSMOの強制昇格でも使用した「ntdsutil」を使用します。
また作業するサーバーは新ADサーバー側です。
コマンドプロンプトを起動して操作していきます。
まずはどのドメインコントローラーがFSMOの役割を持っているのかをnetdomコマンドで確認しておきます。
C:\Users\Administrator.EXAMPLE>netdom /query fsmo スキーマ マスター migrate_host.example.local ドメイン名前付けマスター migrate_host.example.local PDC migrate_host.example.local RID プール マネージャー migrate_host.example.local インフラストラクチャ マスター migrate_host.example.local コマンドは正しく完了しました。
想定通りDC移行用中間サーバーが設定されていれば問題無いです。
以降の処理では、ntdsutilでFSMOの役割を転送していきます。
C:\Users\Administrator.EXAMPLE>ntdsutil ntdsutil: roles fsmo maintenance: connections server connections: connect to server dc_host1.example.local dc_host1.example.local に結合しています... ローカルでログオンしているユーザーの資格情報を使って dc_host1.example.local に接 続しました。 server connections: quit
FSMOメンテナンスモードで新ADサーバーに接続しました。
C:\Users\Administrator.EXAMPLE>fsmo maintenance: transfer schema master サーバー "dc_host1.example.local" は 5 個の役割を認識しています スキーマ - CN=NTDS Settings,CN=dc_host1,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local 名前付けマスター - CN=NTDS Settings,CN=migrate_host,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local PDC - CN=NTDS Settings,CN=migrate_host,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local RID - CN=NTDS Settings,CN=migrate_host,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local インフラストラクチャ - CN=NTDS Settings,CN=migrate_host,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=local
スキーマーマスターを転送しました。
FSMO強制昇格時には「seize」を指定していましたが、今回は転送なので「transfer」を指定します。
fsmo maintenance: transfer naming master ※以下省略 fsmo maintenance: transfer pdc ※以下省略 fsmo maintenance: transfer rid master ※以下省略 fsmo maintenance: transfer infrastructure master ※以下省略 fsmo maintenance: quit ntdsutil: quit
続いてその他の役割も転送していきます。
出力されるメッセージはスキーマーマスターとほぼ同じなので省略します。
これでFSMOの役割が新ADサーバーに移動しました。
それでは再度netdomコマンドでFSMOのドメインコントローラーを確認してみましょう。
C:\Users\Administrator.EXAMPLE>netdom /query fsmo スキーマ マスター dc_host1.example.local ドメイン名前付けマスター dc_host1.example.local PDC dc_host1.example.local RID プール マネージャー dc_host1.example.local インフラストラクチャ マスター dc_host1.example.local コマンドは正しく完了しました。
無事FSMOが移動しているのを確認できました。
16.DC移行用中間サーバーをDCからメンバーサーバーへ降格
FSMOの役割をDC移行用中間サーバーから新ADサーバーに転送したことで、DC移行用中間サーバーは不要になります。
その為、DC移行用中間サーバーをドメインコントローラーから通常のメンバーサーバーへ降格します。
不要になったドメインコントローラーは適切に降格させておかないと、後からまた「ntdsutil」の metadata cleanup を使って強制的に削除することが必要になり面倒です。
現時点の状態であれば、新ADサーバーとDC移行用中間サーバーは独立したネットワークで相互に接続しているため、正規の降格手順で実施することができます。
DC降格手順
ドメインコントローラーをメンバーサーバに降格させる際の手順も簡単に紹介しておきます。
まず、「スタート」→「ファイル名を指定して実行」にて dcpromo と入力して実行します。
「Active Drectory ドメインサービス インストールウィザード」が起動します。
取り敢えず「次へ」を押下します。
確認メッセージが表示されるので、「OK」を押下します。
ドメイン内の最後のコントローラーかを指定する画面が表示されます。
既定ではチェックは外れていますが、必ずチェックは外したまま「次へ」を押下します。
十分に注意してください。
次に「DNS委任の削除」画面が表示されたはずですが、どうもスクリーンショットを撮り忘れたようなので、画面の画像はありません。
当画面の「このサーバを指しているDNS委任を削除する」は既定でチェックが付いているため、そのまま「次へ」を押下します。
降格後のAdministratorのパスワードを指定する画面が表示されます。
ドメインコントローラーから外れるとローカルのAdministratorも必要になるため、ここでパスワードを再度設定します。
適切なパスワードを指定して「次へ」を押下します。
設定のエクスポートができる画面が表示されます。
今回の作業ではエクスポートは不要なので、このまま「次へ」を押下します。
ドメインコントローラー降格処理が開始されます。
具体的にはActiveDirectoryなどのアンインストール処理を実行しています。
ウィザードが終了しました。
これでドメインコントローラーの降格処理が完了です。
17.新ADサーバーをネットワークから切断し本番IPアドレスを適用
新ADサーバーは社内ネットワークから切り離したセグメントのIPを割り当てて、社内ネットワークとの通信をできないように制御していましたが、ここで物理的にLANケーブルを抜いて、ネットワークから完全に切断します。
その後、コンソールから直接新ADサーバーを操作して、IPアドレスを現行ADサーバーと同じIPアドレスに付け替えます。
これで、新ADサーバーのホスト名及びIPアドレスは共に、現行ADサーバーと同じ設定になりました。
ホスト名とIPアドレスが現行ADサーバーと同じで、且つAD内のデータベースやDNSの情報が同一であれば、現行ADサーバーのLANケーブルを新ADサーバーに差し替えるだけで本番サーバーの切り替え作業が終わります。
尚、新ADサーバーのIPアドレスを変更したことで、DNSのAレコードなどのIPアドレスも自動的に変更が適用されると思いますが、念のため、新ADサーバー内のDNSも、変更後のIPアドレスが適用されているかを確認しておいてください。
18.現行ADサーバー(旧サーバー)を新ADサーバーへ切り替え
いよいよ本番機の切り替え作業です。
切り替え作業は前述した通り、LANケーブルを現行ADサーバーから新ADサーバーに差し替えるだけです。
また、現行ADサーバーのセカンダリ機は、「9.DC移行用中間サーバーの旧DC情報を削除」の作業にて、新ADサーバーのドメイン情報から削除してあります。
よって、切り替えた際にセカンダリ機が残っているとDCの整合性が取れなくなるため、切り替え作業の直前に現行ADサーバーのセカンダリ機は停止しておきます。
では、思い切ってLANケーブルを差し替えて本番機を切り替えてみましょう！
因みに、私がこの本番切り替え作業を実施したタイミングは、深夜とか早朝といったユーザーが使っていない時間ではなく、お昼休憩時間にしました。
なんせ問題があればすぐに切り戻しができる前提であり、切り替え自体もLANケーブルを差し替えるだけで済むので、理論上のダウンタイムは僅かだからです。
切り替え作業の際に、予め自身の端末からADサーバーに対して Ping -tでPingを飛ばし続けていましたが、LANケーブル切り替え時のダウンタイムは約3秒程度でした。
クライアントからみたら、参照していたドメインコントローラーが突然新しい機能レベルのフォレストに変わった状態になる訳で、何らかの問題が出ることも想定していましたが、特に問題は発生せず、ユーザーはドメインコントローラーが切り替わったことに気付かないまま業務をしていました。
万が一切り替え後に問題が発生した場合は、すぐに元々のADサーバーにLANケーブルを差し替えれば、切り戻しは完了です。
これで本番ADサーバーのFSMOの役割を持つプライマリ機の切り替えが完了しました。
お疲れまでした。
19.切り替え後の残作業
前項の作業で、ADサーバーのプライマリ機の切り替えが完了しましたが、後は以下の残作業があります。
- ADのセカンダリ機の構築及びDC追加
- フォレストの機能レベルをWindows Server 2016に変更
まず、前項で実施したADのプライマリ機の入れ替えが正常にできている限り、セカンダリのドメインコントローラー追加作業は、一般的なDC追加作業と同じで結構です。
ADのドメインコントローラーは、一般的には2台の冗長構成が推奨されますが、必ず2台の構成を組まないといけない訳ではなく、プライマリ機1台だけで稼働させても問題はないのですが、ADは社内の認証基盤であり重要なサーバーであるため、なるべく早くにセカンダリを追加して冗長化を実施しておきましょう。
また、今回の切り替え作業では、実はフォレストの機能レベルを2008まで上げた状態で止まっており最新の機能レベルである2016までは上げていません。
現時点ではプライマリ側の「Active Directory ドメインと信頼関係」からいつでも2016に上げられる状態になっています。
当移行作業の一番の目的はADサーバーをWindows 2000 ServerからWindows Server 2019に移行することであり、フォレストを最新の機能レベルまで上げるのは現時点では必須ではありません。
また、フォレストの機能レベルを一度上げると、後から下のレベルに戻すことはできません。
よって、切り替えが済んだ新しいADサーバーのバックアップを取得して万が一に備えておきつつ、2016の機能レベルで十分に検証してから新ADサーバーのフォレストの機能レベルの変更に臨みましょう。
それらが済めば、長かったADサーバー移行作業が完全に終了したと言えます。
最後に
今回の記事では、Windows 2000 Serverで稼働しているActiveDirectoryをWindows Server 2019に移行する場合の作業手順や移行方法を紹介しました。
冒頭でも記載した通り、今回の記事のように、いまだにWindows 2000 ServerでADを稼働させている環境はそれほど多くは無いかと思います。
その為、記事内容自体にはそれほど需要が無いかも知れませんが、そもそも、Microsoftのサポート切れに合わせて適切な時期にサーバーを更改していれば、今回の様な面倒な作業はしなくても済みます。
よって、適切な時期にサーバーを更改しないと、こんな面倒な作業が必要になるのか！？と反面教師として記事を読んでいただけますと幸いです。
今回も長々と記事を読んでいただきましてありがとうございました。
それでは皆さまごきげんよう！
今回の記事は2万5千文字近いボリューム
大変だった・・・
