まず、これはWindows Server2003から2012DC/DNS/ADへの移行です。 2003年のDC/DNS/ADサーバーのバックアップもありますが、現時点では問題ないと思いますが、必要に応じて使用できます。私はすでにいくつかの手間のかかる作業を行い、次のようないくつかのステップバイステップガイドを使用して、新しい2012サーバーをAD/DC/DNSホストとして構成およびセットアップしました(私の知る限り)。
ステップバイステップ:既存のWindows Server2003ネットワークへのWindowsServer 2012ドメインコントローラーの追加
クライアントをオフラインにしてサーバーをテストしましたが、すべてが意図したとおりに機能しているようです。これは驚くほどうまく機能しました。
今トリッキーな部分:
私の同僚と私は、これを可能な限り痛みのないものにするための唾を吐くオプションですが、私たちの誰もこのような移行を実行していません。以下は、これまでで最も実現可能なものです。
長所:簡単そうに聞こえます
CONS:2003で実行されているジョブが欠落している場合は、前後に割り当てられます。クライアント/ドメインの信頼エラーがたくさんある可能性があります。おそらく私が予測できないより多くの問題。
netsh
を使用してクライアントのプライマリDNSを2012DCに変更しますPROS:信頼の問題はないようです。ジョブやファイルなどを見逃した場合に備えて、両方のサーバーが稼働している可能性があります。
CONS:スクリプトは複雑で、MOSTクライアントではないにしても一部を見逃す可能性があります。
私は、ベストプラクティスに少し近く、リスクが少し少ないものを望んでいます。
可能な限り苦痛を伴わずにこれを達成する方法についての追加のアイデアを事前に感謝します。
個人的にはオプション1を使用しますが、いくつかのステップがあります。新しい2012サーバーはすでに構成されており、AD/DNSサーバーとして正しく機能していることをすでに確認しているので、その側面は正常に機能しています。
(1)まず最初にFSMOの役割を転送新しいサーバーに転送し、しばらく待ってから問題が発生しないようにします。
(2)次に、すべてのネットワーク全体で機能する必要がある/機能する必要がある機能のリストを日常的に作成し、それをテストする方法を検討します。可能であれば、他の部門の人々に何を使用しているかを尋ねることをお勧めします。あなたが発見したい最後のことは、あなたが気づいてさえいない重要なものが実行されていないことです。
(3)時間外に、2003サーバーのIPを2012ボックスに再割り当てし、古い2003ボックスを新しいIPで実行するように設定します。そうすれば、何かが足りないことがわかった場合でも、それらはまだオンラインであり、必要なものにアクセス/チェック/取得することができます。チェックリストに目を通し、すべてが正常に機能していることを確認します。
(4)翌日、問題の準備をし、必要になる可能性のあるすべての人が参加して利用可能であることを確認し、発生した問題を修正する準備をします。起動、給料日、請求日、月曜日、金曜日など、負荷が発生している日に切り替えを行うことは避けてください。うまくいけば何も起こりませんが、最悪の事態を計画し、最良のものを期待する方がはるかに良いです。
(5)最後に、問題なく数日間稼働したら、古いサーバーをシャットダウンしますが、万が一の場合に備えて、しばらくの間使用できるようにしておきます。
私がオプション2を避ける理由は、あなたを捕まえる可能性が高いものそのものが、あなたがスクリプトを書くとは思わないものと同じだからです。また、古い設定では、古いサーバーを指すようにハードコードされたものになるはずです。間違いなく、グループポリシーやスクリプトが変更されないものになるでしょう。
クライアントのDNSエントリを新しい2012DCに変更してみませんか?それらがすべて揃っていると思ったら、2003DCをシャットダウンします。事態が悪化した場合は、問題なく2003DCをオンラインに戻すことができます。または、2003 DCを降格し、他のプロセス/ジョブ/ファイル共有などが正しく移行されることが確実になるまでそのままにしておきます。