对于任何活动目录管理员来说，最让其烦恼的，是一些被称为延迟对象的奇怪小东西。从Windows 2000 Server开始，它们就存在，尽管微软一直在努力提供给我们一些好用的工具，以便摆脱延迟对象，并保护我们的域控制器，但它们可能永远不会完全消失掉。

　　虽然已经有了一些描述延迟对象的好文章，我想基于我对它们的经验，针对这个问题提出自己的看法。我发现仍然有许多活动目录管理员，或者不懂什么是延迟对象，或者不知道怎么去处理它们。

　　简单地说，一个延迟对象（lingering object）就是一个已经被删除，并在域控制器还没有在域的墓碑生命期内对变化进行复制时，又被重新加入的任意活动目录对象。

　　换句话说，当一个活动目录对象被删除后，它仍然作为一个墓碑在活动目录中存在着。这种形式的对象只拥有强制属性，并被移到了已删除对象容器中。可以通过Windows Server 2003支持工具中的LDP.exe工具，来查看已删除对象容器中的内容。一旦被墓碑化，一个对象就会在墓碑生命期（默认是60天）终止前，保持这种状态。当生命期到了以后，垃圾收集过程会将其从活动目录中清除。

　　现在假设，您在巴西的远程办公场所有一个全局编录服务器，而该服务器，已经位于60天的墓碑生命期里面，在网络上无法访问了。原因可能是维护、网络中断、硬件故障等等。这些都会使得全局编录无法同其它域控制器进行复制。

　　然后，假设您有多个域林，并且当巴西的域控制器不在网络上时，英国域中有100个用户被删除了。最后，巴西的全局编录重新上线，并进行了复制。但既然它没有复制对已经从活动目录中清除的那100个用户对象的删除操作，该全局编录会认为这些对象需要复制给其它的伙伴。那么现在，其伙伴复制了这些对象，然后那100个账户可能又重新可用了。当然，由于巴西的全局编录只包括一个英国域的只读拷贝，它只复制了这些对象的只读拷贝。

　　在这种情况下，您会看过各种各样的异常现象。您可能已经在几个月前删除了一个叫RBrown的账号，现在另外一个有相同名字的人加入了公司。然后，您试着去创建RBrown这个账号，就会出错说账号已存在。您也可能在活动目录中看到不一致，比如说一个对象的两份拷贝（一个延迟版本和一个重建的版本），或者在用户界面上，根据您在查询哪一个全局编录或域控制器，会看到不同的对象。您甚至会得到冲突的对象，并发现，由于全局地址表(Global Address List GAL)中的不一致，邮件无法得到正常处理。

　　在本文的下半部分中，我们将介绍删除活动目录里延迟对象的方法。