Все контроллеры домена не проходят проверку 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 Standard.
Все контроллеры домена не проходят тест 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. (ASDIEdit, корневой домен, контекст именования по умолчанию, CN= система, CN= служба репликации файлов, CN= системный том домена (общий ресурс 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%.
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
Хорхе также предоставляет сценарий Powerhell для проверки репликации ADDS, который я бы порекомендовал запустить: https://gallery.technet.microsoft.com/Testing-Active-Directory-94e61e3e
Люди часто забывают, что репликация Active Directory состоит из двух отдельных половинок, ADDS и SYSVOL. Если одна из сторон потерпит неудачу, вы столкнетесь с большими проблемами. Кроме того, FRS и DFS-R печально известны тем, что молча терпят неудачу с катастрофическими последствиями для объекта групповой политики. Сторона GPDS 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.