本文提供有关在 Active Directory 域服务 (AD DS) 林中徘徊对象的信息。 具体而言,本文讨论了指示存在挥发对象的事件、挥之不去对象的原因以及可用于删除挥发对象的方法。
原始 KB 数: 910205
总结
挥之不去的对象是在删除 AD DS 林后重新出现的对象。 如果域控制器在林中停止复制更改或从林中的其他域控制器复制更改,然后重新开始复制,则可能会发生此行为。 发生此行为的原因是林在多个域控制器之间复制对象删除的方式。
对象删除如何通过林进行复制
删除 AD DS 林中的对象时,AD DS 将生成一个逻辑删除对象来表示已删除的对象。 逻辑删除对象包含已删除对象的属性的一小部分。 域和林中的其他域控制器使用入站复制来接收逻辑删除对象,并更新其林信息以考虑删除。 墓碑对象在指定时间段内保留在森林中,称为墓碑生存期(TSL)。 在 TSL 的末尾,AD DS 永久删除逻辑删除对象。 原始域控制器的所有直接复制合作伙伴和可传递复制伙伴都必须在 TSL 中接收逻辑删除对象的副本。
TSL 的默认值取决于在林中安装的第一个域控制器上运行的操作系统版本。 对于当前所有受支持的 Windows Server 版本,默认 TSL 为 180 天。
注意
将域控制器升级到较新版本的 Windows Server 时,现有 TSL 值不会更改。 现有 TSL 值将一直保留,直到手动更改它。
如何发生徘徊对象
如果域控制器在一段时间内停止复制对剩余复制拓扑的更改或从其余复制拓扑复制,然后重新开始复制(例如,如果服务器必须物理断开连接并移动,然后重新连接)。 当域控制器在超过 TSL 的时间段内复制时,域控制器可能不会收到一个或多个逻辑删除对象。 因此,从所有其他域控制器上的林中删除的一个或多个对象可能会保留在断开连接的域控制器上。 此类对象称为挥之不去的对象。
当断开连接的域控制器再次开始复制时,它充当源复制伙伴,其目标伙伴没有的对象。 目标域控制器通过执行以下操作之一进行响应:
Strict Replication Consistency
如果在目标域控制器上启用了注册表项,该域控制器将识别它无法更新该对象。 目标域控制器本地停止从源域控制器进行目录分区的入站复制。Strict Replication Consistency
如果在目标域控制器上禁用了注册表项,该域控制器将请求该对象的完整副本。 此操作将对象重新引入到林中。 从管理的角度来看,你删除的对象会重新出现。
挥之不去的对象并不总是引起明显的症状。 在以下情况下,挥之不去的对象可能仍然未检测到:
- 管理员、应用程序或服务不会更新挥之不去的对象。
- 管理员、应用程序或服务不会尝试创建域中具有相同名称的对象。
- 管理员、应用程序或服务不会尝试在林中使用同一用户主体名称(UPN)创建对象。
长时间断开连接的原因
避免延迟对象的最简单方法是防止域控制器在超过 TSL 的时间段内与复制拓扑断开连接。 如果域控制器必须长时间断开连接,请注意挂起对象的可能性。
以下条件可能会导致长时间断开连接:
管理员从网络中删除域控制器,然后将其放入存储中。
管理员预先暂存域控制器,然后将其发送到远程位置。 但是,TSL 在域控制器到达远程位置之前过期。
域控制器长时间无法连接到广域网络(WAN)。 例如,如果船在海上,游轮上的域控制器可能无法复制超过 TSL 的时间。
在以下情况下,即使域控制器处于脱机状态(小于默认 TSL)也会显示挥之不去的对象:
管理员缩短 TSL 以强制垃圾回收已删除的对象。
源或目标域控制器上的系统时钟未正确高级或回滚。 在域控制器重启后,时钟倾斜最为常见,原因如下::
系统时钟电池或主板有问题。
计算机的时间源配置不正确。 此类源可能包括使用 Windows 时间服务(W32Time)、第三方时间服务器或使用网络路由器配置的时间源服务器。
管理员推进或回滚系统时钟,以延长系统状态备份的使用寿命,或加速垃圾回收已删除的对象。 确保系统时钟反映实际时间。 此外,请确保事件日志中不包含来自将来或过去的无效事件。
指示林具有挥之不去的对象
即使没有明显的效果,挥之不去的对象的存在也可能会导致问题。 如果挥之不去的对象是安全主体,则最有可能发生这些问题。
指示林可能有挥之不去的对象的事件
事件 ID | 常规说明 |
---|---|
1862 或 1863 | 本地域控制器最近未从多个域控制器(站点间)收到复制信息。 |
1864 | 本地域控制器最近未收到来自多个域控制器的复制信息(摘要)。 |
1,311 | 知识一致性检查器(KCC)无法生成跨树拓扑。 |
20:42 | 自此服务器上次与命名源服务器一起复制以来,它已过长。 |
指示林具有挥之不去对象的事件
事件 ID | 常规说明 |
---|---|
1084 | 服务器上不存在该对象。 |
1388 | 此目标系统收到了应在本地但不存在的对象更新。 |
1,311 | 另一个域控制器复制了此域控制器上不存在的对象。 |
注意
- 记录事件 ID 1988 的域控制器上不存在挥之不去的对象。 源域控制器包含挥之不去的对象。
- 当对一个域控制器复制到另一个域控制器的挥发对象更新时,域控制器的事件日志记录行为取决于包含徘徊对象的目录分区是否可写。 如果目标域控制器上的挥发对象驻留在可写分区中,则域控制器会记录事件。 如果徘徊对象驻留在只读分区中,则无法更新该对象,并且域控制器不会记录事件。
指示林具有挥之不去对象的 Repadmin 错误
事件 ID | 常规说明 |
---|---|
8240 | 服务器上不存在该对象。 |
8,606 | 为创建对象提供的属性不足。 |
林具有挥之不去对象的其他指示
Microsoft Exchange Server 全局地址列表(GAL)包含已删除的用户或组帐户。 在这种情况下,帐户名称会显示在 GAL 中,但当用户尝试发送电子邮件时会发生错误。
对象在林中应是唯一的,但在对象选取器或 GAL 中看到对象的多个副本。 此类情况可能包括已更改名称的重复对象。 这些重复对象混淆目录搜索。 例如,如果搜索无法解析两个对象的相对可分辨名称,冲突解决函数将追加
*CNF:<GUID>
到其中一个名称。 在此示例中,*
表示保留字符,是一个常量,CNF
指示冲突解决,并<GUID>
表示 objectGUID 属性值。用户具有当前帐户,但该帐户已重命名。 用户不会收到电子邮件。 用户对象的两个实例(当前版本和较旧版本)都显示在 GAL 中。 由于两个对象具有相同的电子邮件地址,因此无法传递电子邮件。
不再存在的通用组继续显示在用户的访问令牌中。 因此,用户可能有权访问你打算对该用户不可用的资源。
不能创建新对象或 Exchange 邮箱。 但是,你看不到林中的对象。 错误消息报告对象已存在。
使用现有对象的属性的搜索可能会错误地找到具有相同名称的对象多个副本。 已从域中删除一个对象,但该对象保留在隔离的全局编录服务器中。
从林中删除挥之不去的对象
选择以下方法之一以删除挥之不去的对象。
方法 1:使用 LOLv2
检测和删除挥发对象的首选方法是使用 Lingering Object Liquidator v2 (LoLv2)。 若要下载该工具,请参阅 Lingering Object Liquidator (LoL)
有关如何使用 LoLv2 的详细信息,请参阅以下文章:
方法 2:使用 Repadmin 工具
如果无法使用 LoLv2,可以使用 Repadmin 工具(Repadmin.exe)。 有关详细信息,请参阅 使用 Repadmin 删除挥发对象的步骤。
防止挥之不去的对象
若要防止林中挥之不去的对象,请使用以下方法之一。
方法 1:启用严格复制一致性注册表项
重要
此部分(或称方法或任务)介绍了修改注册表的步骤。 但是,注册表修改不当可能会出现严重问题。 因此,按以下步骤操作时请务必谨慎。 出于防范目的,请在修改之前备份注册表,以便在出现问题时还原注册表。 有关如何备份和还原注册表的详细信息,请参阅:如何备份和还原 Windows 中的注册表。
可以在每个域控制器上启用 Strict Replication Consistency
注册表项,以便可疑对象在源域控制器上隔离。 然后,管理员可以在对象在整个林中传播之前删除这些对象。
如果可写的挥发对象位于环境中,并且尝试更新该对象,则注册表项中的 Strict Replication Consistency
值将确定复制是继续还是停止。 Strict Replication Consistency
注册表项位于以下注册表子项中:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
- 名称:
Strict Replication Consistency
- 数据类型:REG_DWORD
- 值:
- 0 (已禁用)。 目标域控制器从源域控制器请求完整对象。 挥之不去的对象作为新对象重新出现在林中。
- 1 (已启用)。 目标域控制器停止从源域控制器进行相关目录分区的入站复制。
默认值 Strict Replication Consistency
取决于林中第一个域控制器的 Windows 版本。 此计算机创建新林的林根域。
如果林是通过提升运行 Windows Server 2003 或更高版本的服务器创建的,则添加到林的任何域控制器上的默认值
Strict Replication Consistency
为 1 (已启用)。如果林是通过提升运行 Windows 2000 Server 的服务器创建的,则添加到林的任何域控制器上的默认值
Strict Replication Consistency
为 0 (已禁用)。 在这种情况下,请按照“确保新升级的域控制器上启用严格复制一致性”中的步骤操作。
注意
Strict Replication Consistency
如果提升域或林的功能级别,域控制器上的值不会更改。
启用 Strict Replication Consistency
的首选方法是使用 Repadmin。 有关如何执行此操作的详细信息,请参阅以下文章:
方法 2:使用命令行命令检查复制
若要使用 repadmin /showrepl
命令检查复制,请执行以下步骤:
打开命令提示符窗口(选择“开始>运行”,键入 cmd,然后选择“确定”。
在命令提示符处运行以下命令:
repadmin /showrepl * /csv >showrepl.csv
在 Microsoft Excel 中,打开 Showrepl.csv 文件。
选择 A + RPC 列和 SMTP 列,然后选择“编辑>删除”。
选择紧邻列标题下的行,然后选择“Windows>冻结窗格”。
选择整个电子表格,然后选择“数据>筛选器>自动筛选”。
在“ 上次成功 时间”列的标题中,选择向下箭头,然后选择“ 升序排序”。
在 src DC 列的标题中,选择向下箭头,然后选择“自定义”。
在 “自定义自动筛选 ”对话框中,选择 不包含。
在右侧的框中 ,键入 del。
注意
此步骤可防止已删除的域控制器出现在结果中。
在“上次失败”列的标题中,选择向下箭头,然后选择“自定义”。
在 “自定义自动筛选 ”对话框中,选择 不等于。
在右侧的 框中,键入 0。
检查筛选的电子表格是否存在复制失败。 这些是必须解决的问题。
方法 3:删除域控制器
如果必须删除和替换域控制器,或者怀疑域控制器出现故障,请确保域控制器脱机的时间段小于 TSL。
方法 4:增加 TSL
可以使用 Windows PowerShell 或 ADSI 编辑将 TSL 增加到 180 天。
若要使用 PowerShell 增加 TSL,请打开管理 PowerShell 窗口,然后按顺序运行以下命令:
$ADForestconfigurationNamingContext = (Get-ADRootDSE).configurationNamingContext
Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$ADForestconfigurationNamingContext" -Partition $ADForestconfigurationNamingContext -Replace @{tombstonelifetime='180'}
ADSI 编辑在 服务器管理器 的“工具”菜单上可用。 若要更改 TSL,请执行以下步骤:
- 在 ADSI 编辑中,连接到林的配置分区。 要实现这一点,请执行下列操作:
- 在左窗格中,右键单击 ADSI 编辑,然后选择“ 连接”。
- 在 “连接设置”中,选择 已知的命名上下文,然后选择“ 配置”。
- 选择“确定”。
- 在导航树中,转到 CN=Configuration>CN=Services>CN=Windows NT>CN=Directory 服务。
- 右键单击 CN=Directory 服务,然后选择“ 属性”。
- 选择“属性”选项卡。
- 在 “选择要查看 列表的属性”中,选择“ 可选”。
- 在 “选择要查看 的属性”列表中,选择“ TombstoneLifetime”。
- 在 “编辑属性 ”框中,键入 180,选择“ 设置”,然后选择“ 确定”。
为Microsoft 支持部门收集数据
如果需要Microsoft 支持部门方面的帮助,建议按照使用 TSS 收集 Active Directory 复制问题中提到的步骤收集信息来收集信息。