- PR -

Windows2003 追加ドメインコントローラーの昇格のときのコピーメカニズム

1
投稿者投稿内容
きのこ
ぬし
会議室デビュー日: 2004/09/01
投稿数: 256
投稿日時: 2006-02-01 11:27
いつもおせわになっております
最近ＦＳＭＯをもうサーバーをアップグレードしました
ＫＡＺさんには本当にお世話になりました

いよいよ支店のサーバーのハードごと取り替える作業になりましたが
例として
TOKYO-001というメインのアクティブディレクトリがあり
OOSAKA-001という遠隔地でのアクティブディレクトリのハード
ごと取り替えその際、2003をいれるつもりなのですが
計画として

1. OOSAKA-TEMPと名前のＰＣをアクティブディレクトリとして昇格
2. OOSAKA-001を降格してアクティブディレクトリでなくする
3. 変更がTOKYO-001に反映されるまでまつ
4. OOSAKA-001をネットワークから切り離し
5. 新規ハードにWin2003をＰＣ名　OOSAKA-001で立ち上げてネットワークに参加させる
6. 新規OOSAKA-001をアクティブディレクトリに昇格
7. 新規OOSAKA-TEMPを降格

のステップで考えてます。
OOSAKAとTOKYOの間はWANでそれほど太い帯域ではないとして
OOSAKA-TEMPをもたせることで情報をＬＡＮを通じてコピーして
作業の短縮を考えております。
ところであるＰＣをアクティブディレクトリに昇格するとき
はコピーもとに対してなにか決まりがあるのでしょうか？
もし必要であれば上記１，２、６，７で
サーバーたちをＷＡＮのつながったＬＡＮから切断してしまおうとおもってます
（まちがってＷＡＮをまたいで遠隔地にあるサーバーに照会、コピーをするのを
避けるため）

なにかご存知でしたらアドバイスどうかよろしくお願いいたします


ＮＡＯ
ぬし
会議室デビュー日: 2001/10/24
投稿数: 1256
お住まい・勤務地: 神奈川のはずれから東京の下町
投稿日時: 2006-02-01 11:51
まずもう少し詳細な情報を。

ActiveDirectoryは東京と大阪で1つのドメインなんでしょうか？
(要するに1つのドメインで東京と大阪にそれぞれドメインコントローラがある)

今のドメインの環境は？(サーバのOSは？)

ドメインは混在モード？それともWindows2000？(2台ともWindows 2000 Serverだったとして)

そのあたりをまず書いた方が良いと思いますよ。

_________________
Inspired Ambitious
ISMS Assistant Auditor
きのこ
ぬし
会議室デビュー日: 2004/09/01
投稿数: 256
投稿日時: 2006-02-01 12:48
すみません　ＮＡＯさん

構成はシングルフォーレスト、シングルドメインです
アクティブディレクトリはこの二つ以外にも
NAGOYA-001, HIROSHIMA-001, SENDA_001などがWindows 2000 SP4で動いております
OOSAKA-001をふくめすべてのアクティブディレクトリがカタログサーバーとして機能
しております

TOKYO-001はＦＳＭＯで最近、
Windows2003 SP1 に(2000 SP4から）
アップグレードしました、つまり混在モードになりました

現在、テスト環境　下の１、２の作業をして３の段階でまっているとこなのですが
（ＬＡＮでつないでいたので、
下のテンポラリーアクティブディレクトリを
昇格するときと、古いハードにはいったアクティブディレクトリを
降格する部分、ネットワークから切り離しておき、
つないでみましたが、ＴＯＫＹＯ−００１に反映されないでいます）


TOKYO001のところだとTOKYO-001, OOSAKA-001がドメインコントローラー
として登録された情報をもっておりOOSAKA-TEMPがみあたりません
逆にOOSAKA-TEMPでは
ＴＯＫＹＯ−００１とOOSAKA-TEMPがドメインコントローラーとして
登録されております。
つまり変更が還元されていない。
これはやはりネットワークを切断したのがいけなかったのでしょうか？
ＮＡＯ
ぬし
会議室デビュー日: 2001/10/24
投稿数: 1256
お住まい・勤務地: 神奈川のはずれから東京の下町
投稿日時: 2006-02-01 13:13
纏めると。

シングルフォレスト、シングルドメインで全てのDCがGCになっていて、
DCとしてNAGOYA-001, HIROSHIMA-001, SENDA_001, TOKYO-001, OOSAKA-001の5台がある環境で

OOSAKA-001のハードを交換したい為にOOSAKA-TEMPと言う一時的なDCを立てて
OOSAKA-TEMPを一時的な大阪のDCにした後に
OOSAKA-001をリプレースして再度DCとして参加。

って事ですよね？

DCを追加した時に他のDCに変更が反映されるのはデフォルトで5分後です。
ネットワーク構成がどの様になっているか知りませんが、
OOSAKA-TEMPがOOSAKA-001にDCとして追加されたよ。と通知が行くのは5分後です。
さらに他のDCが隣接していればOOSAKA-001から5分後

と言う様に昇格すればすぐ反映されるわけでは無いです。

また、昇格、降格は全てのDCに反映される為
少なくともOOSAKA-001でOOSAKA-TEMPが追加された事を確認出来てないと、他のDCに反映が行き渡りません。

つまりDCの昇格、降格時にはNWに繋がっていないと変更が他のDCに反映されません
それで全てのDCにOOSAKA-TEMPがDCとして追加された変更が反映された後に
OOSAKA-001を降格します。

結論から言うと。
変更が反映される前にNWから切断してしまった為

となります。

昇格、降格はNWに繋いだ状態で行って下さい。

＃一部文章がおかしかった為修正

[ メッセージ編集済み 編集者: ＮＡＯ 編集日時 2006-02-01 13:47 ]
kaz
ぬし
会議室デビュー日: 2003/11/06
投稿数: 5403
投稿日時: 2006-02-01 17:28
こんばんわ．

この場合，混在／native はあまり関係なさそうな気がします．

Domain Controller は TOKYO-001/OOSAKA-001 のほかにもあるのですよね？
であれば，OOSAKA-TEMP は挟まなくてよろしいのでは？
他になければ「Domain Controller が１台だけしかない」状況を作らないために
いろいろと気苦労があるでしょうけど．
その線で考えると，
引用:

きのこさんの書き込み (2006-02-01 11:27) より:

新規 server に Win2k3 を OOSAKA-001 として install して shutdown させておく
OOSAKA-001 を member server に降格する
変更が TOKYO-001 に反映されるまで５分ほど待つ
OOSAKA-001 を Active Directory Domain から削除する
新規 OOSAKA-001 を起動して Active Directory に参加させる
新規 OOSAKA-001 を Domain Controller に昇格させる．

でダメでしょうか？
引用:

（まちがってＷＡＮをまたいで遠隔地にあるサーバーに照会、コピーをするのを
避けるため）

ＮＡＯ様のご指摘にあるとおり，Domain Controller の昇格／降格の処理は
Domain Controller が通信できる状態で実施するのが望ましいです．
失敗を心配されるなら，
全ての Domain Controller を ghost などの imaging tool で backup しておくとか，
そんな力技でしか回避できないのではないかと．
※ちなみに LiveState で３台の Domain Controller を
※「壊れたので reset」な復旧方法で回復させた経験があります．
※その場合，全ての Domain Controller を停止した状態になりますのでアレですが．

以上，ご参考までに．
きのこ
ぬし
会議室デビュー日: 2004/09/01
投稿数: 256
投稿日時: 2006-02-01 23:22
NAOさん、Kazさん
ありがとうございます

新規 server に Win2k3 を OOSAKA-001 として install して shutdown させておく
OOSAKA-001 を member server に降格する
変更が TOKYO-001 に反映されるまで５分ほど待つ
OOSAKA-001 を Active Directory Domain から削除する
新規 OOSAKA-001 を起動して Active Directory に参加させる
新規 OOSAKA-001 を Domain Controller に昇格させる．

でやってみようと思います。
私の無知な心配事ですが
懸念していたのは、変更が TOKYO-001 に反映されるまでの
時間でそういったドメイン昇格、降格の
反映がギガビットでつながっているＬＡＮ間と、
394kb でつながっているＷＡＮとではどのくらい反映する時間に影響するのかが
気がかりでした。

若干、話がちがうのですが
ドメインのWINDOWS2003にアップグレードするときに
adprep /forestprep
をしますが（以下のサイトを参考にしました）
http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/ja-jp/Default.asp?url=/resources/documentation/WindowsServ/2003/standard/proddocs/ja-jp/prepare_for_the_upgrade_of_a_mixed_or_Win2000_domain.asp

そこの１６番にインフラマスターとスキーママスタが
ＬＡＮでつながっているときは１５分、ＷＡＮの場合は半日くらいまちなさい
とあったので気になりました。
ありがとうございました
kaz
ぬし
会議室デビュー日: 2003/11/06
投稿数: 5403
投稿日時: 2006-02-02 00:32
引用:

きのこさんの書き込み (2006-02-01 23:22) より:

懸念していたのは、変更が TOKYO-001 に反映されるまでの
時間でそういったドメイン昇格、降格の
反映がギガビットでつながっているＬＡＮ間と、
394kb でつながっているＷＡＮとではどのくらい反映する時間に影響するのかが
気がかりでした。

あまり関係の無い話ですが，object が複製されるときの通信で流れる
通信の量（大きさ）はどこぞに情報があったと思います．
OU と user account で違うとか，ISDN くらいでも「大丈夫ぢゃない？」
くらいという感覚が頭に残ってます．
が，どうしても気になるなら，remote site は「サイトを構成する」
ことで，複製処理の時間間隔などをある程度制御できますし，
複製 data をたしか 15% ほど圧縮してくれていたと思います．
その辺も加味して設計を見直されてみては？
引用:

そこの１６番にインフラマスターとスキーママスタが
ＬＡＮでつながっているときは１５分、ＷＡＮの場合は半日くらいまちなさい
とあったので気になりました。

15 分は複製の仕組みから算出される時間です．
これもＮＡＯ様のご指摘にありますが，
LAN 環境での Domain Controller 間の複製を通知する時差は約５分ですが，
それが 3 hops までに制限される仕様により，
算出される約 15 分の時差が生じる可能性が生じます．
また，何も変更が行われなくても，６時間ごとに複製相手に
複製を要求する仕様もあったと記憶しています．
この辺のことを指しているのではないかと．

なので，もっとも良いのは旧 OOSAKA-001 の降格／削除から
新 OOSAKA-001 の参加／昇格までは，
６時間の時差を置くと「理屈の上で安全であろう」と考えられます．
※あくまもでもっとも安全な策，という意味です．

以上，ご参考までに．

きのこ
ぬし
会議室デビュー日: 2004/09/01
投稿数: 256
投稿日時: 2006-02-02 09:00
KAZさん

補足説明ありがとうございます。
では６時間余裕を持って作業します
ありがとうございました
1

スキルアップ／キャリアアップ（JOB@IT）