Сбой репликации Sysvol между контроллерами домена Server 2008 R2
Недавно мы добавили второй DC в нашу сеть на другом сайте. Похоже, что DC не испытывают каких-либо трудностей при связи через сеть, и объекты AD (пользователи, компьютеры и т. Д.) Синхронизируются правильно. Тем не менее, групповые политики не являются. Изучение C:\Windows\SYSVOL\domain папка на новом контроллере домена показывает, что он пуст, тогда как на старом контроллере домена он содержит Policies а также scripts папки со связанным содержимым.
Тем не мение, dcdiag не показывает никаких явных намеков на то, что не так (см. вывод ниже), и DFSR, кажется, считает, что он реплицируется правильно, в соответствии с выводом dfsradmin backlog, dfsrdiag replicationstate не показывает активных соединений, но я не уверен, нормально ли это; dfsradmin membership list показывает оба DC.
У кого-нибудь есть какие-либо идеи? Я в значительной степени в своем уме; Я бы даже попытался вручную скопировать политики, если бы не тот факт, что при этом возникает много проблем с разрешениями.
dcdiag выход:
C:\Windows\system32>dcdiag
Directory Server Diagnosis
Performing initial setup:
Trying to find home server...
Home Server = HACTAR
* Identified AD Forest.
Done gathering initial info.
Doing initial required tests
Testing server: Saturn\HACTAR
Starting test: Connectivity
......................... HACTAR passed test Connectivity
Doing primary tests
Testing server: Saturn\HACTAR
Starting test: Advertising
......................... HACTAR passed test Advertising
Starting test: FrsEvent
......................... HACTAR passed test FrsEvent
Starting test: DFSREvent
There are warning or error events within the last 24 hours after the
SYSVOL has been shared. Failing SYSVOL replication problems may cause
Group Policy problems.
......................... HACTAR failed test DFSREvent
Starting test: SysVolCheck
......................... HACTAR passed test SysVolCheck
Starting test: KccEvent
......................... HACTAR passed test KccEvent
Starting test: KnowsOfRoleHolders
......................... HACTAR passed test KnowsOfRoleHolders
Starting test: MachineAccount
......................... HACTAR passed test MachineAccount
Starting test: NCSecDesc
......................... HACTAR passed test NCSecDesc
Starting test: NetLogons
Unable to connect to the NETLOGON share! (\\HACTAR\netlogon)
[HACTAR] An net use or LsaPolicy operation failed with error 67,
The network name cannot be found..
......................... HACTAR failed test NetLogons
Starting test: ObjectsReplicated
......................... HACTAR passed test ObjectsReplicated
Starting test: Replications
......................... HACTAR passed test Replications
Starting test: RidManager
......................... HACTAR passed test RidManager
Starting test: Services
......................... HACTAR passed test Services
Starting test: SystemLog
An error event occurred. EventID: 0x00000422
Time Generated: 10/10/2014 14:39:05
Event String:
The processing of Group Policy failed. Windows attempted to read the
file \\bistromath.domains.h2g2.local\sysvol\bistromath.domains.h2g2.local\Polic
ies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini from a domain controller and
was not successful. Group Policy settings may not be applied until this event is
resolved. This issue may be transient and could be caused by one or more of the
following:
[snip: many identical log entries]
......................... HACTAR failed test SystemLog
Starting test: VerifyReferences
......................... HACTAR passed test VerifyReferences
Running partition tests on : ForestDnsZones
Starting test: CheckSDRefDom
......................... ForestDnsZones passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... ForestDnsZones passed test
CrossRefValidation
Running partition tests on : DomainDnsZones
Starting test: CheckSDRefDom
......................... DomainDnsZones passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... DomainDnsZones passed test
CrossRefValidation
Running partition tests on : Schema
Starting test: CheckSDRefDom
......................... Schema passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... Schema passed test CrossRefValidation
Running partition tests on : Configuration
Starting test: CheckSDRefDom
......................... Configuration passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... Configuration passed test CrossRefValidation
Running partition tests on : bistromath
Starting test: CheckSDRefDom
......................... bistromath passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... bistromath passed test CrossRefValidation
Running enterprise tests on : bistromath.domains.h2g2.local
Starting test: LocatorCheck
......................... bistromath.domains.h2g2.local passed test
LocatorCheck
Starting test: Intersite
......................... bistromath.domains.h2g2.local passed test
Intersite
dfsrdiag backlog:
C:\Windows\system32>dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:queeg /rmem:hactar
No Backlog - member <hactar> is in sync with partner <queeg>
dfsrdiag replicationstate:
C:\Windows\system32>dfsrdiag replicationstate
Summary
Active inbound connections: 0
Updates received: 0
Active outbound connections: 0
Updates sent out: 0
dfsradmin membership list:
C:\Windows\system32>dfsradmin membership list /rgname:"Domain System Volume"
MemName RfName LocalPath StagingPath StagingSize
HACTAR SYSVOL Share C:\Windows\SYSVOL\domain C:\Windows\SYSVOL\staging areas\bistromath.domains.h2g2.local 4096
QUEEG SYSVOL Share C:\Windows\SYSVOL\domain C:\Windows\SYSVOL\staging areas\bistromath.domains.h2g2.local 4096
2 ответа
В конечном итоге я решил эту проблему, демонтировав новый DC, оставив его в качестве простого члена на несколько дней, а затем повторно продвигая его (для выполнения дополнительных тестов). Повторная реклама привела к тому, что новый контроллер правильно скопировал ранее отсутствующие файлы, что сделало тесты несколько избыточными.
Тем не менее, я должен отметить, что я действительно пытался понизить и повторно рекламировать новый DC раньше, но безрезультатно. Возможно, длительный период, в течение которого не выполнялась репликация DFS, вызвал некоторую форму тайм-аута; учитывая отсутствие четких данных, я предпочитаю, как это было отсортировано.
Я знаю, что это старый вопрос, но я столкнулся с той же проблемой после того, как объявил новую виртуальную машину Windows 2016 новым DC. Гугл привел меня сюда.
Вот что я узнал в надежде, что это поможет другим:
Если резервное копирование любого из ваших DC выполняется с использованием VSS, VSS приостанавливает DFSR. Это нормально. Зарегистрированные события могут привести к жалобе DCDIAG.
Вы можете увидеть некоторые обращения вокруг, которые говорят что-то вроде "Очистите журнал событий DFS и снова запустите DCDIAG". Это правда, что DCDIAG не жалуется на DFSR, если вы очистили журнал, но это, конечно, обман.
В конечном счете, вам необходимо убедиться, что репликация DFS действительно выполняется.
Официальный способ сделать это - инструмент управления DFS (Системный менеджер | Инструменты | Управление DFS).
В управлении DSF:
- в левой части действий щелкните " Создать диагностический отчет".
- Выберите " Тест на распространение", пройдите мастер, чтобы запустить тест.
- Через пару часов (ваш интервал может отличаться; у меня было 1,6 часа для трех DC), вернитесь в DFS Management и снова нажмите "Создать диагностический отчет".
- Выберите Отчет о распространении и создайте отчет.
Отчет откроется в браузере по умолчанию и покажет, работает ли распространение и сколько времени это заняло.