Принудительное выполнение заслуживающей и незаслуживающей доверия синхронизации для репликации sysvol, реплицированной службой DFSR
В этой статье описывается принудительное выполнение заслуживающей и незаслуживающей доверия синхронизации репликации sysvol, реплицированной службой DFSR
Применяется к: Windows Server 2012 R2
Оригинальный номер базы знаний: 2218556
Аннотация
Рассмотрим следующий сценарий.
Вам необходимо принудительно выполнить заслуживающую доверия синхронизацию репликации sysvol на контроллере домена (DC). В службе репликации файлов (FRS) управление осуществляется с помощью значений данных D2 и D4Bur Flags
для значений реестра, но эти значения не существуют для службы репликации распределенной файловой системы (DFSR). Для этого нельзя использовать оснастку управления DFS (Dfsmgmt.msc) или Dfsradmin.exe командной строки. В отличие от пользовательских папок реплицированных DFSR, репликация sysvol намеренно защищена от любых изменений через интерфейсы управления, чтобы предотвратить аварии.
Как выполнить незаслуживающую доверия синхронизацию репликации sysvol, реплицированной DFSR (например, D2 для FRS)
В средстве ADSIEDIT.MSC измените следующие различающееся значение имени (DN) и атрибут на каждом контроллере домена, которые вы хотите сделать не заслуживающими доверия:
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain> msDFSR-Enabled=FALSE
Принудительное выполнение репликации Active Directory по всему домену.
Выполните следующую команду из командной строки с повышенными привилегиями на тех же серверах, которые заданы как не заслуживающие доверия:
DFSRDIAG POLLAD
В журнале событий DFSR отобразится код события 4114, указывающий, что репликация sysvol больше не реплицируется.
В том же DN из шага 1 задайте msDFSR-Enabled=TRUE.
Принудительное выполнение репликации Active Directory по всему домену.
Выполните следующую команду из командной строки с повышенными привилегиями на тех же серверах, которые заданы как не заслуживающие доверия:
DFSRDIAG POLLAD
В журнале событий DFSR отобразится код события 4614 и 4604, указывающий на инициализацию репликации sysvol. Этот контроллер домена теперь выполняет репликацию Sysvol D2 .
Как выполнить заслуживающую доверия синхронизацию репликации sysvol, реплицированной DFSR (например, D4 для FRS)
Задайте для запуска службы репликации DFS значение Manual (Вручную) и остановите службу на всех контроллерах домена в домене.
В средстве ADSIEDIT.MSC измените следующие DN и два атрибута на контроллере домена, который вы хотите сделать заслуживающим доверия (предпочтительно эмулятор PDC, который обычно является самым актуальным для репликации sysvol):
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain> msDFSR-Enabled=FALSE msDFSR-options=1
Измените следующие DN и один атрибут на всех остальных контроллерах домена в этом домене:
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain> msDFSR-Enabled=FALSE
Принудительно выполните репликацию Active Directory по всему домену и проверьте ее успешность на всех контроллерах домена.
Запустите службу DFSR на контроллере домена, который был установлен как заслуживающий доверия на шаге 2.
В журнале событий DFSR отобразится код события 4114, указывающий, что репликация sysvol больше не реплицируется.
В том же DN из шага 2 задайте msDFSR-Enabled=TRUE.
Принудительно выполните репликацию Active Directory по всему домену и проверьте ее успешность на всех контроллерах домена.
Выполните следующую команду из командной строки с повышенными привилегиями на том же сервере, который вы настроите как заслуживающий доверия:
DFSRDIAG POLLAD
В журнале событий DFSR отобразится код события 4602, указывающий на инициализацию репликации sysvol. Этот контроллер домена теперь выполняет репликацию Sysvol D4 .
Запустите службу DFSR на других не заслуживающих доверия контроллерах домена. В журнале событий DFSR отобразится код события 4114, указывающий, что репликация sysvol больше не реплицируется на каждом из них.
Измените следующие DN и один атрибут на всех остальных контроллерах домена в этом домене:
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain> msDFSR-Enabled=TRUE
Выполните следующую команду из командной строки с повышенными привилегиями на всех не заслуживающих доверия контроллерах домена (то есть всех, кроме ранее назначенного заслуживающим доверия):
DFSRDIAG POLLAD
Возврат службы DFSR к исходному типу запуска (автоматически) на всех контроллерах домена.
Дополнительные сведения
При установке флага заслуживающего доверия на одном контроллере домена необходимо незаслуживающим доверия способом синхронизировать все остальные контроллеры домена в домене. В противном случае вы увидите конфликты на контроллерах домена, исходящие из любых контроллеров домена, которые вы не назначили заслуживающими/незаслуживающими доверия и перезапуск службы DFSR. Например, если все сценарии входа были случайно удалены, а их копия вручную была помещена обратно на владельца роли эмулятора PDC, это делает этот сервер заслуживающим доверия и все остальные серверы не заслуживающими доверия, что гарантируют успешность и предотвращает конфликты.
Если какой-либо контроллер домена назначается заслуживающим доверия, эмулятор PDC как заслуживающий доверия является предпочтительным, так как его содержимое репликации sysvol является наиболее актуальным.
Использование флага заслуживающего доверия необходимо только в том случае, если необходимо принудительно синхронизировать все контроллеры домена. Если вы почините только один контроллер домена, сделайте его не заслуживающим доверия и не трогайте другие сервера.
При написании этой статьи для простоты описания предполагалась среда из 2 контроллеров домена. Если у вас несколько затронутых контроллеров домена, разверните шаги, чтобы включить все из них. Кроме того, предполагается, что у вас есть возможность восстановить данные, которые были удалены, перезаписаны, повреждены и т. д. ранее, если это сценарий аварийного восстановления для всех контроллеров домена в домене.
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по