環境= 8つのDCを備えたWindows2003ネイティブドメイン
2003を実行している古いドメインコントローラー、CA Enterpriseの役割、DHCP、DNS、共有を指すいくつかのGPOスクリプト、およびその他のマイナーな機能)があります。すべてのサーバーそれをプライマリDNSとしてポイントし、この時点(8年以上後)ではドメイン全体でそのIPまたは名前への参照がたくさんあります。これらすべてを手動で変更する気はありません。かなり大規模になります。事業。
このガイドに従いたい: http://msmvps.com/blogs/acefekay/archive/2010/10/09/remove-an-old-dc-and-introduce-a-new-dc-with -the-same-name-and-ip-address.aspx うまくいけば、基本的に「インプレースアップグレード」になります。
ボックスのP2Vを実行することを検討しましたが、正直に言うと、2003年の実行中にそれを維持したくありません。また、CNAMEを使用して2番目のIP(古いもの)を追加することも検討しましたが、接続されたリンクを使用すると、よりクリーンになるように見えました。
私の実際の質問:
リンクが示唆することを行うときの落とし穴や大きな注意の兆候はありますか?誰かがこの道を進んで、どのように進めるかについてアドバイスがありますか?
これは比較的一般的な操作です。エースは優れたADリソースであるため、純粋なDCピース)として彼の言葉を取り入れることは非常に簡単です。
彼は他のサービスに多くの時間を費やしていません。あなたの場合、それは重要です。
発行された証明書のすべての情報を失うことをいとわない場合を除いて、CAを正しく実行するには、現在のDC)をアップグレードする必要があるため、CAは少し苦痛になる可能性があります(cf. http://support.Microsoft.com/kb/298138 )これにCAを使用する内容に応じて、問題がない場合とない場合があります。これは、CA構成を失うことで確実に実行されます。 CAでこれらの操作を実行することはできないため、新しいマシンの名前を変更して昇格するまで、新しいCAを作成しないように注意してください。
DNSデータの移行は、ADが統合されていると仮定すると魔法のように行われます。そうでない場合は、セカンダリとして設定し、プライマリに変更して、古いIPを新しいサーバーに割り当てた後に再構成する必要があります。
DHCPデータの移行は可能であり、指示に従えば悪くはありません(cf. http://support.Microsoft.com/kb/962355 )。エースはリンクされたページでこれをカバーしています。
共有の移行には、データと権限が含まれます。通常はFSMT( http://www.Microsoft.com/en-us/download/details.aspx?displaylang=en&id=10268 )のようなものを使用しますが、永続的なものではありませんサーバー名の変更。したがって、robocopyを使用して、アクセス許可(/ copyall)を含むファイルを新しいサーバーにコピーし、共有定義を(手動または http://support.Microsoft.com/kb/125996 =)。
これについてはArsTechnica( http://arstechnica.com/civis/viewtopic.php?f=17&t=1117166 )にスレッドがあり、「スイングサーバー」の使用を推奨しています。私はSBS移行のケースでそれを行いましたが、既存のDCが非常に多いため、あなたのケースではやり過ぎだと思います。
DNSとDHCPが他のサーバーにも存在するのか、それともこのサーバーだけに存在するのかについては、あなたは言いませんでした。これだけの場合、まず第一に、単一障害点などのために悪いですが、これは、これを実行している間、エンドユーザーに非常に目に見えるダウンタイムを見ていることを意味します。この場合、スイングサーバーが理にかなっています(1つの大きなブリップではなく2つの小さなブリップ)。
素晴らしいもの。見た目はすべて良さそうです。@ MikeBazはCAを指摘するのに適しています。これは、ACEが言及していませんが、DC上にあるのが一般的です。 「オールオアナッシング」の切り替えは、ゆっくりと時間をかけて、各サービスを独自のミニプロジェクトとして新しい場所に移動することです。 DNSは、IPを気にする必要がある唯一のものである可能性があります(サーバーがWINSサーバー上にない場合)。
単一のDC障害がDC、DNS、DHCP、CA、netlogonなどのネットワークサービスに影響を与えることはないという点で、ADDCがフォールトトレラントになるようにネットワークを設計する必要があります。このサーバーを使用することをお勧めします交換は、それらのそれぞれの設計を改善して可用性を高めるチャンスです。良いニュースは、それぞれが最小限の労力で実行できるため、NEXT DC交換がはるかに簡単になることです。
スクリプトの場合、すべてのDC上にある(そしてそれらの間で複製される)netlogonからポイント/実行している場合、スクリプト内のサーバー名は\\ old-dc\netlogonではなく、\\ domainname.com\netlogonをポイントする必要があります。これは、クライアントが最も近いDCからスクリプトとサポートファイルを取得するための推奨される方法です。スクリプト/ GPOで他の共有にファイルを保存する場合は、使いやすく、単一のファイル共有が停止してもファイルアクセスが妨げられないDFS + DFSRの使用を検討してください。
DNSの場合、ネットワーク内にその数のDCがあるため、すべてのクライアントとサーバーを少なくとも2つのDNSサーバーに設定する必要があります。その場合は、1つを削除するDCは移行中に問題になりません。DHCPクライアントの場合は、DHCPスコープを別のDC/DNSホストに変更するだけです。これを今すぐ実行できます。サーバーの場合静的IPを使用すると、 スクリプトを使用 またはjr。adminにタスクを割り当てて、すべてに適切なDNSエントリがあることを手動で確認できます。DNSはADの生命線であり、可能であれば、実際に3+を入力します。 DNSサーバーを変更したり、新しいIPを割り当てたりする必要があるこのような場合のため、サーバーNIC上のDNS全体(2未満になることはありません)。