我试图更好地了解 Active Directory 如何处理架构更新，特别是考虑到 AD 的重要性以及需要更新的情况范围，该过程实际上有多安全。例如，Exchange 2007、OCS、SCOM 都需要架构更改，这不仅仅是在您考虑从（例如）Windows 2003 到 Windows 2008 基础架构的重大转变时发生的事情。
我正在寻找的是有关架构更改的最佳退出计划的建议，以防万一它确实出错了。例如，在更新期间让一个 DC 脱机并在架构更新失败时使用它来回滚整个环境是否可以接受？重新激活在架构更新期间脱机的 DC 是否有任何问题？
模式更新是一种单向功能。您只能向 AD 添加新架构，永远不能删除任何内容。因此，当软件需要模式扩展或更新时，您应该始终仔细评估替代方案；确保这是您愿意承诺使用的东西。
首先，确保您有一个良好的 AD 数据库备份副本（通常是 %SystemRoot%\ntds\NTDS.DIT）！将其保存在安全的地方。
如果您的森林中只有一个 DC，那非常简单。只需按照说明运行 adprep（或让软件更新 AD 本身）。
如果您有多个 DC，请确保绝对没有由
dcdiagand报告的错误replmon -syncall。确保您有每个 AD 数据库的备份（来自每个 DC）。确定具有 Schema Master 角色的 DC。尽可能在该服务器上/对该服务器进行所有更新。在大多数情况下，AD 将保护自己免受架构更新失败的影响。如果 LDIF 文件没有通过语法（比如你在更新过程中出现 BSOD），那么它将不会被加载。每个“更新”都有自己的一组 LDIF 文件。
我从未见过模式更新（只要正确完成）出错。MS 似乎真的竭尽全力使这个过程成为一个坚实可靠的过程，它表明了这一点。我能看到任何不好的事情发生的唯一真实情况是，如果你在中途断电（即使那样我也不确定），或者你的 AD 一开始就被搞砸了（在这种情况下你有更大的问题）。
架构升级真正所做的只是使用新的对象类和属性（应用程序或更新版本的 AD 可以使用）扩展 AD，因此灾难的范围非常有限。 这篇 technet 文章给出了一个不错的概述，并涵盖了一些潜在的 Bad Things Happening 案例。
对我来说，标准方法是事先确保一切正常运行（通过 dcdiag、replmon 等），并确保我有一个已知良好的 AD 备份，以防最坏的情况发生。我会尽可能长时间地保留此备份，因为 AD 非常强大，以至于问题可能在之后很长一段时间内都不会出现。所以标准备份和恢复将是我的回滚。但就像我说的，我从未见过这种情况。
单直流离线方法适用于小型环境。对于大型环境，我更愿意在未连接的 dc 上执行更新。如果更新过程成功完成，然后将其连接到网络并复制更改。在这种情况下，退出就像拉出镜像组中的一个驱动器一样简单，然后关闭直流并重新插入更新前的当前良好驱动器。
在具有数百或数千个 dc 的大型网络上，重新插入良好的 dc 方法是不切实际的。