所有 DC 均未通过 VerifyEnterpriseReferences 和 DNS RReg 测试 - 其余一切正常,包括复制到全新的 DC

所有 DC 均未通过 VerifyEnterpriseReferences 和 DNS RReg 测试 - 其余一切正常,包括复制到全新的 DC

因此,我们最近向我们的域 (Win 2008 R2 Enterprise) 添加了一个新的 DC,想法是用第二个企业 DC 替换我们的 Win 2008 R2 标准 DC​​ - 这将为我们提供 2008 R2 Enterprise 上的 2 个 DC。

在添加此 DC 的同时,我们还将林和域级别从 2003 提升到了 2008。

据我所知,一切都复制得很好。AD、SYSVOL 或其他任何东西都没有问题。

在降级 2008 R2 标准盒之前,我要确保一切都良好且牢固。

所有 DC 均未通过 VerifyEnterpriseReferences 测试,输出如下:

   Starting test: VerifyEnterpriseReferences
     The following problems were found while verifying various important DN
     references.  Note, that  these problems can be reported because of
     latency in replication.  So follow up to resolve the following
     problems, only if the same problem is reported on all DCs for a given
     domain or if  the problem persists after replication has had
     reasonable time to replicate changes. 
        [1] Problem: Missing Expected Value
         Base Object: CN=DC2008S-0,OU=Domain Controllers,DC=domain,DC=com
         Base Object Description: "DC Account Object"
         Value Object Attribute Name: msDFSR-ComputerReferenceBL
         Value Object Description: "SYSVOL FRS Member Object"
         Recommended Action: See Knowledge Base Article: Q312862

        [2] Problem: Missing Expected Value
         Base Object:
        CN=DC2008E-0,OU=Domain Controllers,DC=domain,DC=com
         Base Object Description: "DC Account Object"
         Value Object Attribute Name: msDFSR-ComputerReferenceBL
         Value Object Description: "SYSVOL FRS Member Object"
         Recommended Action: See Knowledge Base Article: Q312862

        [3] Problem: Missing Expected Value
         Base Object:
        CN=DC2008E-1,OU=Domain Controllers,DC=domain,DC=com
         Base Object Description: "DC Account Object"
         Value Object Attribute Name: msDFSR-ComputerReferenceBL
         Value Object Description: "SYSVOL FRS Member Object"
         Recommended Action: See Knowledge Base Article: Q312862

        LDAP Error 0x20 (32) - No Such Object. 
     ......................... DC2008S-0 failed test VerifyEnterpriseReferences

此外,DNS RReg 测试失败 - 我还没有详细研究过这个问题,但它包含在 dcdiag 报告中,所以我想我现在就把它添加到这里

     Summary of DNS test results:


                                        Auth Basc Forw Del  Dyn  RReg Ext
        _________________________________________________________________
        Domain: domain.com

           DC2008S-0                    PASS PASS PASS PASS PASS FAIL n/a  
           DC2008E-0                    PASS PASS PASS PASS PASS FAIL n/a  
           DC2008E-1                    PASS PASS PASS PASS PASS FAIL n/a  

     Total Time taken to test all the DCs:2 min. 52 sec.

     ......................... domain.com failed test DNS

该错误提示我查看 2003 服务器的知识库文章https://support.microsoft.com/en-us/help/312862/recovering-missing-frs-objects-and-frs-attributes-in-active-directory

我仍然尝试继续关注,只是想看看我能发现什么。

我们所有的 DC 上似乎都填写了 Server-Reference。(ASDIEdit、根域、默认命名上下文、CN=System、CN=File Replication Service、CN=Domain System Volume(SYSVOL 共享)),所有 3 个 DC 都列为 nTFRSMember,并且属性的详​​细信息已在 serverReference 中填写。

它与我提取的内容不完全匹配,但我不能 100% 确定我正在寻找正确的地方:

CN=NTDS Site Settings,CN=SITE_NAME,CN=Sites,CN=Configuration,DC=DOMAIN_NAME,DC=com

CN=NTDS Settings,CN=DC2008S-0,CN=Servers,CN=SITE_NAME,CN=Sites,CN=Configuration,DC=DOMAIN_NAME,DC=com

但是对于所有 3 个 DC,第二个值都是真(具有不同的 DC 名称)。

但是,如果我运行 ntfrsutl ds,我会得到(null)输出:

NTFRS CONFIGURATION IN THE DS
SUBSTITUTE DCINFO FOR DC
   FRS  DomainControllerName: (null)
   Computer Name            : DC2008E-0
   Computer DNS Name        : DC2008E-0.domain.com

并且该输出在所有 3 个 DC 上也都是正确的。

再次 - 据我所知,其他一切似乎都运行良好。我们在 5 天前启用了新的 DC 并更新了功能级别。我不确定为什么会出现这些故障,并希望在继续退役之前将其清理干净。


额外细节:

我运行了脚本“通过 PowerShell 测试 SYSVOL 复制延迟/收敛”,一切似乎都顺利进行:

Name                      PDC   Site Name  DS Type    IP Address OS Version
----                      ---   ---------  -------    ---------- ----------
DC2008S-0.domain.com      FALSE sitename   Read/Write 10.1.1.3   Windows Server 2008 R2 Standard
DC2008E-0.domain.com      TRUE  sitename   Read/Write 10.1.1.27  Windows Server 2008 R2 Enterprise
DC2008E-1.domain.com      FALSE sitename   Read/Write 10.1.1.28  Windows Server 2008 R2 Enterprise

这一切都是正确的,报告得出了积极的结果!

  ====================== CHECK 6 ======================

  REMARK: Each DC In The List Below Must Be At Least Accessible Through SMB Over TCP (445)

  * Contacting DC In AD domain ...[DC2008E-1.domain.COM [SOURCE RWDC]]...
     - DC Is Reachable...
     - Object [sysvolReplTempObject20180926163805.txt] Exists In The NetLogon Share

  * Contacting DC In AD domain ...[DC2008S-0.domain.COM]...
     - DC Is Reachable...
     - Object [sysvolReplTempObject20180926163805.txt] Now Does Exist In The NetLogon Share

  * Contacting DC In AD domain ...[DC2008E-0.domain.COM]...
     - DC Is Reachable...
     - Object [sysvolReplTempObject20180926163805.txt] Now Does Exist In The NetLogon Share

  Start Time......: 2018-09-26 16:38:05
  End Time........: 2018-09-26 16:38:11
  Duration........: 6.20 Seconds

  Deleting Temp Text File...

  Temp Text File [sysvolReplTempObject20180926163805.txt] Has Been Deleted On The Target RWDC!


Name                                    Site Name  Time
----                                    ---------  ----
DC2008E-1.domain.COM [SOURCE RWDC]      sitename    0
DC2008S-0.domain.com                    sitename    6.17
DC2008E-0.domain.com                    sitename    6.20

更多细节:

我还运行了脚本“通过 PowerShell 测试 Active Directory 复制延迟/收敛”来验证 AD 复制

Name                      Domain        GC   FSMO                Site Name  DS Type    IP Address OS Version
----                      ------        --   ----                ---------  -------    ---------- ----------
DC2008S-0.domain.com      domain.com   TRUE  .....               sitename Read/Write 10.1.1.3   Windows Server 2008 R2 Standard
DC2008E-0.domain.com      domain.com   TRUE  SCH/DNM/PDC/RID/INF sitename Read/Write 10.1.1.27  Windows Server 2008 R2 Enterprise
DC2008E-1.domain.com      domain.com   TRUE  .....               sitename Read/Write 10.1.1.28  Windows Server 2008 R2 Enterprise

所有 DC 在林中均正确显示,然后进行域检查(上面列出的域输出。看到它们都有一个全局目录,并且 DC2008E-0 具有我们所有的 FSMO 角色)

====================== CHECK 15 ======================

  REMARK: Each DC In The List Below Must Be At Least Accessible Through LDAP Over TCP (389)
  REMARK: Each GC In The List Below Must Be At Least Accessible Through LDAP-GC Over TCP (3268)

  * Contacting DC In AD domain ...[DC2008E-1.domain.COM [SOURCE RWDC]]...
     - DC Is Reachable...
     - Object [CN=adReplTempObject20180926164916,CN=Users,DC=domain,DC=com] Exists In The Database

  * Contacting DC In AD domain ...[DC2008S-0.domain.COM]...
     - DC Is Reachable...
     - Object [CN=adReplTempObject20180926164916,CN=Users,DC=domain,DC=com] Now Does Exist In The Database

  * Contacting DC In AD domain ...[DC2008E-0.domain.COM]...
     - DC Is Reachable...
     - Object [CN=adReplTempObject20180926164916,CN=Users,DC=domain,DC=com] Now Does Exist In The Database

  Start Time......: 2018-09-26 16:49:16
  End Time........: 2018-09-26 16:49:32
  Duration........: 15.59 Seconds

  Deleting Temp Contact Object...

  Temp Contact Object [CN=adReplTempObject20180926164916,CN=Users,DC=domain,DC=com] Has Been Deleted On The Target RWDC!


Name                                    Domain        GC   Site Name   Time
----                                    ------        --   ---------   ----
DC2008E-1.domain.COM [SOURCE RWDC]     domain.com    TRUE sitename     0
DC2008E-0.domain.com                   domain.com    TRUE sitename    15.59
DC2008S-0.domain.com                   domain.com    TRUE sitename    2.20

再次,一切看起来都复制得很好。还是 15 秒太长了?是这个延迟导致我在 dcdiag 测试中感到焦虑吗?


另一个更新!

我已验证每个 DC 上每个区域的 SOA 序列号是否匹配。

我还检查了 _msdcs 区域中的所有子目录和记录,那里的所有内容也 100% 匹配。

答案1

听起来您遇到了 SYSVOL 复制问题,我建议使用以下 Powershell 工具来测试 SYSVOL 复制:https://gallery.technet.microsoft.com/Testing-SYSVOL-Replication-c3e9dc68

一旦确认 SYSVOL 复制存在问题,您可以通过执行非权威性 SYSVOL 还原来解决。https://support.microsoft.com/en-us/help/290762/using-the-burflags-registry-key-to-reinitialize-file-replication-servi

如果非权威性不起作用,您可以使用权威性恢复,但要小心,因为这更危险。

解决了 SYSVOL 复制问题后,我建议从 FRS 复制迁移到 DFS-R 复制。https://blogs.technet.microsoft.com/filecab/2014/06/25/streamlined-migration-of-frs-to-dfsr-sysvol/

作为参考,如果需要,还有一组 DFS-R 重新同步步骤:https://support.microsoft.com/en-us/help/2218556/how-to-force-an-authoritative-and-non-authoritative-synchronization-fo

Jorge 还提供了一个 ADDS 复制检查 powershell 脚本,我建议运行:https://gallery.technet.microsoft.com/Testing-Active-Directory-94e61e3e

人们经常忘记 Active Directory 复制由两个独立的部分组成,即 ADDS 和 SYSVOL。如果任何一方发生故障,您都会遇到大问题。除此之外,FRS 和 DFS-R 因默默失败而臭名昭著,并给 GPO 带来灾难性的后果。GPO 的 ADDS 端将在 DC 之间匹配,但 SYSVOL 端(包含 GPO 的实际指令)则不会。

不确定 RREG 问题,但我想确认您的反向 DNS 查找区域是否已正确设置并复制。您可以确认两个 DC 之间的区域序列号以进行收敛。此外,检查 _msdcs 正向区域是否存在错误,包括不正确的 NS 条目。


经过与 OP 进一步讨论,我发现了这个链接:https://social.technet.microsoft.com/Forums/windowsserver/en-US/2ce07c3f-9956-4bec-ae46-055f311c5d96/dcdiag-test-failed-on-verifyenterprisereferences?forum=winserverDS

看来他最初的错误“测试 VerifyEnterpriseReferences 失败”是将域从 2003 级别迁移到 2008 级别之后但在从 FRS 迁移到 DFS-R SYSVOL 复制之前出现的已知和预期错误。可以安全地忽略该错误,但最佳做法是完成 DFS-R 迁移。

相关内容