Troubleshooting active directory replication

How to create SPNs manually

You can create SPNs manually using command line setspn tool. Run command prompt under account that has permissions to create SPN (Domain Admins and above) and type:

setspn -U -S MSSQLSvc/servername.domainname.net:1433 YourDomainName\YourAccountName

setspn -U -S MSSQLSvc/servername:1433 YourDomainName\YourAccountName

1
2
3

setspn-U-SMSSQLSvc/servername.domainname.net1433YourDomainName\YourAccountName

setspn-U-SMSSQLSvc/servername1433YourDomainName\YourAccountName

to register SPNs for both hostname and FQDN for SQL domain account.

You can also use Microsoft Kerberos Configuration Manager for SQL Server tool to analyze your environment and fix SPN related issues if any.

To Install:

Download the 32bit or 64bit version of the Kerberos Configuration Manager installer that matches your computer’s OS architecture.
Click Open to start the installation immediately or click Save to save the installation .msi file to disk and install it later.
Accept the license term of this tool.
Click Next to complete the installation.

To Launch the Tool:

After the installation is complete successfully, double click the KerberosConfigMgr.exe to launch the application.

To Generate SPN List from Command Line:

Go to command line.
Switch to the folder where KerberosConfigMgr.exe is.
Type KerberosConfigMgr.exe -q -l
For more command line option, type KerberosConfigMgr.exe -h

To generate SPNs from a GUI:

Double click on KerberosConfigMgr.exe
Enter credentials that have permissions to register SPNs
Wait for the tool to analyze your environment
Apply necessary fixes

To Save a Server’s Kerberos Configuration Information:

Connect to the target windows server.
Click on Save button on the toolbar
Specify the location where you want the file to be saved at. It can be on a local drive or network share.
The file will be saved as .XML format.

To View a Server’s Kerberos Configuration Information from Saved File:

Click on the Load button on the toolbar.
Open the XML file generated by Kerberos Configuration Manager.

To Generate a Script to Fix SPN from Command Line:

Click on the Generate button for the SPN entry.
The generated script can be used by a user who has privilege to fix the SPN on the server.

To See the Log Files for this Tool:

By default, one log file is generated in the user’s application data folder.

To Get Help:
Option 1: Hover the mouse cursor over the command for tooltip.
Option 2: Run KerberosConfigMgr.exe –h from command line
Option 3: Click the Help button in the toolbar.

2.2 Troubleshoot Replication Error 8606, Event ID 1388, and Event ID 1988

These issues are caused by lingering objects. Lingering objects can be caused when a domain controller is taken offline for an extended period of time, does not replicate for longer than the tombstone lifetime, or is restored from a backup that is older than the tombstone lifetime.

When an object is deleted it is put in a tombstone state. After the tombstone lifetime passes (typically 180 days), DC run garbage collection and those tombstone objects are deleted. If a DC was offline for the entire TSL and then were brought back online they may have objects that have since been deleted, tombstoned, and garbage collected. Any objects that were deleted will still exist on that DC. These objects go unnoticed until a change is made to that object then the DC attempts to replicate that object, and at that point that is where it is either re-introduced into the environment or if strict replication consistency is enabled, blocked.

2.2.1 How to Determine TSL

Run the following command: dsquery * “cn=directory service,cn=windows nt,cn=services,cn=configuration,<Forest DN>” –scope base –attr tombstonelifetime

2.2.2.1 Repadmin /removelingeringobjects

One way to remove lingering objects is to user repadmin with the /removelingeringobjects switch. First you must identify a clean source of the partition. The syntax of the command is repadmin /removelingeringobjects <Dest DC Name> <Source DC Guid> <Naming Context>. So, in other words you need to identify the source DCs guid and the Naming Context you want to clean. The naming context will be available in the Event 1388 or 1988 you receive in the event long. Once you find a clean source you can obtain the guid by opening DNS Manager and opening up the _msdcs Zone and obtaining the CName record for the DC in question.

Below is an example of running the repadmin /removelingeringobjects command

You will receive an Event 1937 when the removal of lingering objects begins.

You will then receive an Event 1939 when removal completes.

2.2.2.2 Repadmin /rehost

An alternative to using repadmin /removelingeringobjects command is to unhost the partition so that the domain controller no longer has that partition and then rehosting the entire partition with a good source.

The repadmin syntax for unhosting the partition is repadmin /unhost <DC Name> <Partition Name>

You will receive an event an event 1658 when the removal begins.

You will receive an event 1660 when the removal completes

The syntax for rehosting the partition is: repadmin /rehost <Dest DC Name> <Partition> <Source DC Name>

Что такое делегирование AD

Само делегирование — это передача части разрешений и контроля от родительского объекта другой ответственной стороне.

Известно, что каждая организация имеет в своем штабе несколько системных администраторов. Разные задачи должны возлагаться на разные плечи. Для того чтобы применять изменения, необходимо обладать правами и разрешениями, которые делятся на стандартные и особые. Особые — применимы к определенному объекту, а стандартные представляют собой набор, состоящий из существующих разрешений, которые делают доступными или недоступными отдельные функции.

Установка доверительных отношений

В AD есть два вида доверительных отношений: «однонаправленные» и «двунаправленные». В первом случае один домен доверяет другому, но не наоборот, соответственно первый имеет доступ к ресурсам второго, а второй не имеет доступа. Во втором виде доверие “взаимное”. Также существуют «исходящие» и «входящие» отношения. В исходящих – первый домен доверяет второму, таким образом разрешая пользователям второго использовать ресурсы первого.

При установке следует провести такие процедуры:

Проверить сетевые связи между котроллерами.
Проверить настройки.
Настроить разрешения имен для внешних доменов.
Создать связь со стороны доверяющего домена.
Создать связь со стороны контроллера, к которому адресовано доверие.
Проверить созданные односторонние отношения.
Если возникает небходимость в установлении двусторонних отношений – произвести установку.

Описание

Для этого на контроллере домена необходимо проверить в редакторе реестра наличие ключа HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState . Если ключ имеет значение отличное от 3 (ELIMINATED) используется FRS

Состояния миграции отображены в таблице ниже

State	Transition Process for Job Responsibilities	Migration Process for SYSVOL Replication
Start (State 0)	Before deciding to retire or leave, the employee handles all of the responsibilities of the job.	Before SYSVOL migration begins, FRS replicates the SYSVOL shared folder.
Prepared (State 1)	The first employee continues working while the new employee shadows the first employee, learning how to perform the work. The new employee may become responsible for some minor tasks, but the first employee remains accountable for the primary responsibilities of the job.	FRS continues to replicate the SYSVOL shared folder that the domain uses, while DFS Replication replicates a copy of the SYSVOL folder. This copy of the SYSVOL folder is not used to service requests from other domain controllers.
Redirected (State 2)	The new employee takes over most of the responsibilities of the job, but the first employee remains to assist the new employee if needed.	The DFS Replication copy of the SYSVOL folder becomes responsible for servicing SYSVOL requests from other domain controllers. FRS continues to replicate the original SYSVOL folder, but DFS Replication now replicates the production SYSVOL folder that domain controllers in the Redirected state use.
Eliminated (State 3)	The first employee retires or leaves, and the new employee handles all of the responsibilities of the job.	DFS Replication continues to handle all the SYSVOL replication. Windows deletes the original SYSVOL folder, and FRS no longer replicates SYSVOL data.

Восстановление контроллера домена в режиме «non-authoritative»

Собираясь восстанавливать контроллер домена, необходимо сначала определить, будет ли достаточен режим «non-authoritative» или потребуется воспользоваться режимом «authoritative». Разница между этими двумя режимами заключается в том, что при режиме восстановлении «non-authoritative» контроллер домена понимает, что он был в течение некоторого времени отключен. Поэтому он позволяет другим контроллерам домена обновить его базу данных, внеся в нее последние изменения, произошедшие во время его отсутствия. При «authoritative» восстановлении контроллер считает, что только на нем имеется истинно верная база данных, поэтому именно он получает полномочия на обновление баз данных других контроллеров домена на основе своих данных.

В большинстве сценариев восстановления вам потребуется режим «non-authoritative», поскольку в среде имеется несколько контроллеров домена. Кроме того, «authoritative» восстановление контроллера домена может привести к новым проблемам. Именно на этом основана логика Veeam Backup & Replication: по умолчанию выполняется «non-authoritative» восстановление DC, поскольку считается, что инфраструктура выстроена с избыточностью и включает в себя несколько контроллеров домена. Чтобы выполнить «authoritative» восстановление с помощью Veeam, необходимо осуществить некоторые дополнительные действия, которые описаны ниже.

ПРИМЕЧАНИЕ. Еще один распространенный вариант действий при отказе контроллера домена — распределить его роли между другими контроллерами и очистить метаданные, если восстановление маловероятно. В этом случае вы поручаете другим DC выполнять функции отказавшего, и вам не нужно его восстанавливать.

Давайте вернемся к файлам резервных копий, которые были описаны в предыдущей статье. Восстановить контроллер домена из резервной копии Veeam Backup & Replication очень легко. Для этого нужно:

Выбрать мастер восстановления в пользовательском интерфейсе
Найти нужный контроллер домена
Выбрать в меню восстановления вариант восстановления ВМ целиком (Restore Entire VM)
Затем указать точку восстановления
Выбрать исходное или новое место восстановления
Завершить процедуру

Самое замечательное здесь, что благодаря обработке данных с учетом состояния приложений при создании резервной копии, вам больше ничего не потребуется делать. Veeam распознает контроллер домена в указанной ВМ и аккуратно восстановит его, используя особый алгоритм:

Восстановление файлов и жестких дисков ВМ
Загрузка ОС в специальном режиме восстановления доменных сервисов (DSRM mode)
Применение настроек
Перезапуск в обычном режиме

Контроллер домена будет знать о восстановлении из резервной копии и предпримет соответствующие действия: существующая база данных будет объявлена недействительной, и партнеры репликации смогут обновить ее, внеся наиболее свежую информацию.

Рис. 1. Veeam Backup & Replication: Восстановление ВМ целиком

Здесь можно прочитать о восстановлении «на голое железо» резервной копии с помощью Veeam Endpoint Backup. Вам потребуется заранее подготовленный аварийный загрузочный диск Veeam и доступ к самой резервной копии (на USB-носителе или сетевом диске). Помните, что в данном случае особая логика Veeam Backup & Replication использоваться не будет. После восстановления с помощью Veeam Endpoint Backup ваш контроллер домена загрузится в режиме восстановления. Вам нужно будет решить, хотите ли вы менять ключи реестра или сразу перезапустите ВМ в обычном режиме. Возможно, эта статья базы знаний будет полезна.

Рис. 2. Veeam Endpoint Backup: восстановление «на голое железо»

How can I fix the target principal name is incorrect – cannot generate SSPI context error?

1. Change SQL Service User

Try changing the SQL SERVICE user with the one that is Domain Admin. When you shut down the service, you need an account with privileges to create a new SPN (Service Principal Name).

When a service starts without it, it will trigger the error. Changing the privileges of your system account can fix the error.

However, it is always recommended for service accounts to give them the least privileges due to security reasons.

Remove the SPN entries from AD Users and Computers

Open the Active Directory User and Computers in Advanced View.
Look for the SSPN entries for MSSQL Svc.
Remove all the entries associated with MSSQL Svc.
Close AD User and Computers and check for any improvements.
Change Active Directory permission.

2. Check your password

The error cannot generate SSPI context can occur due to password issues. If you had recently changed your password, but haven’t logged out of your account, it can trigger the error.

Try logging out and then signing in with the new password to fix the error.

In other instances, the issue could be due to password expiration. Change the expired password and login with the new credentials to see if that resolves the error.

3. Change Active Directory permission

Run Adsiedit.msc and from the Run dialog box.
In the Active Directory Service window, expandDomain , then expand DC = RootDomainName, and then CN = Users.
Right-click on CN= and select Properties.
Open the Security tab.
Click on Advanced option.
Select any one of the SELF rows.
Click Edit and then the Open Permission Entry window.
Here, make sure the Principal is set to SELF, Type is set to Allow, and Applied to is set to This Object Only.
In the Properties section, select the following.Read servicePrincipalNameWrite servicePrincipalName
Click OK to apply the changes and exit.

Try establishing a new connection and check if they cannot generate SSPI context error is resolved. Make sure you restart the SQL Services that are associated with the current account to apply the changes.

Changing the Active Directory permission is a safe option than changing the SQL server user. However, before you proceed to change the permission, make sure the problem is triggered due to permission issues.

Log in to the server where your SQL instance is running and then check the error logs to check if the error is triggered due to permission problems.

The error in the log will look something like this:

The error cannot generate SSPI context can occur due to permission as well as expired credentials issues. Changing the password and permission should help you fix the error and log back into your SQL server.

Still having issues? Fix them with this tool:

Доверчивый

Чтобы разрешить пользователям в одном домене получать доступ к ресурсам в другом, Active Directory использует доверительные отношения.

Доверительные отношения внутри леса создаются автоматически при создании доменов. Лес устанавливает границы доверия по умолчанию, а неявное транзитивное доверие является автоматическим для всех доменов в лесу.

Терминология

Одностороннее доверие: Один домен разрешает доступ пользователям в другом домене, но другой домен не разрешает доступ пользователям в первом домене.
Двустороннее доверие: Два домена разрешают доступ пользователям в обоих доменах.
Надежный домен: Домен, которому доверяют; чьи пользователи имеют доступ к доверяющему домену.
Переходное доверие: Доверие, которое может распространяться за пределы двух доменов на другие доверенные домены в лесу.
Непереходное доверие: Одностороннее доверие, не выходящее за пределы двух доменов.
Явное доверие: Доверие, которое создает администратор. Это не транзитивно и только в одну сторону.
Перекрестное доверие: Явное доверие между доменами в разных деревьях или в одном дереве, когда отношения потомок / предок (дочерний / родительский) не существуют между двумя доменами.
Ярлык: Объединяет два домена в разных деревьях, транзитивный, одно- или двусторонний.
Лесной трест: Относится ко всему лесу. Переходный, одно- или двусторонний.
Область: Может быть транзитивным или нетранзитивным (непереходным), одно- или двусторонним.
Внешний: Подключитесь к другим лесам или доменам, не относящимся к AD. Нетранзитивный, одно- или двусторонний.
PAM доверие: Одностороннее доверие, используемое Microsoft Identity Manager из (возможно, низкоуровневого) производственного леса в «бастионный» лес (уровень функциональности Windows Server 2016 ), которое выдает ограниченное по времени членство в группах.

Немного теории

Непосредственно перед началом процесса установки разберем небольшой кусок теории.

Доменные службы Active Directory – это широко используемая технология для централизации хранения и управления учетными записями пользователей, нахождении ресурсов в сети предприятия, а также реализация механизма Single Sign-On (SSO) от компании Microsoft. В основе доменных служб Active Directory лежит реализация протокола LDAP. Грубо говоря Active Directory Domain Services – это реализация протокола LDAP от компании Microsoft.

По механизму и тонкостям работы Active Directory написаны отдельные книги. И даже кратко изложить основные момент – дело не простое. Однако, для понимания общей концепции в контексте установки контроллера домена необходимо ознакомится со следующими основными понятиями:

Схема Active Directory. Нечто мифическое, которое обвешано кучей тайн и не редко вызывает трепещущий страх и ужас при сочетании слов “нужно выполнить обновление схемы” А если серьезно, то это описание шаблонов всех возможных объектов в Active Directory – пользователей, компьютеров, принтеров и т.д. Содержит информацию о том, какие свойства есть у объектов и какие они могут иметь типы значений и непосредственно значения.
Лес Active Directory. Это совокупность всех доменов, которые объединены общей конфигурацией схемы объектов Active Directory. Лес содержит как минимум один домен. Такие тяжелые продукты, как, например Microsoft Exchange или Skype for Business могут быть установлены только одни в пределах всего леса, т.к. он вносит необходимые ему изменения в схему Active Directory. Установить рядом еще один независимый экземпляр этих продуктов не получится.
Домен. Граница, в пределах которой осуществляется управление настройками безопасности. Например, у вас есть два домена. В каждом из них администратор может управлять своим набором учетных записей пользователей, компьютеров, параметров безопасности и политики. Администратор Домена А не может управлять объектами в Домене Б (если не настроено необходимое делегирование).
Дерево доменов. Совокупность всех доменов в пределах леса.
Пространство имен. В передлах леса у вас может быть несколько имен. Например, один домен называется itproblog.ru, второй домен называется sale.itproblog.ru. В таком случае пространство имен продолженное (continuous). В тоже время у вас может быть еще один домен в том же лесу, например, hmmail.ru. Как видите – имя у него совершенно другое. Однако, это нисколько не мешает ему находится в том же лесу, что и домен с именем itproblog.ru.

Примеры топологий Active Directory

Рассмотрим немного примеров.

Ниже изображена схема одной из наиболее распространенной и простой топологии – один лес и один домен

Важно понимать, что в одном домене может быть установлено несколько контроллеров домена (для отказоустойчивости). Именно этот сценарий мы рассмотрен в данной статье

Пример схемы:

Следующей по уровню сложности следует топологи с несколькими доменами в одном лесу. Причем домены находятся в одном пространстве имен. Скажем, itproblog.ru. В каждом из доменов можем быть от одного до нескольких контроллером домена. Пример схемы:

Одна из наиболее комплексных топологий – это несколько доменов в одном лесу. Причем, не все домены используют одно пространство имен. Пример такой схемы ниже:

Домены в разных лесах Active Directory никак не заимосвязаны друг с другом (без установки дополнительных доверительных отношений). Домены в пределах одного леса автоматически доверяют друг другу, т.е. пользователям из Домена А могут быть назначены разрешения в домене Б. Пример схемы с несколькими отдельными лесами ниже:

Исключить проблему регистрации не удалось

Если сам участник домена устанавливается или проблема сети, она не будет зарегистрирована в DNS-сервере.

Если хост компьютера участника правильно зарегистрирован в IP-долларе в DNS-сервере, вы можете запускать IPConfig / Registerdns на этом компьютере для вручную зарегистрироваться. После завершения, DNS-сервер проверяет, есть ли правильная запись, такая как Server1.contoso.com, IP-адрес 192.168.100.13, настаивает на том, есть ли область Contoso.com, соответствующими записи и IP.

Если контроллер домена не регистрирует роль на DNS-сервере, она не является папкой и записью _tcp, перезапустите сервис NetLogon на сервере.

Создайте больше контроллеров домена

Если в домене есть несколько контроллеров домена, вы можете иметь следующие преимущества.

Улучшите эффективность входа пользователя: Если есть несколько контроллеров домена для предоставления услугам клиентам, вы можете поделиться бремя на пользователях входа в идентификацию (учетную запись и пароль), чтобы эффективность входа в систему пользователя лучше.
Беда: если есть контроллер домена, не удается, могут быть другие обычные контроллеры домена, чтобы продолжить предоставление доменных серверов.
Его можно настроить, чтобы быть избыточным, одним из которых не нужно переключаться, по-прежнему поддерживать обычный сервис.

1. Сначала измените имя, измените IP, настройте DNS, чтобы указать на первый контроллер области: 192.168.100.11 после подтверждения пропускания Ping.

2. Во второй серверной системе откройте свойства компьютера, измените компьютер с именем DC2, присоединяйтесь к домену как Contoso.com, DNS Suffix — Contoso.com, как показано на рисунке; затем всплывает учетные данные авторизации домена в контроле домена в управлении доменом Домен контролирует номер учетной записи и пароль устройства и определяет, затем перезагрузите, завершение домена. Обратитесь к рисунке ниже:

3. Установите службу домена Active Directory и роли DNS-сервера в соответствии с первым контроллером домена.

4. В теге конфигурации развертывания «Мастер конфигурации домена Active Directory» выберите увеличение контроллеров домена к существующему домену, заполните доменное имя contoso.com, предоставьте это действие ABC \ Administrator (пароль учетной записи администратора домена как учетные данные) Далее обратитесь к ссылке.

5. В вкладке «Опция« Контроллер домена »мастера конфигурации доменных служб Active Directory имеет флажок« Глобальный каталог GC », выберите имя сайта Contoso (сайт домена требуется, чтобы запросить выбор), введите пароль восстановления DSRM (пароль новый Настройки), затем выберите следующий шаг, обратитесь к рисунку.

6. Вкладка «Опция DNS» Мастер конфигурации доменных служб Active Directory на вкладке «Просмотр», следующий шаг по умолчанию, на предварительной проверке, проверьте проверку, вы можете выбрать установку, как карту; перезапустите DC2 после завершения.

7, затем переключитесь в DC1, откройте DNS-сервер, нажмите правой кнопкой мыши на площади contoso.com, измените контроллер домена и интеграцию DNS и применить, см.

8. В регулярной теге измените, как копировать данные зоны, на все DNS-серверы в этом домене, динамически обновляйте, чтобы быть в безопасности, см. Рисунок ниже.

9. На атрибуте области contoso.com в DNS-сервере на dc1 в теге сервера имени добавьте dc2 в качестве сервера имени, введите DC2 IP и полностью квалифицированный домен DC2.contoso.com в всплывающем окне. ИНЖИР.

10. Переключитесь на DC2, повторите вышеуказанный шаг (имя сервера и полностью квалифицированное доменное имя), после завершения обновления, увидим то же Contoso.com в качестве DNS-сервера на DC1.

11, проверка

Откройте пользователи Active Directory и компьютеры на DC2, он обнаружит, что контент и DC1 полностью согласуются, вы можете видеть, что DC1, DC2, типы в контроллере домена, являются глобальным каталогом GC, указывая, что два контроллера домена равны друг другу. ( Не забудьте указать на 192.168.100.11 и 192.168.100.12 в домене в домене, чтобы при отсутствии определенного контроллера зоны не повлияет, это не повлияет на нормальное использование домена).

Признак

Обычно только контроллеры домена чтения (RODCs) реплицируются только для пользовательских учетных записей, которые являются членами группы репликации паролей RODC или перечислены в атрибуте msDS-RevealOnDemandGroup учетной записи RODC.

Однако для некоторых учетных записей пользователей, которые не являются членами группы репликации паролей с разрешенным кодом RODC или не указаны в атрибуте msDS-RevealOnDemandGroup учетной записи RODC, можно обнаружить, что пароли для этих учетных записей, которые являются аутентификацией RODC, могут быть кэшированы в RODC.

Например, при сравнении вывода свойства Advanced Replication Policy для репликации паролей с помощью пользователей и компьютеров Active Directory и выходных данных указанные записи отличаются друг от друга.

Описание ситуации

И так у меня есть лес и 3 домена Active Directory, развитая сеть сайтов AD. Утром в систему мониторинга поступило уведомление, что появились проблемы с репликацией между контроллерами домена, при выводе команды repadmin /replsummary, я увидел ряд ошибок:

(8524) The DSA operation is unable to proceed because of a DNS lookup failure
(1722) The RPC server is unavailable.

Если с ошибкой «(1722) The RPC server is unavailable.» я сталкивался и ее успешно решал, то вот «(8524) The DSA operation is unable to proceed because of a DNS lookup failure» я видел впервые.

Также я вам советую сразу запустить массовую диагностику и выгрузить весь результат в текстовые файлы, для этого создайте bat-файл вот с таким содержанием:

@echo off chcp 855 repadmin /replsummary > c:\temp\replsummary.log repadmin /syncall > c:\temp\syncall.txt repadmin /Queue > c:\temp\Queue.txt repadmin /istg * /verbose > c:\temp\istg.txt repadmin /bridgeheads * /verbose > c:\temp\bridgeheads.txt repadmin /syncall /APed > c:\temp\APed.txt dcdiag /a /q > c:\temp\dcdiag.txt

repadmin /showrepl > c:\temp\showrepl.txt

Например я также через showrepl вижу ошибку:

Last attempt @ 2022-09-23 09:09:37 failed, result 1722 (0x6ba):

Как исправить ошибку репликации (8524)

Первое, что вы должны выполнить, это убедиться:

Что ваши контроллеры домена доступны по сети, вы точно должны увидеть, что порты по которым работает активный каталог, нормально доступны с контроллеров домена на которых нет проблем

Самое важное, чтобы все DNS-имена нормально резолвелись. Очень часто работающие контроллеры ссылаются на состояние 8524, если контроллер домена Active Directory не может разрешить удаленный DC с помощью полностью CNAME-записи.
Для проверки портов я советую использовать утилиту Telnet или PowerShell
100% быть уверенным, что на сбойном контроллере нет ошибки и состояния (1722) The RPC server is unavailable
Если с портами и доступностью все хорошо, и все контроллеры друг друга видят без ошибок, то попробуйте выполнить принудительную реплику по всем контроллерам через команду (Лучше это делать сначала на любом рабочем DC, потом можно на сбойном или имеющем ошибки):

repadmin /syncall /APed

Данная команда выполнятся может долго, зависит от количества сайтов и контроллеров домена.

Проверьте правильность настройки ваших сайтов Active Directory, нет ли там устаревших связей, или сайтов которых уже нет, в которых могут быть уже выведенные контроллеры домена. Если такие присутствуют, то удалите сайт и такие объекты. На проблемы с сайтами может указывать ошибка с ID 8524, чтобы решить эту проблему, запустите сайты и службы Active Directory (dssite.msc). Затем перейдите в раздел «Серверы», выберите удаленный контроллер домена — Настройки NTDS и удалите подключения, удалите настройки NTDS, удалите от туда контроллер домена
Обязательно проверьте в просмотре событий журналы «СИСТЕМА», «Active Directory Web Services», «DFS Replication», «Directory Service», «DNS Server» наличие альтернативных ошибок, которые вам могут, что-то подсказать, куда дальше копать.

Тут вы можете обнаружить ряд событий, которые будут причиной ошибки репликации «(8524) The DSA operation is unable to proceed because of a DNS lookup failure»:

1. ID 1926 — Попытка установить ссылку репликации на раздел каталога только для чтения со следующими параметрами не удалась
2. ID 1925 — Попытка установить ссылку на репликацию для следующего раздела каталога writable не удалась.
3. ID 1865 — KCC не смог сформировать полную топологию сети деревьев. В результате, следующий список сайтов не может быть достигнут с локального сайта
4. ID 1308 — KCC обнаружил, что последовательные попытки реплицироваться со следующей службой каталогов последовательно сбой.
5. ID 1655 — Active Directory попытался связаться со следующим глобальным каталогом, и попытки оказались безуспешными
6. ID 2023 — Этот сервер каталогов не смог реплицировать изменения на следующий удаленный сервер каталога для следующего раздела каталога

Если сбойный контроллер домена уже не будет в сети и просто не может работать, то нужно его полностью удалить с очисткой метаданных.
Можете еще попробовать поискать дополнительные подсказки через инструмент Active Directory Replication Status Tool

После того, как сбойный контроллер домена был введен в боевое состояние, проверены нужные пункты из указанных выше, реплика восстановилась. Об этом стало говорить уменьшающееся количество ошибок при попытке реплики.

Надеюсь, что смог чем-то помочь, с вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.