超过墓碑期限的活动目录对象复制的讨论

首先，要向大家道歉的是，我在上一篇《恢复误删除的活动目录对象》文档中，说：“超过活动目录墓碑期限的对象只能从备份中恢复了”这句话。这句话实际上是值得商榷的。

我首先翻查了资料：在微软的网站上，明确说明，如果一个备份超过了墓碑期限，就不是一个好的备份。

在如下一篇KB中：

http://www.microsoft.com/china/technet/archives/windows2000/win2ksrv/technote/adrecov.asp

提到：

“Active Directory 可以通过禁止执行还原操作，来防止其自身还原比逻辑删除存留时间长的数据。因此，备份的可用时限与企业的“逻辑删除存留时间”设置相等。”

 

在以上的文档中，明确说明，一个就是不能用一个超过墓碑期限的备份进行恢复。其原因却语焉不详，我仍旧在思考中，我将我的疑惑讲给一个女同事听，令人震惊的是，她立刻回了邮件，。并罗列了一个方法，说明问题产生的原因：

 

下面是她所罗列的方法：

“祁老师，我觉得这段话比较好理解

Suppose a DC is offline (or doesn't replicate) within the defined tombstone lifetime. During this time, an object on another DC is deleted, then completely removed after the tombstone lifetime. When the offline DC wakes up, it still contains a copy of the deleted object. Because no corresponding tombstone object exists to replicate to the awakened DC, the DC replicates the object out as a new object. This action results in a zombie object, aka a lingering object.

下面是解决这个问题的方法：

1. 首先确认这个DC是否能够联系上GC，使用NSlookup命令来尝试解析GC的SRV记录，具体方法参考：

How to verify that SRV DNS records have been created for a domain controller

http://support.microsoft.com/?id=816587

 

2. 在长时间没有复制的DC上运行net time \\PDC_IP，使DC的时间与PDC同步。

 

3. 在长时间没有开机的DC上运行以下命令：

repadmin /removelingeringobjects ServerName ServerGUID DirectoryPartition /advisory mode

 

注：ServerName为长时间没有开机的DC的DNS名称，ServerGUID为DC的GUID名称，DirectoryPartition为分区名称，类似DC=example,DC=com。

 

确定DC的GUID请运行以下命令

repadmin /showrepl ServerName

 

4. 运行Regedit.exe 编辑注册表，定位到以下位置：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

编辑Strict Replication Consistency，改为1。

 

5. 然后在两台DC上都进行如下操作：

运行regedit，找到HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and Corrupt Partner，将这个键值设置为1。

如果没有，手动新建Allow Replication With Divergent and Corrupt Partner，类型为DW（双字节值）。

 

在做完以上操作后，重启DC，查看DC的复制情况。”

 

这使得我更加专注于这个问题：在前一段的描述又不尽相同。我查了一下如下KB的资料：

http://technet2.microsoft.com/WindowsServer/en/Library/77dbd146-f265-4d64-bdac-605ecbf1035f1033.mspx

 

慢慢的，原因浮现了出来

一．为什么超过墓碑复制期限的DC上线会导致问题。

在AD的复制操作中，有两种复制方法：

       1．Strict Replication Consistency

              该种方法将对象的复制变成两种，newcreate和update。Newcreate复制就是通知自己的复制伙伴，这是一个新建对象，而update复制则是复制已存在对象的变化了的属性。

       2．Loose Replication Consistency

              这种方法是windows 2000 sp3以前所采用的，就是不分上面的不同类型的复制

产生问题的原因：

       当一台DC长期不上线，在其他DC上删除了某个对象，并且该删除对象超过了墓碑期限，被真正删除了。然后，不上线的DC上线了，它如果不修改那个被删除的对象的属性，则永远不会有问题，但如果在这台DC上修改了该对象的属性，就会导致触发update复制更新，但其他的DC根本就没有类似的纪录。于是，问题产生了。

 

二．不同复制方法带来的不同处理方式：

1．  Loose replication consistency的机制：

在目的DC上会产生一个event id为1388的错误，说明在另一个DC上存在滞留不去的对象（lingering object），进行了属性的修改，而本DC没有该对象，将通过完整的复制该对象的方式解决这个冲突.

“ The attribute set included in the update request is not sufficient to create the object. The object will be re-requested with a full attribute set and re-created on this DC.”

 

2．  Strict replication consistency的机制：

在目的DC将产生1988错误，说明这种情况，并且因为是Strict replication consistency机制，所以，它会阻塞掉lingering object的复制企图。

 

 

三．解决lingering object问题的方法

好了，现在问题变成了怎么解决掉这些lingering object了，本质上讲，就是用”repadmin/removelingeringobjects”命令删除这些对象。当然，这个命令是用在windows 2003的环境中的一条命令，必须安装好support tools工具以后。

其操作步骤就是何芸所罗列的方法。

       另外，在上面所罗列的方法中，通过修改注册表的方式强行将复制的方法变为Strict replication consistency，以防止lingering object复制的情况发生。这种方法用在windows server 2003,Windows 2000 sp3和windows 2000 SP4的环境中，如果是Windows 2003 sp1的环境下，可以通过“repadmin /regkey DC_LIST +strict”将域内的DC设置为该种复制机制，特别是如果要设置所有的DC都采用strict replication，可以用“*”来代替DC_list。

 

四．恢复超过墓碑期限的活动目录备份

现在，问题又回到，如果我手头有一份180天前的备份，能不能恢复？

首先，这要明确的是，如果你手头有一个备份，但备份的时间超过了墓碑期限的话，在活动目录恢复的过程中，会出现弹出窗口，提示该备份集有超过时间期限的问题。并且拒绝用该备份恢复活动目录。

 

所以，面临的第一个问题是要将该备份集恢复到DC上去，方法很简单：通过ADSIedit.msc工具，修改墓碑期限的时间，将时间延长，延长到涵盖了那个备份集所备份的时间，则就可以进行恢复了。如下图所示：

 

在恢复以后，这些记录将以什么形式参与到复制中去？是变成lingering object？还是可以通过授权恢复的方法，将其复制到其他服务器上去呢？

我还要定下心来想一想，由试验进一步的验证。今天就到这里吧，就到这里，休息一下。