Назад | Перейти на главную страницу

Все контроллеры домена не проходят проверку VerifyEnterpriseReferences и DNS RReg - все остальное работает, включая репликацию на новый контроллер домена

Итак, мы недавно добавили новый DC в наш домен (Win 2008 R2 Enterprise) с идеей заменить наш Win 2008 R2 Standard DC на второй Enterprise, что даст нам 2 DC в 2008 R2 Enterprise.

При добавлении этого DC мы также подняли уровень леса и домена с 2003 по 2008 год.

Насколько я могу судить, все воспроизводится нормально. Нет проблем с AD, SYSVOL или чем-либо еще.

Я проверяю, все ли хорошо и плотно, прежде чем понижать стандартную коробку 2008 R2.

Все контроллеры домена не проходят проверку 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

Я все еще пытался следовать, просто чтобы посмотреть, что найду.

Ссылка на сервер, кажется, заполнена на всех наших контроллерах домена. (ASDIEdit, корневой домен, контекст именования по умолчанию, CN = System, CN = File Replication Service, CN = Domain System Volume (общий ресурс SYSVOL), все 3 контроллера домена указаны как 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

Но второе значение истинно (с разными именами DC) для всех 3 DC.

Однако если я запустил ntfrsutl ds, я получу (нулевой) вывод:

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 и обновили функциональные уровни 5 дней назад. Я не уверен, почему я получаю эти отказы, и хотел бы исправить это, прежде чем продолжить вывод из эксплуатации.


Дополнительные детали:

Я запустил сценарий «Тестирование задержки / сходимости репликации SYSVOL с помощью PowerShell», и все, похоже, взорвалось:

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

Подробнее:

Я также запустил сценарий «Тестирование задержки / конвергенции репликации Active Directory через PowerShell», чтобы проверить репликацию 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

Все контроллеры домена появляются правильно в лесу, а затем проверяется домен (выходные данные домена указаны выше. Видно, что все они имеют глобальный каталог, а 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?


Очередное обновление!

Я проверил, что серийный номер SOA в каждой зоне на каждом DC совпадает.

Я также просмотрел все подкаталоги и записи в зоне _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

Хорхе также предоставляет сценарий PowerShell для проверки репликации ADDS, который я бы рекомендовал запустить: https://gallery.technet.microsoft.com/Testing-Active-Directory-94e61e3e

Люди часто забывают, что репликация Active Directory состоит из двух частей: ADDS и SYSVOL. Если одна из сторон потерпит неудачу, у вас возникнут большие проблемы. Вдобавок к этому FRS и DFS-R печально известны тем, что молча терпят неудачу с катастрофическими последствиями для GPO. Сторона ADDS объектов GPO будет соответствовать между контроллерами домена, но сторона SYSVOL (которая содержит фактические инструкции для GPO) - нет.

Не уверен в проблеме RREG, но я хотел бы подтвердить, что ваши зоны обратного просмотра DNS настроены и реплицируются правильно. Вы можете подтвердить серийные номера зоны между двумя контроллерами домена для схождения. Кроме того, проверьте зону пересылки _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.