|
|
我最近处理过一个需要. 对整个林根域进行恢复的状况 。构造 自身 是相对比较简单的，包含两个域，一个空的林根以及一个包括一切 用户、计算机等的子域。其中也只有大约4000个用户。
但存在两个（简直 是致命的）问题。首先，该组织在根域中仅仅建立了一个域控制器。第二，更不幸的是，那个域控制器已经有超越 10个月没有进行备份了。虽然 根域控制器是一个RAID-5的磁盘配置，在同一天内，灾难发作 了而且驱动器里面有两个挂掉了。
这品种 型的配置可能是承袭了微软在Windows 2000的早期所信奉的一种最佳做法。当时的建议是创建一个空的根域，这样在子域名字被更改时，可以对其进行添加或者移除（不能在一个域被定义后再对其进行改名）。
这种方法没有得到持续 ，但是，由于 多个域林会有其它的复杂性：在一个交叉域组中恢复组和用户之间的后端链接，在全局目录服务器只读上下文中存在的延迟对象，以及其它的相关问题。为了避免这些问题，一些组织不得不把多域构造 拆为单域。
在这个例子中，两个域分别为Corp.com和EMEA.Corp.com，其中Corp-DC1是根域中的域控制器，而EMEA-DC1和EMEA-DC2为子域中的域控制器。
请注意，一切 的客户——包括用户、工作站以及服务器——没有被这个问题所影响，这使得我们有时间去指定并公布 一个处理方案 。
应战
这种状况 下有若干问题和应战 ，包括：
1.我还没有见过林根域需要. 被恢复的例子，并且我也找不到谁见过
2.恢复10个月以前的备份会在工作良好的子域控制器的林中引入延迟对象
3.当恢复1月份的备份时，在根域控制器中修改系统时间的话会遇到什么问题？
4.是否需要. 对Corp.com和EMEA.corp.com两个域之间的信任关系进行修复？同样地，是否需要. 重置安全隧道密码？
5.是否有必要使用一个受权 的备份？
6.当还原Corp.com 1月份的备份时，会遇到什么样的复制问题？
虽然 如此，在这次灾难中也有一些正面的要素 ：
1.在根域中没有用户或者工作站——仅仅包括管理账户和域控制器。因而 ，当还原10个月以前的备份时，延迟对象的危害很小。
2.没有对根域控制器进行过任何修改（比方 活动目录对象）（虽然 需要. 关注配置容器的更改）
3.域名服务器被拜托 给子域。因而 ，对于客户而言，EMEA.corp.com是域名独立的，而且在父域中没有资源。
恢复方案
最初的想法是将EMEA域控制器恢复到1月份的备份，还原Corp域的域控制器，前滚子域控制器，然后调整到当前时间。这个20步的处理过程需要. 停机若干天，并且由于 其复杂性和毁坏 性被驳回了。
我们最后采用了下面这种更简单的方案 ：
1.还原两个子域控制器的当前备份（以及根域控制器1月份的备份），将三个域控制器变为一个私有网络上的三台计算机。
2.解决问题，然后重复消费 林的步骤。
3.在Corp.com域中添加第二个域控制器。
4.备份两个域中的一切 域控制器。
整个过程破费 了大约 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 =17.取消检查Corp-DC1上的全局目录参数。在复制完成后再重新启用。
8.使用HPSReports对域控制器进行体检。逐一 检查出现的任何错误，直到一切 错误都得到了清理：
1.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.
2.Repadmin/Replsum /bysrc /bydest /sort:delta，以对林中一切 域控制器的复制进行测试。
3.DCDiag /test:DNS /e /v，以测试林中一切 DNS NS的DNS问题。
4.一切 的事情 日志。
5.确保应用程序事情 日志显示组策略（the Application event log indicating Group Policy）中的1704（SCECLI）事情 都得到应用。同时，检查每个机器的GPResult输出以检查GPO是否正常。
6.确保您可以通过一个Corp.com账户登录到EMEA域的一个计算机 – 并可以反过来进行 – 以进一步的验证信任关系。
7.将消费 EMEA域中的客户添加到测试EMEA域，并查看是否能被辨认 。
8.在每一个域中的域控制器里添加用户和站点，并查看它们是否能复制到一切 的域控制器。这对域进行了测试并对NC复制进行了配置。
9.当一切 的问题都得到解决后，在消费 林中重复这些步骤。
10.在消费 根域控制器（Corp-DC1）被还原以后，在那个域中设立第二个域控制器（根域中的第二个域控制器能避免 最开始遇到的问题的产生）。
11.对一切 的4个域控制器有方案 的进行备份。
12.将墓碑生命期属性重置为最小的120到180天。确保严厉 复制一致性（the strict replication consistency）的值仍为1。
结果
最初，在事情 日志中显示了大量的错误和正告 ，在Repadmin/showrepl报告中也有一些错误。其中很多错误是由于 试图修复系统而发作 的。在运行一夜之后，大部分的错误都自己. 得到了修复。我们接下来对剩余的事情 进行了处理，直到它们都得到解决。测试和消费 环境产生了类似 的结果。
1.由于 没有启用动态注册，会存在一些DNS问题。结果是我们不得不手动的对一些DNS记录进行配置。
2.在对根域的Corp-DC1域控制器进行最初的还原之后（从旧的备份），可以在目录服务事情 日志中找到一个事情 分类，包括：
1.1869 – 在Site-LAN（指的是EMEA-DC1）中发现了GC
2.1655 – 不能在其中一个站点（指的是EMEA-DC）中找到GC
3.事情 1869和1655是按EMEA和Corp-DC1服务器的顺序记录的
4.一些1311事情 。
5.一些触及 DNS查找失败的复制不成功
许多1869和1865事情 是在查找全局目录时遇到了艰难 。对一切 的这些事情 置之不理，复制依然 可以进行，我们可以通过运行Repadmin /replsum /bysrc /bydest /sort:delta来发现这一点：
3.通过DCDiag /test:DNS /e /v报告，我们发现DNS依照 预期进行工作。
4.存在许多W32时间事情 – 事情 ID为29、24和22 – 不需要. 采取进一步的措施，就会随着时间而消失。
5.在旧的被还原后的Corp-DC1被放到线上之后，最初会有大量的正告 和错误事情 。12个小时后，它们都自己. 得到了修复。
总的来说，还原工作进行得相当好，并且相对没有过失 。这是在没有停机时间，而且环境风险极小的状况 下得到完成的。不用 使用受权 备份，并且信任关系也不需要. 被修复。由于我们已经在测试环境中进行了测试，一切 我们有自信心 将这个方案 放到消费 环境中。虽然 如此，这对您只是“这应该可行”的一个假定 ，直到尝试过您才可能真的对其进行控制 。
|
|
|
|
|
|
|
|
|
|
