SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

ドメインコントローラーの入れ替えに伴う基本的な作業について

11 comments

Active Directory (AD) のドメインコントローラー (DC) をハードウェア老朽化に伴い、新規ハードウェアを購入しセットアップを行うというシナリオを実施する際に必要となる基本的な作業について少しまとめてみたいと思います。
アイティデザイン株式会社様が公開されている Windows Server 2003 サポート終了対策 もとても参考になりますので、こちらも合わせて確認をするとよいかと。
2015/7/15 に Windows Server 2003 のサポートが切れると、問題発生時に問い合わせができなくなりますので、今後 2003 から移行される場合には、十分にリスクや、問題発生時のアクションを明確にする必要性が出てきます。
Windows Server 2003 のサポート終了
Windows Server 2003 延長サポート終了に伴う ターミナル サーバー ライセンス のアクティブ化に関する注意事項

■Winodws Server 2012 R2 の DC を追加する前に確認しておきたい情報



Windows Server 2003 のドメインに、 Windows? Server 2012 R2 を使用してドメインコントローラーを追加する場合は、
Windows Server 2012 R2 をドメイン コントローラーとして Windows Server 2003 で構成された Active Directory ドメインに追加後、ログオン障害が発生する

の情報を確認しておくとよいかと思います。
Windows Server 2012 R2 にドメインコントローラーの役割を追加し、ドメインコントローラーに昇格する前に (ドメインコントローラーとしてのセットアップを実施する前)、KB 2919355 / KB 2989971 を適用しておくことで本問題を回避することができます。
# ポイントはドメインコントローラーとして追加する前に対応することかと。
また、Windows Server 2012? / R2 のドメインコントローラーを Hyper-V の仮想環境上に構築し、IDE 接続をしている場合は IDE に接続されている仮想ハード ディスクでハイパー-V のホスト サーバーで発生した、計画外の再起動との整合性の損失 も合わせて確認をしておくとよいかと思います。
 

■初期の構成


本当は DC を複数台用意したほうが良いのですが今回は 1 台のみ準備をしています。
OS は Windows Server 2003 R2 を使用しています。

image
この環境に DC を追加して入れ替える流れを見ていきます。
Windows Server 2000 ~ Windows Server 2008 R2 までは [dcpromo] を実行して AD のインストールウィザードを開始します。
image
Windows Server 2012 以降はサーバーマネージャーを実行します。
 


同一の OS のバージョンを使用した DC を追加するのであれば AD の準備 (スキーマ拡張等) は不要ですが老朽化対応で DC を追加する場合、最新のバージョンの OS の導入を検討することがあると思います。
今回は、同一のバージョンではなく Windows Server 2012 RC に入れ替えるシナリオとしたいと思います。
新しいバージョンの OS を DC として追加する場合、フォレストやドメインに対して ADPREP を実行して更新をかける必要があります。
各 OS のインストールメディアには、ADPREP.exe が含まれていますので、既存のドメインコントローラー上でこのプログラムを実行します。

なお、Adprep については以下の技術情報が参考になります。
Adprep.exe の実行
基本的な作業としては、

  • フォレストに対しての準備
  • ドメインに対しての準備

の 2 種類の準備作業を実施します。
適切な準備作業が行われていないと、DC 追加時に以下のようなエラーが発生します。
image
 
adprep 実行時の注意点
既存のドメインコントローラーは Windows Server 2003 R2 x64 を使っているので Windows Server 2012 のインストールメディアの [supportadprepadprep.exe] を実行しようとしても有効な Win32 アプリケーションではありませんというエラーになり実行することができませんでした。
image
そのため、追加するサーバーをドメインに参加させ、ドメイン参加後に Windows Server 2012 にドメインの Administrator でログインをして実行することにしました。
バージョンごとのadprep の格納場所は以下のようになっています。

  • 2003 : インストールメディアの [i386] ディレクトリ
  • 2003 R2 : 2003 R2 のインストールメディアの 2 枚目の [cmpnentsr2adprep] ディレクトリ
  • 2008 : 2008 のインストールメディアの [sourcesadprep] ディレクトリ
  • 2008 R2 : 2008 R2 のインストールメディアの [sourcesadprep] ディレクトリ
    # x86 環境で実行する場合は adprep32 を使用
  • 2012 : 2012 のインストールメディアの [sourcesadprep] ディレクトリ
  • 2012 R2 : 2012 R2 のインストールメディアの [sourcesadprep] ディレクトリ

なお、2012 / 2012 R2 についてはドメインコントローラー昇格時に adprep が統合されているようですので、事前に実行する必要がなければ、明示的に adprep を実行しなくても拡張がされます。
 
フォレストの準備
最初にフォレストの準備 (スキーマ拡張)? をする必要があるのですが、フォレストの拡張をする際には既存の DC の OS のバージョンに気を付ける必要があります。
スキーマ拡張をする際には、フォレスト内の DC が WIndows Server 2003 以降を実行している必要があります。
そのため 作業を計画する前にフォレスト内の全 DC の OS のバージョンの確認をし、DC の導入に影響が出ないことを確認しておく必要があります。
image
Windows Server 2008 R2 の DC 追加であれば 2000 の DC が存在していても大丈夫だったと思いますが、2012 では 2000 ドメインがサポートされなくなっているので注意が必要です。
追加のドメイン コントローラーをインストールする
フォレスト内の DC が Windows Server 2003 以降を使用していることが確認できたら インストールメディアの [supportadprepadprep.exe] をコマンドプロンプトから実行します。
最初はフォレストの準備ですので [adprep /forestprep] を実行します。
フォレストの準備が終了したら 2008 で追加された RODC 用の準備を行います。こちらのコマンドは [adprep /rodcprep] となります。

なお、フォレストの機能レベルですが、DC を追加するタイミングで [2003 以上] に設定をしておく必要があります。 そのため、DC を追加する前までに、[Active Directory ドメインと信頼関係] からフォレストの機能レベルを [Windows Server 2003] 以上に設定しておきます。
image
image
現在のスキーマのバージョンについては How to determine the current Active Directory or Exchange Server schema version に記載されている情報から取得できますので、こちらを確認しておくとよいかと思います。
 
ドメインの準備
続いてドメインの準備を行います。
ドメインの準備をする際の注意点としてはドメインの機能レベルがあります。
ドメインの準備をする際には、ドメインの機能レベルが [ネイティブモード] の必要があります。
image
Windows Server 2003 R2 のドメインを新規に構築した場合、ドメインの機能レベルは [2000 混合] になっていると思いますので Active Directory ユーザーとコンピューターから [Windows 2000 ネイティブ] 以上に変更する必要があります。
image
ドメインの機能レベルの要件を満たせたら [adprep /domainprep /gpprep] を実行して、ドメインの準備を行います。
以上で DC を追加する前の準備は完了です。
なお、Windows Server 2012 以降は adprep が AD DS サービスに統合されているようですので、個別に実行しなくても問題はなさそうです。
# スキーマ拡張等がこのプロセスの中で実施されます。
Windows Server 2012 と Adprep の考察
image
 
フォレストとドメインの準備については以下を適宜実行することになるかと思います。

  • adprep /forestprep
  • adprep /domainprep
  • adprep /domainprep /gpprep
  • adprep /rodcprep

?

■AD 移行時に覚えておくとよいコマンド


AD 移行時にはいくつか覚えておくとよいコマンドがありますのでその紹介を。
AD のテストは dcdiag で実施することができます。
ドメイン / ドメインコントローラーの正常性確認をする場合にはこのコマンドを利用すると切り分けのための有益な情報が取得できます。
また、ドメインコントローラー間の複製は repadmin コマンドでコマンドから実施することが可能です。
私がよく使うコマンドとしては以下のものでしょうか。

REM レプリケーションの状態を取得 repadmin /showrepl repadmin /replsum REM 全サイトの DC に対して、複製をプル要求 repadmin /syncall Aed REM 全サイトの DC に対して、複製をプッシュ repadmin /syncall AedP

ほかには名前解決も重要になってきますので [ipconfig /displaydns][ipconfig /flushdns][nbtstat ?c] は適宜実行するようにしておくとよいかと。
NETBIOSによる名前解決はそれほど影響しないかもしれませんが、AD ではDNS レベルでの名前解決は複製でも使用されますので、名前解決ができることが重要です。
 

■サポートされるドメインの機能レベルとフォレストの機能レベル


各 OS でサポートされるドメインの機能レベルとフォレストの機能レベルは以下のようになっています。

ドメインの機能レベル フォレストの機能レベル
Windows 2000 Server Windows 2000 混在
Windows 2000 ネイティブ
Windows 2000
Windwos Server 2003 Windows 2000 混在モード
Windows 2003

Windows 2000
Windows Server 2003
Windows Server 2003 R2 Windows 2000 混在モード
Windows 2000 ネイティブ
Windows Server 2003
Windows 2000
Windows Server 2003
Windows Server 2008 ※1 Windows 2000 ネイティブ
Windows Server 2003
Windows Server 2008
Windows 2000
Windows Server 2003
Windows Server 2008
Windows Server 2008 R2 ※1 Windows 2000 ネイティブ
Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows 2000 ネイティブ
Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012 ※2 Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2 ※3 Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2


※1 : ドメインの機能レベルとして Windows 2000 ネイティブ以上が必要
※2 : フォレストの機能レベルとして Windows 2003 以上が必要
※3 : 機能レベルとしては 2008 以降しか選択できないが、2003 の環境に追加可能
2008 R2 までですが、各機能レベルで追加される機能は Understanding Active Directory Domain Services (AD DS) Functional Levels / 各機能レベルで有効になる機能に関する付録 に記載されています。
なお、Windows Server 2008 R2 以降は特定の条件を守れている場合はフォレストの機能レベルとドメインの機能レベルを下げることができます。
# フォレストの機能レベルを 2008 R2 から 2008 に下げる場合はごみ箱機能が無効になっている必要があります。
ドメインの機能レベルを上げる
フォレストの機能レベルを上げる
2003 に戻すことはできませんが、最新のレベルまで上げた場合に戻したい場合などは 2008 R2 までであれば、障壁は少なく下げることができるかと思います。
ロールバックについては?拡張したスキーマと昇格した機能レベルのロールバック?が参考になります。
機能レベルを下げることが求められるケースとしては ADMT を使用する場合が考えられるかもしれません。
2013/9 時点では、Windows Server 2012 に対応した ADMT がリリースされていないため、ADMT を使用する場合には 2008 R2 のドメインコントローラーを用意する必要があるようです。
2012 まで上げきってしまった環境で ADMT を実行したい場合には機能レベルを下げる必要が、出てくるかもしれないですね。
Windows Server 2012 で、ADMT 3.2 と PES 3.1 のインストール エラー
2015/7/13 追記
Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains で Windows Server 2012 / 2012 R2 で、 ADMT 3.2 がサポートされていることが記載されています。
# 2015/7/13 時点では、日本語版のものは 2008 R2 になっていたので、英語版から確認できます。
詳細については ADMT 3.2はWindows Server 2012/2012R2に対応していました(追記あります)? で解説をされていますので、こちらが参考になります。
 

■Windows Server 2012 の DC 追加?


Windows Server 2008 R2 までは DCPROMO を使用して DC 化を行っていましたが Windows Server 2012 以降では DCPROMO を使用することができません。
# コマンドプロンプトからは実行できるようですが。
image
AD 化はサーバーマネージャーから実行する必要があります。
サーバーマネージャーの [役割と機能の追加] から [Active Directory ドメイン サービス] を追加します。
image
image
役割の追加が終わったら DC に昇格させる必要があります。
Windows Server 2012 では、役割を追加した後にタスクから昇格を行います。
image
既にドメインのある環境ですので [既存のドメインにドメイン コントローラーを追加する] で導入を行います。
image
あとは以前のバージョンの Windows Server の DC の追加と同様に作業を進めていきます。
imageimageimageimageimageimageimage
以上で DC の追加は完了です。
 

■FSMO の移行


今回は入れ替えを目的にしていますので、最終的には Windows Server 2003 の DC を撤去する必要があります。
そのため 2003 の DC が担当している FSMO (操作マスター) をすべて 2012? に移動させます。
RID / PDF / インフラストラクチャ の役割に関しては [Active Directory ユーザーとコンピューター] から転送を行います。
image
ドメイン名前付けマスターに関しては [Active Directory ドメインと信頼関係] から転送を行います。
image
スキーママスターに関しては MMC から転送を行うのですが、デフォルトでは [Active Directory スキーマ] のスナップインが追加されていませんのでコマンドプロンプトから [regsvr32 schmmgmt.dll] を実行して、スナップインを追加し、mmc.exe のスナップインの追加と削除からスナップインを追加します。
image
スナップインを追加したら [Active Directory ドメイン コントローラーの変更] からスキーママスターを転送するドメインコントローラーに選択し、操作マスターから転送を行います。
image
FSMO はこの 5 種類になりますので以上で転送は完了です。
FSMO の確認はコマンドからもできますので転送が終わった後は一覧で確認をしてもよいかもしれないですね。

ntdsutil roles connections connect to server localhost quit select operation target list roles for connected server

 
image
PowerShell でも確認をすることができます。

Get-ADDomain | Select-Object InfrastructureMaster,PDCEmulator,RIDMaster Get-ADForest | Select-Object DomainNamingMaster,SchemaMaster

image
 

■グローバルカタログサーバーの設定


Active Directory サイトとサービスから 2012 の DC が グローバルカタログサーバー (GC) になっていることを確認します。
image
Windows 2003 R2 までは、新規に追加したサーバーは GC になっていませんでしたが、2008 以降は追加したサーバーは自動的に GC に設定されていたかと思いますが、DC を降格させても必ずドメイン内に GC が一台は存在している状態にします。
 

■DNS の設定


2012 の DC が DNS の役割を持っていることを確認します。
image
ゾーンの情報については AD 統合のゾーンとして設定をしていれば複製によって追加した DC に同期がされるのですが、DNS のサーバーのプロパティの設定や条件付きフォワーダーの設定は複製されないので注意が必要です。
フォワーダーの設定は dnscmd でコマンドで設定できますので使用している場合はコマンドで用意しておくとよいかと思います。
 

■クライアントが参照している DNS の変更


AD を使用している場合、クライアントが AD に参加しているのが通常の環境かと思います。
ここで注意が必要になってくるのが、クライアント (またはドメインに参加しているサーバー) が参照している DNS になります。
AD に参加してくる端末は DNS で AD が解決できる必要があります。
クライアントは AD 以外の DNS を参照して、その DNS で AD のドメインのゾーンをフォワーダーやゾーン転送で解決している場合には、その DNS を変更する必要があります。
DHCP で DNS を設定している場合は、DHCP で割り当てている DNS を新規に構築した DC の IP に変更することで対応ができます。
クライアントが AD の DNS を固定で参照している場合は、クライアントの設定を変更して DNS の参照先を変えるということもできますが、台数が多いとこの方法を使うのは厳しいことがあると思います。
スタートアップスクリプトで netsh コマンドを使って DNS を変更することもできますがインタフェース名の指定がネックになることがたまにあるのですよね。
# 管理者権限がなく、ネットワークの設定をユーザーが変えられないという可能性もあるかと。
既存の DNS に関する設定を変更せずに、新しく構築した AD の DNS を使うようにする場合には、

  1. 現行の AD DNS の IP アドレスを変更
  2. 現行の AD? DNS で NetLogon サービスを再起動
  3. 現行の AD DNS で使用していた IP アドレスを新規に導入した DC の追加の IP として割り当てimage
  4. 新規に導入した AD DNS で NetLogon サービスを再起動

これで IP の付け替えが完了します。
# NetLogon サービスを再起動して AD のレコードして必要となる DNS の情報を変更 / 追加した IP で登録しています。
DNS に登録されるレコードについては [C:WindowsSystem32config] の [netlogon.dns] に記述されていますので、どのようなレコードが登録されるかはここを確認するとよいかと思います。
今回は追加の IP で試していますが、一つの IP のみの利用で付け替えるというパターンもできるかと。
 
DNS をすべての IP アドレスではなく特定の IP に限定してリッスンしている場合は使用する IP アドレスの追加が必要となります。
# リッスンのアドレスを設定した後にクライアントから nslookup? でレコードが引けない場合は DNS のサービスを再起動してみてもよいかもしれません。
インターフェイスに設定している IP アドレスが該当サーバーの IP アドレスとして DNS に登録されますので、不要になった場合は、外すようにしておく必要があります。
# この辺は DC で裏 LAN を設定する際、外す必要があることを覚えておく必要があります。
image
これで、クライアントが使用する DNS の IP は変えずに新しく導入した DC で以前と同じ IP アドレスを使用して DNS のサービスを提供することができます。
 

■旧ドメインコントローラーの撤去


ここまで完了したら 2003 DC を撤去します。
旧ドメインコントローラーに AD 以外の機能が入っている場合は

  • AD の機能を削除しても問題ないのでまずは降格する
  • AD 以外の機能を他のサーバーに移行してから降格する

ということが考えられますがこれは作業のポリシーによるかと。
撤去の準備が完了したら DCPROMO を 2003 の DC で実行して AD を降格します。
# 今回使っていた検証環境だと NETLOGON サービスの停止でタイムアウトが発生してしまったので、エラー後に再度降格を行う必要がありましたが。
image
image
以上でドメインコントローラーの入れ替えは完了です。
このほかの作業としては、

などがあると思いますので必要に応じてこれらを実施します。
GPO にセントラルストアを使用している場合、セントラルストアに最新の OS のポリシーテンプレートをコピーするのを忘れないようにしておくとよいかと。
セントラルストア化した場合、セントラルストアに格納されているポリシーテンプレートが使用されますので、最新の OS に対応したテンプレートとなっていない可能性がありますので。
ほかにも実はこれもやっておいたほうが良いという作業があるかもしれませんが、基本的な作業はこのような内容なのかなと思って少しまとめてみました。
DFS の参照順については DFS 紹介一覧の先頭にログオン サーバーを置くことを可能にする、Windows Server の更新プログラム の PreferLogonDC や Windows 分散ファイル システム名前空間のアクセス エラーのトラブルシューティング方法 の dfsutil も用語として覚えておくとよいかと思います。
 

■ドメインコントローラーと NTP


ドメインに参加しているサーバー / クライアント環境は基本的に、PDC エミュレーターと時刻同期が行われるように設定がされています。
Windows タイム サービスを構成する
そこで考慮する内容としては、

  • PDC エミュレーターの時刻同期先
  • 個別に時刻同期を設定する環境が必要かどうか

があるかと思います。
PDC エミュレーターがドメインと時刻同期を実施するような設定となっている場合の起点となりますので、PDC エミュレーターの移行を行う場合には、NTP の設定も意識する必要が出てきます。
よくある設定としては、

  • デフォルトゲートウェイが NTP と時刻同期をしているため、デフォルトゲートウェイと同期
  • PDC エミュレーターで直接外部の NTP サーバーと同期

というパターンでしょうか。
外部の NTP サーバーとしては NICT の公開 NTP サーバー が使われることがあるかもしれないですね。
設定の方法については、ドメインの時刻をNICTのNTPと同期させる で情報を公開されている方がいらっしゃいますので、そちらを参考にされるとよろしいかと。
時刻同期先の設定が「NT5DS」になっている場合は、ドメインコントローラーとの時刻同期が行われますが、個別に時刻同期を設定しておきたい環境がある場合は上記の設定を、個別に設定したい環境に実施しておき、時刻同期を設定する必要が出てくるかと。
また、仮想環境上でドメインコントローラーを動作させている場合などは、Hyper-V ホストと時刻同期が行われないように、時刻同期設定を切っておくことも検討する必要があるかと。
# Hyper-V 上で稼働しているドメインコントローラー以外についても必要に応じで Hyper-V ホストとの時刻同期の必要性は検討する必要があるかと。
 

■ドメインコントローラーを仮想環境上で実行


ドメインコントローラーを仮想環境上で実行することはサポートされているので、移行先が Hyper-V 等の仮想環境であるケースもあるかと。
以下の情報には一通り目を通しておくとよいかと思います。
Hyper-V でのドメイン コントローラーの実行
仮想化ドメイン コントローラーの計画に関する考慮事項
世界のブログから – 「ドメイン コントローラーどうしよう」
世界のブログから – Hyper-Vとドメイン コントローラーに関してもう一つ
仮想ホスト環境で Active Directory ドメイン コントローラをホストする場合の考慮事項
Windows Server 2012 以降は、ドメインコントローラーの仮想化対応がいくつかされています。
# ドメインコントローラーの複製やスナップショットが戻された場合の対応等
これについては、Windows Server 2012 Active Directory 仮想化の対応状況について がまとまっているかと。
ドメインに参加させていている仮想環境の時刻ホスト上で、ドメインコントローラーが動作している場合、

  • 仮想化ホストが起動
  • ドメインコントローラーが起動

の順になるため、ドメインに参加している仮想化ホストが起動したタイミングで認証が行えるドメインコントローラーが存在しない状態となります。
そのため、最初に起動した仮想化ホストのイベントビューアーで、ドメインコントローラーとの通信ができないことによるエラーが発生する可能性があります。
検証環境等では、許容できるかもしれませんが、本番環境でこれが許容されるかは考慮をした方がよいかと思います。
# 検討した結果、許容できるのであれば、それでも良いかと。
このような、仮想化ホストが起動したタイミングで認証できるドメインコントローラーの対応として、

  • 物理コンピューターにインストールされた、ドメインコントローラーを準備
  • 仮想化ホストをドメインコントローラーに参加させない

というようなことが必要なってくるかと。
昨今は、Azure や AWS のようなパブリッククラウド上にドメインコントローラーを構築して、パブリッククラウドと VPN 接続をすることで、認証を行わせるケースもあるかと思います。
このようなケースでは、仮想環境を実行するための仮想化ホストをドメインに参加させるという概念がそもそもありませんので、仮想化ホストと仮想マシンの起動順序による卵と鶏の関係はなくなるのかなと。
パブリッククラウドでドメインコントローラーを動作させた場合、基本的に仮想マシンが動作している仮想化ホストの障害による停止は最小に抑えられるかと思いますが、冗長構成が不要ということではありませんので、

  • 異なる仮想化ホスト上で実行されたドメインコントローラーによる冗長化
    (Azure であれば可用性セットに 2 つの仮想マシンを入れるというような対応)

は必ず検討する必要があります。
ドメインコントローラーのバックアップですが、

  • 稼働しているドメインコントローラーがすべては起動不可になる
  • AD のオブジェクトを間違えて削除してしまった場合

に使用することになるかと思いますが、前者の発生する可能性は、パブリッククラウド上で発生することは、実際問題としては少ないかもしれないですね。
後者については、オペレーションミスですので発生する可能性があります。
これについては、Active Directory のごみ箱機能 を使うことで、バックアップを使用しなくても、カバーできるかを検討することで回避できるケースもあるかと。

Share

Written by Masayuki.Ozawa

6月 8th, 2012 at 8:42 am

Posted in Active Directory

Tagged with

11 Responses to 'ドメインコントローラーの入れ替えに伴う基本的な作業について'

Subscribe to comments with RSS or TrackBack to 'ドメインコントローラーの入れ替えに伴う基本的な作業について'.

  1. 相変わらず、非常に分かりやすい説明でした。キモになる作業を押さえているのが、Ozawa さんですねぇ

    Maebashi

    22 6月 12 at 18:14

  2. ども、おひしさしぶりです!!
    この辺は都度しらべるのが面倒なので軽くではありますがまとめてみました~。

    Masayuki.Ozawa

    22 6月 12 at 22:05

  3. はじめてのコメントで失礼します。
    この方法でドメインコントローラーの入替えをしようと思っていますが、休日に入替作業完了し、ホスト名とIPアドレスも旧のものに変えて、休み明けから何事もなかったように運用を再開したいのですが、そんなことって、できますでしょうか。
    環境は上記の記事と少し違います。
    旧DC:Win2003SP2の32bit、(同じOSのセカンダリも一応あり)、新DC:Win2012スタンダード64bitです。
    旧DC1→旧DC2 FSMO転送など→旧DC2→新DCではなく、すっ飛ばして旧DC1→新DCと、旧を切り離ししたいものです。
    勝手なお願いで恐縮ですが、よろしくご教示ください。

    FURUMITSU

    16 5月 13 at 17:29

  4. FSMOを保持している状態でドメインコントローラーの名称を変更するとドメインコントローラーが機能しなくなる可能性があります。
    コンピューター名を変更する場合にはFSMOを持っていない状態で変更をするような手順を確立する必要があるかと。
    # FSMO を持っているドメインコントローラーのコンピューター名変更で検索をするとかなりの数の情報が出てくると思います。
    以下は MS の技術情報になりますのでこちらをご参考に移行計画を立ててみてはいかがでしょう。
    [HOWTO] Windows 2003 のドメイン コントローラの名前を変更する方法
    ドメイン コントローラ名を変更する
    Renaming a Domain Controller

    Masayuki.Ozawa

    16 5月 13 at 22:10

  5. ご丁寧に、回答していただき感謝します。
    手順を飛ばさず、2段階で移行するように計画します。
    ありがとうございました。

    FURUMITSU

    19 5月 13 at 08:58

  6. 初めてのコメント失礼します。
    Win2003 からwin2012への移行を検討していたところなので、
    とてもわかりやすく参考になりました!
    ところで、Win2012にFSMOを移行したあと、Win2003を降格せず、セカンダリとしてそのまま
    残しておくことで冗長化できないかと検討しているのですが、win2012と2003の共存は問題
    ありそうでしょうか。
    (プライマリが死んだ場合に、セカンダリの2003がほぼ役に立たない等)

    kazu

    21 5月 13 at 20:32

  7. ドメインの機能レベルが変更できないので新しい機能が使用できない、グループポリシーのテンプレート管理やグループボリシーの設定が2003だけで稼働した場合にどうなるかは考慮されたほうがよろしいかもしれないかと思います。
    グループポリシーの管理については2012対応のRSATがインストールされた環境を別途用意すれば良いのかもしれませんが。

    Masayuki.Ozawa

    21 5月 13 at 23:33

  8. 早速の回答誠にありがとうございました!
    そうですよね、、ドメインの機能レベルがあげられませんよね。。
    プライマリ故障時のログオン接続不可の為にしか使えないというか、、それもキャッシュ回数変更で対応できるので、
    結局は足を引っ張るwin2003は降格し、win2012の1台での構成も考えます。
    ありがとうございました!

    kazu

    22 5月 13 at 01:49

  9. 初めてのコメント失礼します。
    正に同じシナリオでの移行を検討しており
    非常に参考にさせて頂いています。
    勝手なお願いで恐縮ですが、何点かご教示頂けませんでしょうか。
    1.「クライアントが参照している DNS の変更」の作業前までは
    クライアントは旧DCで通常運用は可能なのでしょうか?
    諸事情によりリスクがあるとは思いますが、通常業務時間中に
    移行作業を考えています。
    2.上記手順の途中でトラブルが発生した場合、旧DCでの
    運用に戻すにあたって必要な作業はありますでしょうか?
    いろいろなサイトを見ましたが、上記が解決できず
    作業に取り掛かれないでいます。
    参考になりそうなサイト等がありましたらご教示頂けると
    助かります。

    sekigu

    6 7月 15 at 20:02

  10. >1.「クライアントが参照している DNS の変更」の作業前までは
    > クライアントは旧DCで通常運用は可能なのでしょうか?
    ここまでは可能かと考えています。
    旧 DC での運用をされるのであれば、サイトの設定で、旧 DC のみが含まれるサイトを作成して、IP アドレスを適切に割り当てるというような対応を検討する必要があるかもしれませんが。
    >2.上記手順の途中でトラブルが発生した場合、旧DCでの
    >運用に戻すにあたって必要な作業はありますでしょうか?
    基本的には DC の降格で新規に追加した DC を削除することになるかと思います。
    FSMO を新規追加した DC に移していないのであれば、追加した DC の降格については問題は無いかと。
    変更された AD のスキーマは戻すことができませんので、AD のスキーマ変更に伴う不具合の場合には、作業を実施する前に取得していた AD 環境のリストアを考慮する必要が出てくるかと思います。

    masayuki.ozawa

    6 7月 15 at 21:44

  11. 早速のご回答ありがとうございます。
    1.については移行作業中(2、3日間程)、クライアント側に
    支障がでないかを懸念してのことでしたが、問題なさそうという
    ことで、全くリスクはないというわけではないとは思いますが
    予定通り通常業務中に、そこまでの作業を実施してみようと
    思います。
    2.については、やはり作業のタイミングによっては簡単には
    戻すことはできなさそうですね。
    頂いたアドバイスを基に慎重かつ、トラブル発生を想定して
    移行作業をしようと思います。
    ありがとうございました。

    sekigu

    7 7月 15 at 11:04

Leave a Reply