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