Windows Active Directoryスキーマの更新はどれくらい安全ですか？

Active Directoryがスキーマの更新を処理する方法、特に、ADがどれほど重要で、更新が必要な状況の範囲が実際に手順が安全であるかについて、よりよく理解しようとしています。Exchange 2007、OCS、SCOMはすべてスキーマの変更を必要とします。たとえば、Windows 2003からWindows 2008インフラストラクチャへの大きな移行を検討しているときに起こることではありません。

私が探しているのは、実際にうまくいかない場合に備えて、スキーマ変更の最適なバックアウト計画に関するアドバイスです。たとえば、更新中に1つのDCをオフラインにし、それを使用してスキーマの更新が失敗した場合に環境全体をロールバックすることは受け入れられますか？スキーマの更新中にオフラインだったDCの再アクティブ化に問題はありますか？

スキーマの更新は一方向の機能です。ADに追加できるのは新しいスキーマのみで、削除することはできません。このため、ソフトウェアでスキーマの拡張または更新が必要な場合は、代替手段を常に慎重に評価する必要があります。それがあなたが使用することにコミットするものであることを確認してください。

まず、ADデータベースの適切なバックアップコピー（通常は％SystemRoot％\ ntds \ NTDS.DIT​​）があることを確認してください。安全な場所に保管してください。

フォレストにDCが1つしかない場合は、非常に簡単です。指示に従ってadprepを実行します（またはソフトウェアにAD自体を更新させます）。

DCが複数ある場合は、dcdiagとによってエラーが報告されないことを確認してくださいreplmon -syncall。（各DCからの）すべてのADデータベースのバックアップがあることを確認してください。Schema Masterの役割を持つDCを決定します。可能な場合は、そのサーバーですべての更新を実行します。

ADは、ほとんどの場合、失敗したスキーマ更新から自身を保護します。LDIFファイルが構文を渡さない場合（たとえば、更新中にBSODを使用した場合）、ロードされません。各「更新」には、独自のLDIFファイルのセットがあります。

スキーマの更新が（正しく行われている限り）間違っているのを見たことはありません。MSは、これを確かで信頼できるプロセスにするために、すべての停止を実際に引き出したように見えます。私が悪い出来事を見ることができる唯一の実際のシナリオは、途中で電源を失った場合（それでも確信が持てない場合）、または最初からADがすでにねじ込まれている場合（この場合、より大きな問題があります）です。

スキーマのアップグレードで実際に行われるのは、新しいオブジェクトクラスとプロパティ（アプリケーションまたはADの新しいバージョンが使用できる）でADを拡張するだけなので、障害の範囲はかなり制限されます。 このtechnetの記事はまともな概要を提供し、いくつかの潜在的な悪いことが起こるケースをカバーしています。

私の標準的なアプローチは、すべてが事前に（dcdiag、replmonなどを介して）適切に機能していることを確認し、最悪の事態に備えてADの既知の良好なバックアップを確保することです。ADの堅牢性は非常に高いため、その後問題が長期にわたって顕在化しない可能性があるため、このバックアップをできるだけ長く保持します。したがって、標準のバックアップと復元が私のロールバックになります。しかし、私が言ったように、私はそれが事実であることを見たことがない。

1つのDCオフラインアプローチは、小規模な環境で機能します。大規模な環境では、接続されていないDCで更新を実行することをお勧めします。更新プロセスの提供が正常に完了したら、ネットワークに接続して変更を複製します。このシナリオでのバックアウトは、ミラーセットの1つのドライブを引き出し、DCをシャットダウンして、更新前から最新の正常なドライブを再挿入するだけです。

数百または数千のDCがある大規模なネットワークでは、適切なDCアプローチを再挿入することは実用的ではありません。