Dfsr 4612 ошибка

Что вы знаете об отпуске? Отпуск — это круто! Кто-то едет окучивать грядки, кто-то пляжи. Но однозначно, самая плохая мысль, которая может придти в голову — работать в отпуске. Если вы, сидя на пляже, пытаетесь проверить рабочую почту, участвуете в конференциях, раздаете какие-то указания, проверяете работу сотрудников, то вам, скорее всего надо к доктору. Это не отпуск, это мука.
Я провел отпуск правильно. Выключил телефон, благо компания Билайн позаботилась о том, чтобы у меня не было никакой связи в том месте, где я находился, не заходил в интернет, и полностью посвятил себя простому деревенскому быту. А вот вернувшись в Северную Пальмиру, я обнаружил приличное количество писем от одного веселого заказчика, которого я на самом деле обожаю, ибо он обеспечивает меня не просто работой, а постоянными симуляторами геморроя. В общем и целом, задачка была опять из разряда: “Шеф, усе пропало!”. Основная задача была связана с восстановлением организации Exchange практически с нуля, но внезапно выплыл некий side project, в виде мертвой службы ADDS в домене, который обслуживает инфраструктуру (гипервизоры и все, что с ними связано).

Что же произошло?
Умер сервер с ролью контроллера домена вместе с дисками, на которых находился его VHD. Умер от слова совсем, и восстановлению не подлежит. Слово “бэкап” произносить в данном контексте неуместно, т.к. парни не просто смелые, а отважные. И резервных копий нет и, похоже, никогда и не было. Но есть же второй контроллер домена! Круто!
Правда есть один нюанс: ни один инструмент управления службой ADDS не смог подключиться к ней со словами “The domain can’t exist or can’t be contacted”. Т.е. домен вроде как есть, но в то же время его вроде как и нет.
Куда нужно сходить первым делом, если есть какие-то проблемы с доступом к Active Directory? Ведущие собаководы утверждают, что первым делом надо смотреть в Domain Name System, т.к. “99% проблем с AD это проблемы с DNS!” (городская легенда).
Но там все оказалось вполне себе неплохо. Поудалял записи от старого контроллера (некоторые, типа А удаляются простым Delete, некоторые, типа NS надо удалять на вкладке Name Servers соответствующих зон). Привел в порядок, одним словом. Результат? Нулевой.
Смотрим дальше… При запуске DCDIAG получаем ошибку 1355, причем у меня их было несколько (GC_SERVER_REQUIRED, PDC_REQUIRED и еще всякие разные, в общем все сводилось к такому вот шаблону текста: DcGetDcName(PDC_REQUIRED) call failed, error 1355). По моему скромному разумению все это указывает на проблемы с механизмом Domain Controller Locator.
Вначале меня посетила мысль о том, что роли FSMO остались на стром контроллере, но это не совсем укладывалось в текущую картину, т.к. роли FSMO особо на DC Locator не влияют. Вернее влияют, но не в контексте обычной аутентификации. Проверив расположение ролей с помощью NTDSUTIL, я обнаружил отсутствие информации о старом контроллере. Т.е. метаданные из базы кто-то вычистил до меня (на самом деле, заказчик мне привел экспертное заключение каких-то абстрактных специалистов, что домену пришла труба, и никаких вариантов восстановления просто нет, кроме как создать новый домен, и “перезавести машины в него”. Видимо это и были авторы удаления метаданных).
Что было еще более интересным, так это отсутствие shared folders, которые мы привыкли видеть на любом контроллере домена: SYSVOL и NETLOGON. По сути эти каталоги представляют собой хранилище политик домена (SYSVOL) и логон-скриптов (NETLOGON).
Соответственно, физически они расположены (при дефолтной инсталляции) в C:Windowssysvol<Имя домена>sysvol (SYSVOL Shared Folder) и C:Windowssysvol<Имя домена>sysvolscripts (NETLOGON Shared Folder). Создание этих shared folders вручную ни к какому результату не приводит: ни контроллер от этого работать не начнет, ни сами настройки не сохранятся (при первой же перезагрузке эти shared folders исчезают).
Лезем в Event Viewer. В логе службы ADDS все на первый взгляд ровно. Как и на второй. Интересности обнаруживаются в логе службы репликации распределенной файловой системы (Applications and Services LogsDFS Replication). Там я нашел довольно интересное событие DFSR Error 4612, которое говорит о том, что каталог SYSVOL на данном контроллере был инициализирован и ожидает начальной репликации от умершего контроллера. И, что самое забавное, данный контроллер до завершения процесса репликации не будет работать. Прямо так в логе и пишется. Т.е. по идее, создание роли контроллера домена было не завершено до конца с самого начала, и он никогда не функционировал, как контроллер. Тупо стоял и молотил воздух.
Как же его завести, если того самого контроллера, с которого он ожидает начальной репликации, не существует? Тут на помощь нам приходит процедура авторитативного восстановления SYSVOL. Почему авторитативного? Потому что других “авторитетов” в сети, кроме этого единственного контроллера нет. Не на кого положиться, и ему придется принимать решение самому. Для этого, правда, он должен быть держателем роли PDC Emulator. Захват роли процедура не сложная, с учетом неработоспособности соврменных инструментов управления (консоли и модуль Active Directory в PowerShell), придется работать по старинке. Так как же произвести процедуру авторитативного восстановления SYSVOL при неработающем редакторе ADSIedit? Использовать вместо этого LDP.exe.
Итак, что же было сделано:
1. Остановлена служба репликации:
net stop DFSR или Stop-Service DFSR
2. Далее мне нужно изменить значение двух аттрибутов сервиса SYSVOL Subscription контроллера домена, объект которого можно найти по LDAP-пути CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>
msDFSR-Enabled=FALSE (говорит о том, что репликации нет, дефолтное значение TRUE)
msDFSR-Options=1 (говорит о том, что наш контроллер обладает авторитативным экземпляром, т.е. истинным и верным, дефолтное значение 0)
Проблема была в том, что ADSIedit при попытке подключения к любому из контекстов AD, говорил, что домена не существует, либо он недоступен.
Меня спасла утилита LDP.exe, которая позволяет напрямую подключиться к экземпляру NTDS.dit (вру, конечно, т.к. подключение происходит по LDAP-протоколу на порт 389).
2а. Запускаем LDP.exe, жмем Connection — Bind (Ctrl+B) и цепляемся прямо к контроллеру домена, на котором мы ее и запустили в контексте текущего пользователя (прав-то, надеюсь, достаточно? Нужны права группы Domain Adminы). По сути просто жмем ОК.
2б. Дальше нам нужно подключиться к Default Naming Context, для чего жмем View — Tree (Ctrl+T) и в BaseDN выбираем корень домена в LDAP формате: DC=domain,DC=com).
2в. Ищем объект службы SYSVOL Subscription, последовательно раскрывая ветки дерева. Напоминаю, объект находится по пути CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>.
2г. Выделяем объект, и в контекстном меню (умное слово, на самом деле это меню правой кнопки мыши :)) выбираем Modify (Ctrl+M).
2д. В области Edit Entry, в поле Attribute вводим msDFSR-Enabled, в поле Values вводим FALSE. Выбираем Operation = Replace, жмем кнопку Enter, видим, что операция появилась в Entry List. Вводим данные для второго аттрибута (Attribute = msDFSR-Options, Values = 1, так же жмем Enter, и проверяем наличие в Entry List), и вот после этого жмем кнопку Run. И получаем ошибку 0x2098 Insufficient access rights Лечится просто: запустите LDP.exe от имени администратора (RunAs Administrator), UAC на серверах все-таки зло… В итоге должно получиться сообщение, что вызов ldap_modify_s изменил 2 аттрибута объекта службы SYSVOL Subscription.
2е. Не 3акрываем LDP.exe, она нам еще понадобится.
3. Запускаем службу репликации распределенной файловой системы:
net start DFSR или Start-Service DFSR
NOTE: Перед запуском этой команды рекомендуют очистить каталоги
%WINDIR%SYSVOL<Имя домена>sysvolPolicies
%WINDIR%SYSVOL<Имя домена>sysvolScripts
чтобы не получить кучу неработающих политик. Но у меня там было чисто, т.к. контроллер даже не выполнил начальной репликации.
4. В журнале службы (Applications and Services LogsDFS Replication) сразу же получаем событие от DFSR EventID 4114, которое говорит о том, что репликация каталога SYSVOL отключена.
5. Меняем значение msDFSR-Enabled обратно в TRUE (шаги 2а — 2д, обратите внимание, что меняем значение только одного аттрибута, msDFSR-Options не трогаем)
6. Запускаем репликацию (из командной строки, запущенной с повышением привилегий, иначе опять получите сообщение о недостатке прав):
repadmin /syncall /AdP
7. Запускаем dfsrdiag /ADPoll (если получаете сообщение, что команда не распознана, установите DFS Management Tools, они в FeaturesRemote server Administration ToolsRole Administration ToolsFile Services Tools или Add-WindowsFeature RSAT-DFS-Mgmt-Con)
8. В журнале DFS Replication должно появиться событие DFSR EventID 4602, говорящее о том, что процесс авторитативного восстановления запущен.
На этом все. Перезагружаем сервер и пробуем запустить, например, ADUC. Но тут меня ждал Его Величество Облом. Не работает.
Дело оказалось в том, что каталог SYSVOL был, но политик в нем не было. А их должно быть минимум две: Default Domain Policy c GUID {31B2F340-016D-11D2-945F-00C04FB984F9} и Default Domain Controller Policy c GUID {6AC1786C-016F-11D2-945F-00C04FB984F9}.
Восстановить их можно с помощью утилиты DCGPOFIX, которая воссоздает политики, используя для этого политики, которые хранятся в базе AD (CN=Policies,CN=System,DC=Domain,DC=ru). Один нюанс, даже два:
1. Все изменения, которые вы делали в этих двух политиках, придется делать заново, т.к. большинство настроек хранятся в GPT как раз в каталоге SYSVOLPolicies, а у нас там ничего нет.
2. Сертификат для EFS, если он используется в Default Domain Policy так же не пересоздается. придется все делать вручную. И дай Бог, чтобы у вас не было включено шифрование EFS на уровне политик…
Собственно после выполнения этой последней процедуры, контроллер ожил и заработал.
Выводы и уроки:
1. Развертывание дополнительного контроллера домена — не просто NNF (Next-Next-Finish), хотя казалось бы, чего там сложного, но данный случай показывает, что не проконтролировав процесс начальной репликации, в итоге администратор получил тыкву, практически бесполезную единицу.
2. Резервное копирование — это не для трусов, оно для умных. Наличие простой копии System State могло сильно упростить жизнь.
3. Ну и если вы встряли в подобное, не стоит сразу делать выводов космического масштаба и… ну вы поняли Есть городская легенда, что службу ADDS можно спасти при наличии всего лишь файла NTDS.dit. Так что never give up. Пишите мне, в конце концов, придумаем что-нибудь

Имеется контроллер домена DC01 на Windows Server 2012 R2 (уровень доменалеса 2012 R2) со всеми ролями FSMO, DNS, а также он DHCP.

PS C:Windowssystem32> netdom /query fsmo
Хозяин схемы                DC01.*.*.*
Хозяин именования доменов   DC01.*.*.*
PDC                         DC01.*.*.*
Диспетчер пула RID          DC01.*.*.*
Хозяин инфраструктуры       DC01.*.*.*
Команда выполнена успешно.

В журнале DFS появляется ошибка —

Имя журнала:   DFS Replication
Источник:      DFSR
Дата:          07.04.2014 11:35:47
Код события:   6002
Категория задачи:Отсутствует
Уровень:       Ошибка
Ключевые слова:Классический
Пользователь:  Н/Д
Компьютер:     DC01.*.*.*
Описание:
Служба репликации DFS обнаружила недопустимые данные объекта 
msDFSR-Subscriber при запросе  сведений о конфигурации. 
 
Дополнительные сведения: 
DN объекта: CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC01,
OU=Domain Controllers,DC=*,DC=*,DC=* 
Имя атрибута: msDFSR-MemberReference 
Контроллер домена: DC01.*.*.*
Цикл запроса: 60 мин
Xml события:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="DFSR" />
    <EventID Qualifiers="49152">6002</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2014-04-07T08:35:47.000000000Z" />
    <EventRecordID>276</EventRecordID>
    <Channel>DFS Replication</Channel>
    <Computer>DC01.*.*.*</Computer>
    <Security />
  </System>
  <EventData>
    <Data>msDFSR-Subscriber</Data>
    <Data>CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC01,
OU=Domain Controllers,DC=*,DC=*,DC=*</Data>
    <Data>msDFSR-MemberReference</Data>
    <Data>DC01.*.*.*</Data>
    <Data>60</Data>
  </EventData>
</Event>

Также имеется второй контроллер домена DC00, также Windows Server 2012 R2, на нем не появились шары SYSVOL и NETLOGON, в журнале следующее

Имя журнала:   DFS Replication
Источник:      DFSR
Дата:          07.04.2014 17:01:43
Код события:   4612
Категория задачи:Отсутствует
Уровень:       Ошибка
Ключевые слова:Классический
Пользователь:  Н/Д
Компьютер:     DC00.*.*.*
Описание:
Служба репликации DFS инициализировала SYSVOL по локальному 
пути C:WindowsSYSVOLdomain и готова к начальной репликации. 
Реплицированная папка останется в состоянии начальной синхронизации 
до выполнения репликации со своим партнером DC01.*.*.*. 
Если в это время выполнялось назначение сервера контроллером домена, 
контроллер домена не будет делать объявления и функционировать как 
контроллер домена, пока данная проблема не будет решена. Это могло 
произойти, если указанный партнер также находится в состоянии начальной 
синхронизации или обнаружены нарушения общего доступа на этом сервере 
или партнере синхронизации. Если данное событие произошло в результате 
миграции SYSVOL от службы репликации файлов (FRS) к репликации DFS, изменения 
не будут реплицироваться до тех пор, пока эта проблема не будет решена. 
В результате этого папка SYSVOL на данном сервере может стать не 
синхронизированной с другими контроллерами домена. 
  
Дополнительные сведения:  
Имя реплицированной папки: SYSVOL Share 
Идентификатор реплицированной папки: C0D02335-2516-4027-A9CA-0B86A386E210 
Имя группы репликации: Domain System Volume 
Идентификатор группы репликации: 5F0F06CC-E904-4E94-9ED2-9C70D442AD3B 
Код участника: 22614947-BBFD-4BE5-BBE0-20E99675B0B1 
Только для чтения: 0
Xml события:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="DFSR" />
    <EventID Qualifiers="49152">4612</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2014-04-07T14:01:43.000000000Z" />
    <EventRecordID>88</EventRecordID>
    <Channel>DFS Replication</Channel>
    <Computer>DC00.*.*.*</Computer>
    <Security />
  </System>
  <EventData>
    <Data>C0D02335-2516-4027-A9CA-0B86A386E210</Data>
    <Data>C:WindowsSYSVOLdomain</Data>
    <Data>SYSVOL Share</Data>
    <Data>Domain System Volume</Data>
    <Data>5F0F06CC-E904-4E94-9ED2-9C70D442AD3B</Data>
    <Data>22614947-BBFD-4BE5-BBE0-20E99675B0B1</Data>
    <Data>DC01.*.*.*y</Data>
    <Data>0</Data>
  </EventData>
</Event>

и

Имя журнала:   DFS Replication
Источник:      DFSR
Дата:          07.04.2014 17:01:43
Код события:   5002
Категория задачи:Отсутствует
Уровень:       Ошибка
Ключевые слова:Классический
Пользователь:  Н/Д
Компьютер:     DC00.*.*.*
Описание:
Служба репликации DFS обнаружила ошибку в подключении к 
партнеру DC01 для группы репликации Domain System Volume. 
 
DNS-адрес партнера: DC01.*.*.*
 
Доступные дополнительные сведения: 
WINS-адрес партнера: DC01 
IP-адрес партнера: 192.168.50.53 
  
Служба периодически будет пытаться установить подключение. 
 
Дополнительные сведения: 
Ошибка: 1753 (В системе отображения конечных точек не 
осталось доступных конечных точек.) 
Идентификатор подключения: 5F0F06CC-E904-4E94-9ED2-9C70D442AD3B 
Идентификатор группы репликации: D687A311-7DA0-48CC-8176-859049523817
Xml события:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="DFSR" />
    <EventID Qualifiers="49152">5002</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2014-04-07T14:01:43.000000000Z" />
    <EventRecordID>87</EventRecordID>
    <Channel>DFS Replication</Channel>
    <Computer>DC00.*.*.*</Computer>
    <Security />
  </System>
  <EventData>
    <Data>5F0F06CC-E904-4E94-9ED2-9C70D442AD3B</Data>
    <Data>DC01</Data>
    <Data>Domain System Volume</Data>
    <Data>DC01.*.*.*</Data>
    <Data>DC01</Data>
    <Data>192.168.50.53</Data>
    <Data>1753</Data>
    <Data>В системе отображения конечных точек не осталось 
доступных конечных точек.</Data>
    <Data>D687A311-7DA0-48CC-8176-859049523817</Data>
  </EventData>
</Event>

Решения из гугла не помогли. Если нужна еще какая-то информация — предоставлю.

I’ve just migrated my home/office Windows Server 2012 Essentials to 2016 Essentials. After some initial bumps with NETLOGON and SYSVOL shares not being created (since fixed) things are mostly working. The most troubling problem at the moment is the DFSR
5008 and 4612 errors in the event log and the server health reports.

5008:

The DFS Replication service failed to communicate with partner Kahuna for replication group Domain System Volume. This error can occur if the host is unreachable, or if the DFS Replication service is not running on the server.
 
Partner DNS Address: Kahuna.HULILI.local
 
Optional data if available:
Partner WINS Address: Kahuna
Partner IP Address:  
 
The service will retry the connection periodically.
 
Additional Information:
Error: 1722 (The RPC server is unavailable.)
Connection ID: 05FFA870-EB29-4CA3-BB95-2BCE5219A736
Replication Group ID: E9B7994D-940F-4D0B-B1DD-1B1523D55FB2

4612:

The DFS Replication service initialized SYSVOL at local path C:WINDOWSSYSVOLdomain and is waiting to perform initial replication. The replicated folder will remain in the initial synchronization state until it has replicated with its partner Kahuna.HULILI.local. If the server was in the process of being promoted to a domain controller, the domain controller will not advertise and function as a domain controller until this issue is resolved. This can occur if the specified partner is also in the initial synchronization state, or if sharing violations are encountered on this server or the sync partner. If this event occurred during the migration of SYSVOL from File Replication service (FRS) to DFS Replication, changes will not replicate out until this issue is resolved. This can cause the SYSVOL folder on this server to become out of sync with other domain controllers. 
 
Additional Information: 
Replicated Folder Name: SYSVOL Share 
Replicated Folder ID: 52AA1AA3-F96F-4CBF-8320-0BCD65CD94C2 
Replication Group Name: Domain System Volume 
Replication Group ID: 05FFA870-EB29-4CA3-BB95-2BCE5219A736 
Member ID: 132938DE-64A8-4F7E-A1F7-8B6FF55B0CEA 
Read-Only: 0

Both of these errors refer to the old 2012 server which has been demoted and shut down.

The old server name appears in the registry under HKEY_LOCAL_MACHINESYSTEMControlSet001ServicesNTDSparametersSrc Root Domain Srv and
HKEY_LOCAL_MACHINESYSTEMControlSet001ServicesDFSRParametersSysVolsSeeding SysVolsHULILI.localParent Computer. Maybe other locations too, but these are the only ones I’ve found.

Metadata cleanup in NTDSUTIL doesn’t find the old server.

All tests pass in DCDIAG, except for

      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.
         ......................... BIGKAHUNA failed test DFSREvent

Internet searches return lots of results for events 5008 and 4612 but nothing that seems to help with my situation.

Does anyone know how I can cleanup this broken replication?

Recently while making changes to group policy, I noticed a slew of issues between clients not accepting the policy.  This eventually led me to the discovery that two of the DCs in this particular environment were not replicating properly and were resulting in inconsistent SYSVOL shares.

Symptoms

On the clients we were seeing the following errors when executing the gpupdate command:

Event Viewer Logs

Log Name: System
Source: Microsoft-Windows-GroupPolicy
Date: 7/25/2014 10:46:45 AM
Event ID: 1096
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: mymachine.mydomain.local
Description:
The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LDAP://CN=Machine,cn={CF25ED30-3895-4147-8EB7-38789553F6A0},cn=policies,cn=system,DC=mydomain,DC=local. Group Policy settings will not be resolved until this event is resolved. View the event details for more information on the file name and path that caused the failure.

On the DCs we were seeing the following events inside of Event Viewer -> Applications and Service Logs -> DFS Replication

Log Name: DFS Replication
Source: DFSR
Date: 7/25/2014 1:04:30 PM
Event ID: 4612
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DC02.mydomain.local
Description:
The DFS Replication service initialized SYSVOL at local path C:WindowsSYSVOLdomain and is waiting to perform initial replication. The replicated folder will remain in the initial synchronization state until it has replicated with its partner DC01.mydomain.local. If the server was in the process of being promoted to a domain controller, the domain controller will not advertise and function as a domain controller until this issue is resolved. This can occur if the specified partner is also in the initial synchronization state, or if sharing violations are encountered on this server or the sync partner. If this event occurred during the migration of SYSVOL from File Replication service (FRS) to DFS Replication, changes will not replicate out until this issue is resolved. This can cause the SYSVOL folder on this server to become out of sync with other domain controllers.

Additional Information:
Replicated Folder Name: SYSVOL Share
Replicated Folder ID: 2276C68D-BC24-46BF-B492-067919163EDA
Replication Group Name: Domain System Volume
Replication Group ID: D50C64AE-0A01-4F97-B838-069F0BCBE369
Member ID: 7ADF2D7C-7947-412C-A619-C0C0D72F6A9C
Read-Only: 0

---

Log Name: DFS Replication
Source: DFSR
Date: 7/25/2014 1:04:30 PM
Event ID: 5002
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DC02.mydomain.local
Description:
The DFS Replication service encountered an error communicating with partner DC01 for replication group Domain System Volume.

Partner DNS address: DC01.mydomain.local

Optional data if available:
Partner WINS Address: DC01
Partner IP Address: 192.168.1.5

The service will retry the connection periodically.

Additional Information:
Error: 1753 (There are no more endpoints available from the endpoint mapper.)
Connection ID: D50C64AE-0A01-4F97-B838-069F0BCBE369
Replication Group ID: 4DCE6A8E-6271-48B6-A0D0-5447718B8FAB

Solution

We ended up having to manually preform an authoritive synchronization between the two DCs.  As you may know, DFSR no longer uses the same steps as FSR to do an authoritive sync.  Below are my notes and expereinces on completing an authoritive DFSR sync.  You can find the ofificial notes from Microsoft here: http://support.microsoft.com/kb/2218556/en-us

1. Logon to your primary DC
2. Stop the DFS Replication service
   1. Click on the Start menu, select Administrative Tools, and then click Services
   2. In the Name column, right-click DFS Replication or Netlogon, and then click Stop
3. Open up ADSI Edit
   
   
4. Open up the Default naming context
   
   
5. Navigate to the following
   1. CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name to replicate from>,OU=Domain Controllers,DC=<domain>
      
      
6. Change the following attributes to the following values
   1. msDFSR-Enabled=FALSE
      msDFSR-options=1
      
      
      Both values applied
      
      
      1. Note: If you cannot see msDFSR-options, uncheck Show only attributes that have values
         
7. On the ALL other DCs, change the msDFSR-Enabled attribute to False
   
   
8. Force Active Directory replication throughout the domain (ensure all sync resposnes terminate with no errors).
   1. repadmin /syncall primary_dc_name /APed
      
      1. NOTE: Here is a list of what the switches mean
         1. /A: Perform /SyncAll for all NC’s held by <Dest DSA> (ignores <Naming Context>)
         2. /P: Push changes outward from home server (default: pull changes)
         3. /e: Enterprise, cross sites (default: only home site)
         4. /d: ID servers by DN in messages (instead of GUID DNS)
9. Start the DFSR service back up on the authoritive DC
   1. Click on the Start menu, select Administrative Tools, and then click Services
      
   2. In the Name column, right-click DFS Replication or Netlogon, and then click Start
10. Open up event viewer and navigate to Applications and Services Logs -> DFS Replication.  Verify you see Event ID 4114.
    
11. Navigate back to the following in ADSI
    1. 1. CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name to replicate from>,OU=Domain Controllers,DC=<domain>
          
          
12. Set the value of msDFSR-Enabled to TRUE
    
    
13. Execute the following via an elevated command prompt
    1. DFSRDIAG POLLAD
       1. NOTE: This is a utility apart of DFS Managment Tools.  I completed the guide successfully without running this command, but Microsoft recommends you do run this command.
14. Force Active Directory replication throughout the domain
    1. repadmin /syncall primary_dc_name /APed
       
       
15. Wait a few minutes and you should see Event ID 2002 and 4602
    
    
16. Navigate back to each of your secondary DCs and change the value of msDFSR-Enabled to TRUE
    
    
17. Execute the following via an elevated command prompt
    1. DFSRDIAG POLLAD
       1. NOTE: This is a utility apart of DFS Managment Tools. I completed the guide successfully without running this command, but Microsoft recommends you do run this command. Force Active Directory replication throughout the domain
18. Verify you see Event ID 2002 and 4602 on each of the secondary DCs
    

At this point, try running a gpupdate on your client.  If all has gone well, each of your shared SYSVOL folders on your DCs should contain the same amount of policies and your client should successfully pull down all policies.