Windows Server環境で運用中のドメイン名を変更する際には、既存の仕組みに依存するアプリケーションやユーザーアカウントなどさまざまな影響を考慮する必要があります。スムーズな移行のためには、事前のバックアップやテストの実施がとても重要です。本記事では、Active DirectoryとDNSを「example.com」から「test.com」に移行する際のポイントや具体的な手順、さらに注意すべき点を丁寧に解説します。将来的なシステムトラブルの予防やユーザーの混乱を減らすためにも、移行計画を綿密に立てて確実にステップを踏んでいきましょう。
ADとDNS移行の背景と重要性
ドメイン名の変更は、単なる文字列の置き換えにとどまらず、組織のIT基盤全体に影響を及ぼす大きなプロジェクトです。特に、Active Directory(AD)はWindows環境全体のユーザー管理やセキュリティ、ポリシー管理の中核を担うため、その設定を変更することは運用に直結します。またDNSはネットワーク上で名前解決を担う重要な役割を果たしており、ADやほかのサーバーサービスが正しく動作するうえで必要不可欠です。
ドメイン名変更の主な動機
- 組織変更や社名変更に伴い、社外からの信頼性やブランドイメージを統一するため
- 組織統合やM&Aなどでドメイン統合を図りたい
- セキュリティ要件の見直しにより、新規ドメイン環境の構築が求められる
ドメイン名を変えること自体はコマンドで実施できますが、一般的には「新規ドメインを構築し、そこにユーザーやコンピューターを移行」するアプローチが推奨されるケースが多いです。これは既存環境への影響を最小限に抑えながらも、新環境での動作確認をしっかりと行える利点があるためです。
移行前に行うべき準備
移行の計画段階で、以下の事前準備を確実に実施しておくと、トラブルを未然に防ぎやすくなります。
現状調査とリスク分析
- 既存ADの構成調査
- どのドメインコントローラー(DC)が稼働中か
- FSMO(Flexible Single Master Operations)役割を持つサーバーの把握
- グループポリシーオブジェクト(GPO)やログオンスクリプトの確認
- DNSの設定調査
- フォワーダー(Forwarder)やルートヒント(Root Hints)の設定
- プライマリゾーンとセカンダリゾーンの有無
- レコードの重複や誤設定の洗い出し
- 依存関係の洗い出し
- LDAPやKerberos認証を利用するアプリケーション、ファイルサーバー、SQLサーバー
- AD DSに基づくユーザー認証が必須なシステム全般
- 証明書サービス(AD CS)の有無と構成
バックアップとリスクマネジメント
- ADのバックアップ: Windows Server標準のバックアップツール、またはサードパーティーツールを用いてシステム状態を含むAD全体をバックアップ
- DNSゾーンのエクスポート: 移行に備えてゾーンファイルをエクスポートし、万が一に備える
- 復旧計画の策定: 最悪の場合はバックアップからリストアできるように、手順書とテストを実施
新しいドメイン環境の構築
移行を行う前に、まずは「test.com」の新規環境を整える必要があります。移行を円滑に進めるためにも、新しいドメインコントローラーを段階的にセットアップし、その後に既存ADからユーザーやコンピューターを移行するのが一般的です。
新ドメインコントローラー(DC)の構築
- Windows Serverのインストール
新規サーバーにWindows Serverをインストールし、最新の更新プログラムを適用しておきます。 - Active Directory Domain Services(AD DS)のインストール
以下の手順でAD DS役割を追加します。
- サーバーマネージャーから「役割と機能の追加」を実行
- 「Active Directory Domain Services」を選択
- 新ドメインの作成
- 「dcpromo」を使う、あるいはサーバーマネージャーのウィザードに従ってドメインコントローラーを昇格
- ドメイン名として「test.com」を指定
信頼関係の設定
旧ドメイン「example.com」と新ドメイン「test.com」の間でオブジェクトを行き来できるようにするため、必要に応じて「双方向の信頼関係」を設定します。これにより、移行するユーザーやグループが新ドメインを参照できるようになります。
信頼関係の作り方
- 「Active Directory Domains and Trusts」を起動
- 旧ドメイン名を右クリックし、「信頼関係のプロパティ」から新しい信頼関係を追加
- 双方向・一方向など、移行計画に応じて最適な形を選択
ADMTを利用したオブジェクト移行
Active Directory Migration Tool(ADMT)は、Microsoftが提供する移行支援ツールです。ユーザー・グループ・コンピューターなどのオブジェクトを、旧ドメインから新ドメインへ移行する際に利用します。
ADMTのインストールと前提条件
- SQL ServerまたはSQL Express
ADMTは移行情報をデータベースに書き込むため、SQL Server環境が必要です。SQL Server Expressでも問題ありません。 - PES(Password Export Server)のセットアップ
ユーザーパスワードを新ドメイン側に移行する場合、PESを利用して暗号化された形でパスワード情報を転送します。 - バージョンの確認
- ADMTの最新バージョンは3.2(Windows Server 2012用)ですが、現在はサポートが終了しているため、実環境での利用時には事前検証が重要
- Windows Serverのバージョンとの互換性にも注意
ADMTの基本移行手順
- ADMTのインストール
- 新ドメイン側にADMTをインストール
- セットアップウィザードに従ってSQL接続設定などを完了させる
- 移行ウィザードの起動
- ユーザー、グループ、コンピューターなど移行対象を選択
- オプション設定でSID履歴のコピーやパスワード移行を有効にする
- テストグループの移行
- まずは少数のユーザーやコンピューターを選んでテスト移行
- ログオン確認やアプリケーション動作確認を行う
- 本格移行
- 問題がなければ、規模を拡大してすべてのオブジェクトを移行
DNS移行と設定更新
新ドメイン「test.com」に合わせてDNSの設定も変更する必要があります。特にAD統合DNSを利用している場合、正しくドメインを解決できるようにレコードを整合させることが重要です。
新ドメインにおけるDNSの役割分担
- プライマリゾーンの作成
- 「test.com」用のプライマリゾーンを新ドメインコントローラー上で作成
- AD統合ゾーンとすることで、複数のドメインコントローラー間でゾーン情報を自動同期
- フォワーダーや条件付きフォワーダーの設定
- 旧ドメインの名前解決が必要であれば、「example.com」を解決できるDNSサーバーをフォワーダーとして追加
- 特定のサブドメインだけをフォワードするような条件付きフォワーダー(Conditional Forwarder)を設定
- レコード移行
- 旧DNSからSRVレコードやAレコードなどを必要に応じて移行
- 権限設定(ACL)がある場合は、新DNSに合わせて付与を見直し
DNS移行時のトラブルシューティング例
| 症状 | 考えられる原因 | 対策 |
|---|---|---|
| 新ドメインのホスト名が解決できない | DNSゾーンの設定ミス、伝播遅延 | ゾーン設定を再確認し、レプリケーション待機 |
| 旧ドメインと通信が不安定 | 信頼関係の設定不備、フォワーダー不正 | 信頼関係やフォワーダーの設定を再確認 |
| SRVレコードが登録されない | DCプロモーション不完全 | DCのイベントログを確認、再度dcpromo実行 |
ユーザープロファイルの移行と注意点
ユーザーアカウントのSIDが変わることに伴い、既存のPCでのユーザープロファイルが新ドメイン移行後に正しく読み込めなくなるケースがあります。ADMTのSID履歴コピー機能を使う場合もありますが、それだけではローカルキャッシュプロファイルが移行できないこともあるため、以下のような対策を検討します。
プロファイル移行のアプローチ
- User State Migration Tool(USMT)
- Microsoft公式ツールで、ユーザープロファイルやドキュメント、レジストリ設定をバックアップし、新しいドメイン環境へ移行
- ローカルプロファイルを手動でリネーム
- C:\Users\olduser などを C:\Users\newuser にコピー後、レジストリを書き換える手法
- 手間がかかるうえにトラブル発生リスクもある
- 段階的移行
- 新ドメインへの参加後、新たに作成されたプロファイルへ必要なファイルを移動し、ユーザーが手作業で環境を再構築
グループポリシー(GPO)への影響
GPOもドメイン名やSIDに依存している場合があります。移行後にポリシーが効かなくなったり、適用範囲が崩れたりすることがあるため、以下をチェックします。
- GPOリンク先(OU構造)の変更
- セキュリティフィルターの再設定
- スクリプト内のドメイン名ハードコーディング部分を修正
移行後の検証と運用
無事にドメイン移行が完了した後も、しばらくは旧ドメインと新ドメインを併用しつつトラブル監視を行うのが一般的です。
移行後のチェックリスト
- ユーザーのログオン確認
- ユーザーが新ドメインにログオンできるか
- グループポリシーが正常に適用されているか
- アプリケーションの動作確認
- SQL Serverやファイルサーバーなど主要システムへのアクセス
- 社内ポータルやWebアプリケーションが正常に動作するか
- DNSのクリーンアップ
- 旧ドメインのレコードを削除または不要レコードをクリーンアップ
- 不要になったゾーンの整理
旧ドメインの段階的廃止
- ユーザーが全員新ドメインに移行し、安定稼働を確認
- 旧ドメインのDNSゾーンを削除または停止
- 旧ドメインコントローラーを降格(dcpromoでAD DSのアンインストール)
- 旧ドメインの存在が不要になったらDNSから最終的にゾーンを削除
トラブルシューティングとベストプラクティス
実際の移行では予期せぬトラブルが発生することも少なくありません。以下のポイントを踏まえておくと、問題が起きた際にスムーズに対処できます。
ドメイン名変更 vs. 新規ドメイン構築
- ドメイン名のリネームツール(rendom.exe)を使用する方法もありますが、運用中の環境では非推奨とされています。
- 既存ドメインのまま名称を変えると、GPOや証明書、アプリケーション設定などあらゆる箇所で不整合が起きるリスクが高いです。
- そのため、多くの場合は「新ドメインを構築し、移行」という手法が選ばれます。
ゼロダウンタイムを目指す運用
- 段階的にユーザーを移行することで、業務時間中に移行しても被害を抑える
- 旧ドメインとの信頼関係を維持しながら、新ドメインへユニット単位で移行
計画・テスト・実装の流れを徹底
- 計画(Plan): 要件整理、リソース確認、移行範囲の確定
- テスト(Test): テスト環境で移行のリハーサルを実施
- 実装(Do): 本番移行を行い、段階的にユーザーを移行
- 検証(Check): 移行結果を評価し、問題点を修正
まとめと今後の展望
ドメイン名を変更するプロジェクトは、多岐にわたる知識と段取りが必要です。特にADとDNSはWindowsサーバー基盤の根幹を担っているため、以下のポイントを押さえて安全に移行しましょう。
- 事前にバックアップを取り、テスト環境での検証を入念に行う
- 信頼関係の構築やADMTを用いたオブジェクト移行で段階的に進める
- DNSの設定確認やレコード移行、GPOの再設定を丁寧に行う
- 移行後もしばらくは旧環境と並行運用し、トラブルを監視する
結果的に、組織全体のセキュリティや管理性の向上につながり、将来的な拡張やクラウド連携などの施策を進めやすくなります。是非、本記事でご紹介した手順やポイントを参考に、安心・安全なドメイン移行を実現してください。
コメント