如何在多域林中恢复活动目录根域-市域治理工作总结

我最近处理过一个需要对整个林根域进行恢复的情况。结构本身是相对比较简单的，包含两个域，一个空的林根以及一个包括所有用户、计算机等的子域。其中也只有大约4000个用户。

但存在两个（几乎是致命的）问题。首先，该组织在根域中仅仅建立了一个域控制器。第二，更不幸的是，那个域控制器已经有超过10个月没有进行备份了。尽管根域控制器是一个RAID-5的磁盘配置，在同一天内，灾难发生了而且驱动器里面有两个挂掉了。

这种类型的配置可能是承袭了微软在Windows 2000的早期所信奉的一种***做法。当时的建议是创建一个空的根域，这样在子域名字被更改时，可以对其进行添加或者移除（不能在一个域被定义后再对其进行改名）。

这种方法没有得到延续，但是，因为多个域林会有其它的复杂性：在一个交叉域组中恢复组和用户之间的后端链接，在全局目录服务器只读上下文中存在的延迟对象，以及其它的相关问题。为了避免这些问题，一些组织不得不把多域结构拆为单域。

在这个例子中，两个域分别为Corp.com和EMEA.Corp.com，其中Corp-DC1是根域中的域控制器，而EMEA-DC1和EMEA-DC2为子域中的域控制器。

请注意，所有的客户——包括用户、工作站以及服务器——没有被这个问题所影响，这使得我们有时间去指定并颁布一个处理计划。

挑战

这种情况下有若干问题和挑战，包括：

我还没有见过林根域需要被恢复的例子，并且我也找不到谁见过
恢复10个月以前的备份会在工作良好的子域控制器的林中引入延迟对象
当恢复1月份的备份时，在根域控制器中修改系统时间的话会遇到什么问题？
是否需要对Corp.com和EMEA.corp.com两个域之间的信任关系进行修复？同样地，是否需要重置安全隧道密码？
是否有必要使用一个授权的备份？
当还原Corp.com 1月份的备份时，会遇到什么样的复制问题？

尽管如此，在这次灾难中也有一些正面的因素：

在根域中没有用户或者工作站——仅仅包括管理账户和域控制器。因此，当还原10个月以前的备份时，延迟对象的危害很小。
没有对根域控制器进行过任何修改（比如活动目录对象）（尽管需要关注配置容器的更改）
域名服务器被委托给子域。因此，对于客户而言，EMEA.corp.com是域名独立的，而且在父域中没有资源。

恢复计划

最初的想法是将EMEA域控制器恢复到1月份的备份，还原Corp域的域控制器，前滚子域控制器，然后调整到当前时间。这个20步的处理过程需要停机若干天，并且因为其复杂性和破坏性被驳回了。

我们***采用了下面这种更简单的计划：

还原两个子域控制器的当前备份（以及根域控制器1月份的备份），将三个域控制器变为一个私有网络上的三台计算机。
解决问题，然后重复生产林的步骤。
在Corp.com域中添加第二个域控制器。
备份两个域中的所有域控制器。

整个过程花费了大概3周时间，大部分的时间都用在研究日志、进行还原等等上面。我们对该过程进行了详细的考虑，并有条不紊的对其进行实施，以确保任何事情都能合适地完成。另外，用户不会遇到停机。这意味着，尽管没有根域，林看起来岌岌可危，对于用户认证和我们进行的还原，它都运作良好。我们进行的生产恢复是在不影响用户的情况下，在上班时间里进行的。

恢复过程

恢复过程包括下面的步骤：

1.获取三台计算机，并在私有子网上对其进行配置。

2.在测试计算机上重建EMEA-DC1和EMEA-DC2上当前系统的状态备份。

3.将Corp-DC1 1月份的备份还原到测试计算机。

4.将Corp-DC1的1月份备份上的系统时间设为当前的日期/时间。

5.将墓碑生命期设为365（***）以消除暂时的延迟对象问题。通过ADSIEdit修改cn=Directory Service,cn=WindowsNT,cn=Services,cn=Configuration, dc=pp上的墓碑生命期属性

6.将注册表键严格复制一致性（strict replication consistency）的值设为“1”（严格），以避免复制过程中的延迟对象。

HKEY_LOCAL_MACHINE/System/CurrentControlSet/
Services/NTDS/Parameters
ValueName = Strict Replication Consistency
Data Type = Reg_DWORD 
Value Data =1

7.取消检查Corp-DC1上的全局目录参数。在复制完成后再重新启用。

8.使用HPSReports对域控制器进行体检。逐个检查出现的任何错误，直到所有错误都得到了清理：

Netdom Trust/verfy，以验证Corp和EMEA域之间的信任关系。
```
C:>netdom trust Corp /domain:EMEA.corp.com /verify 
```
The trust between Corp and EMEA.corp.com has been successfully verified.
Repadmin/Replsum /bysrc /bydest /sort:delta，以对林中所有域控制器的复制进行测试。
DCDiag /test:DNS /e /v，以测试林中所有DNS NS的DNS问题。
所有的事件日志。
确保应用程序事件日志显示组策略（the Application event log indicating Group Policy）中的1704（SCECLI）事件都得到应用。同时，检查每个机器的GPResult输出以检查GPO是否正常。
确保您可以通过一个Corp.com账户登录到EMEA域的一个计算机 – 并可以反过来进行 – 以进一步的验证信任关系。
将生产EMEA域中的客户添加到测试EMEA域，并查看是否能被识别。
在每一个域中的域控制器里添加用户和站点，并查看它们是否能复制到所有的域控制器。这对域进行了测试并对NC复制进行了配置。

9.当所有的问题都得到解决后，在生产林中重复这些步骤。

10.在生产根域控制器（Corp-DC1）被还原以后，在那个域中设立第二个域控制器（根域中的第二个域控制器能防止最开始遇到的问题的产生）。

11.对所有的4个域控制器有计划的进行备份。

12.将墓碑生命期属性重置为最小的120到180天。确保严格复制一致性（the strict replication consistency）的值仍为1。

结果

最初，在事件日志中显示了大量的错误和警告，在Repadmin/showrepl报告中也有一些错误。其中很多错误是因为试图修复系统而发生的。在运行一夜之后，大部分的错误都自己得到了修复。我们接下来对剩余的事件进行了处理，直到它们都得到解决。测试和生产环境产生了相似的结果。

1.因为没有启用动态注册，会存在一些DNS问题。结果是我们不得不手动的对一些DNS记录进行配置。

2.在对根域的Corp-DC1域控制器进行最初的还原之后（从旧的备份），可以在目录服务事件日志中找到一个事件分类，包括：

1869 – 在Site-LAN（指的是EMEA-DC1）中发现了GC
1655 – 不能在其中一个站点（指的是EMEA-DC）中找到GC
事件1869和1655是按EMEA和Corp-DC1服务器的顺序记录的
一些1311事件。
一些涉及DNS查找失败的复制不成功

许多1869和1865事件是在查找全局目录时遇到了困难。对所有的这些事件置之不理，复制仍然可以进行，我们可以通过运行Repadmin /replsum /bysrc /bydest /sort:delta来发现这一点：

1865事件

3.通过DCDiag /test:DNS /e /v报告，我们发现DNS按照预期进行工作。

4.存在许多W32时间事件 – 事件ID为29、24和22 – 不需要采取进一步的措施，就会随着时间而消失。

5.在旧的被还原后的Corp-DC1被放到线上之后，最初会有大量的警告和错误事件。12个小时后，它们都自己得到了修复。

总的来说，还原工作进行得相当好，并且相对没有差错。这是在没有停机时间，而且环境风险极小的情况下得到完成的。不必使用授权备份，并且信任关系也不需要被修复。由于我们已经在测试环境中进行了测试，所有我们有信心将这个计划放到生产环境中。尽管如此，这对您只是“这应该可行”的一个假设，直到尝试过您才可能真的对其进行掌握。

【编辑推荐】