DNSサーバーでもあるドメインコントローラーを廃止するためのベストプラクティス
DNSサーバーとして頻繁に使用されるActive Directoryドメインコントローラーの廃止プロセスについては、2つの考え方があります。
発信DCのIPアドレスを新しいDCに追加し、DNSがそのアドレスをリッスンしていることを確認します。
古いDCを降格し、DNSの役割はそのままにして、新しいサーバーにグローバルDNSフォワーダーを構成します。
明らかに、すべてのサーバーとデバイスが新しいサーバーのプライマリIPアドレスを使用するように設定されるまで、どちらも一時的なギャップですが、環境のサイズによっては、移行期間が比較的長くなる場合があります。
ここに明確なベストプラクティスがありますか？
これは厳密なQ＆Aの質問というよりは「議論」の質問だと思うので、答えるのをためらっています...しかし、土曜日の朝は怠惰なので、とにかく質問します。
ここに明確なベストプラクティスがありますか？
いいえ（くそー、たぶんこれは簡単な答えでした...）
Microsoftは非常に一般的なを簡単に提供しています Google対応 ドメインコントローラーを降格し、ADおよびDNSの移行を実行する方法に関するわかりやすいガイダンス。ただし、それらにリンクすることも、特定の質問に対処することもしません。Microsoftは、すべての特定のケースを個別に文書化できないためです。組織の環境。
そのため、私たちのようなシステム管理者/エンジニアは、Microsoftが私たちのためだけに特別なスクリプトを作成していない私たち自身の専門知識と経験のギャップを埋める必要があり、それが私たちの価値を高めています。
これと同じ問題に対処するために私たちが行った例を挙げましょう。私はまた、数十以上のドメインコントローラー、同じネットワーク上に共存している異種のADフォレスト、Windows以外のデバイスも消費している世界中にまたがる環境で作業しているためです。同じDCからのDNSサービスなど。新しいデータセンターへの移動と古いデータセンターからの移動、新しいハードウェアまたは新しいOSバージョンへの移行が必要なこと、および単純な古いビジネスポリシーが、ドメインコントローラーを廃止する必要があるすべての理由です。潜在的にまだ使用されていました。そして、現在それらのDC/DNSサーバーを使用している複数の異種組織がある場合、それは通常、プロジェクトマネージャーやチケットを含むドメインコントローラーを廃止する前に、すべてのクライアント（その多くはあなたの制御下にない場合があります）を再構成する厄介で引き抜かれたプロセスです作業に数日または数週間かかる他のさまざまなチームに.
だから、私は誰もあなたに与えることはできないと思いますtheこの質問への答え。あなたがそれについて取り組むことができる千の方法があり、いくつかはあなたの組織の構造とニーズに応じて他のものより良いでしょう。
この問題に対処するために行ったのは、各データセンターにVIPを作成し、そのVIPの背後にあるそのデータセンター内のすべてのドメインコントローラーをプールすることです（これはVIPはDNSサービス用のみですが、明らかな理由により、KerberosとLDAPの負荷分散について話しますnotです。 ）このようにして、クライアントはDNSリゾルバにVIP=を使用するように構成できます。また、VIPしかし、私たちは喜んでいます。
しかし、あなたは問題の前にいるわけではありません...あなたが提供したオプションを考えると：
発信DCのIPアドレスを新しいDCに追加し、DNSがそのアドレスをリッスンしていることを確認します。
古いDCを降格し、DNSの役割はそのままにして、新しいサーバーにグローバルDNSフォワーダーを構成します。
私はオプション＃1を選択します。あなたの目標は古いサーバーをできるだけ早く廃止することであり、オプション＃2は古いサーバーを取り除く助けにはならないからです。オプション＃2では、サーバーの存在が依然として必要です。 Mathias R. Jessenのスタブゾーンの提案にも同意しません。これも、古いサーバーをそのままの状態で稼働させたままにする必要があるため、最終目標につながらないためです。
オプション＃1では、醜いかもしれませんが、古いサーバーを廃止し、会社のコスト削減を主張し、そのデータセンターで別の月の家賃を支払う必要をなくし、そのような優れた従業員であることに対して賞を与えることができます。
編集：チャットについてもう少し考えてみます。自分の要件をあなたに当てはめていたのではないかと思います。現時点では、いくつかの要件について、すぐに利用できる要件があるためです。私の心に新鮮。サーバーをできるだけ早く停止する必要性がすぐにはないようです。
とはいえ、私はそれを好むので、提案を変更するつもりはありません。既存のドメインコントローラーに追加のIPを追加することは、非常によく似たシナリオで過去にうまく機能しており、不確定な時間サーバーがそこに座っている奇妙な痕跡を残さないほうがいいと思います。
Active Directoryの地獄への道は一時的な包帯で舗装されています。廃止または廃止予定のDNSサーバーのIPアドレスを新しいDCおよびDNSサーバーに割り当てることは、一時的な包帯です。
@gravyfaceがコメントで述べたように、理想的なシナリオでは、古いDCを完全に廃止する前に、すべてのDHCPスコープと静的構成を変更して、クライアントのDNS設定を古いIPではなく新しいIPに更新します。 。
すべてのクライアントが時間どおりに再構成されたことを確認することは必ずしも可能ではありませんが、ここではオプション番号2（名前空間全体の転送）を最も不快なオプションとは見なしません。
古いサーバーが降格した後でも要求を転送できるようにすることに加えて、DNSサーバーの受信要求に対してデバッグログを有効にすることをお勧めします。これにより、ifクライアントはまだ古いDNSサーバーを指していますが、そのクライアントを識別しています。
そうは言っても、明白な3番目のオプションを逃したと思います：Stub Zones！
- DCを降格し、DNSの役割を維持して、以前にDCが保持していたすべてのゾーンをスタブゾーンとして追加し、それ以外はすべて転送します。このように、クライアントが実際に作業を行う代わりに、クライアントが実際に使用しているドメインコントローラーにアクセスするように強制する