windows-server-2008 – 所有DC失败VerifyEnterpriseReferences

发布时间：2020-12-13 23:20:35 所属栏目：Windows 来源：网络整理

导读：因此,我们最近在我们的域(Win 2008 R2 Enterprise)中添加了一个新的DC,其想法是用第二个企业版替换我们的Win 2008 R2标准DC – 这将为我们提供2008 R2企业版的2个DC. 在添加此DC时,我们最终还提升了从2003年到2008年的林和域级别. 据我所知,一切都复制得很好

因此,我们最近在我们的域(Win 2008 R2 Enterprise)中添加了一个新的DC,其想法是用第二个企业版替换我们的Win 2008 R2标准DC – 这将为我们提供2008 R2企业版的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,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,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的知识库文章

我仍然试图跟随,只是为了看看我发现了什么.

Server-Reference似乎在我们所有的DC上填写. (ASDIEdit,根域,默认命名上下文,CN = System,CN =文件复制服务,CN =域系统卷(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,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上的输出都是正确的.

再说一遍 – 据我所知,其他一切似乎都很有效.我们现在浮动新的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在Forest中都是正确的,然后是域检查(上面列出的域输出.看到它们都有一个全局编录,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=com] Exists In The Database

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

  * Contacting DC In AD domain ...[DC2008E-0.domain.COM]...
     - DC Is Reachable...
     - Object [CN=adReplTempObject20180926164916,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,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测试中导致agita？

另一个更新！

我已经验证了每个DC上每个区域中的SOA序列号匹配.

我还浏览了_msdcs区域中的所有子目录和记录,并且那里的所有内容都匹配100％.

听起来你有一个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

在将域从2003级迁移到2008级之后但在从FRS迁移到DFS-R SYSVOL复制之前,他的原始错误“失败的测试VerifyEnterpriseReferences”似乎是已知且预期的错误.可以安全地忽略该错误,但最佳实践涉及完成DFS-R迁移.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!