Как правильно удалить устаревшие объекты, если -strict уже долгое время установлен на большом количестве контроллеров домена?

Чтобы это исправить, потребуется время.

Чтобы остановить всю репликацию, запустите:

repadmin /options +DISABLE_OUTBOUND_REPL

На всех РЦ. Помните, что указанный выше параметр не предотвращает ручные действия по репликации, такие как запуск администратора (вы) repadmin /syncall /APedи т. д. Но это хорошо, потому что это позволяет вам полностью восстановить синхронизацию всех контроллеров домена, прежде чем повторно включить регулярную репликацию.

Repadmin определяет, что это устаревший объект, если объект существует на ServerA, но не на ServerB, где ServerB - это ссылочный контроллер домена. Разница между репликацией вновь созданных объектов и репликацией обновлений к уже существующим объектам является ключевым. Воспроизведение вновь созданных объектов = хорошо. Репликация обновлений на уже существующие объекты = хорошо. Репликация обновлений на объекты, которые не существуют на конечном DC = bad.

Вам нужно только вспенить, промыть, повторять, пока все DC не совпадут с вашим единственным хорошим эталонным DC. Затем включите везде строгую согласованность, а затем снова включите репликацию. Да, вы рискуете удалить допустимые объекты, созданные на других удаленных контроллерах домена, которые не были реплицированы на ваш ссылочный контроллер домена.

От великого "Как работает модель репликации Active Directory" статья:

Настройка согласованности репликации

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

Параметр реестра на контроллерах домена под управлением Windows Server 2003 или Windows 2000 Server с пакетом обновления 3 (SP3) предоставляет значение согласованности, которое определяет, реплицирует ли контроллер домена и реанимирует обновленный объект, который был удален из всех других реплик, или репликация таких объектов заблокирован. Параметры по умолчанию отличаются для контроллеров домена, работающих под управлением Windows 2000 Server с пакетом обновления 3 (SP3) и Windows Server 2003.

Строгая согласованность репликации

Чтобы избежать проблем с реанимированием удаленных объектов, контроллер домена, работающий под управлением Windows Server 2003 во вновь созданном (не обновленном) лесу Windows Server 2003, по умолчанию блокирует входящую репликацию при получении обновления для объекта, которого у него нет. .

Примечание • Репликация Active Directory использует отслеживание обновлений, чтобы различать репликацию вновь созданного объекта и обновление атрибута для существующего объекта. Репликация устаревшего объекта - это попытка обновить атрибут или атрибуты объекта, которые целевой контроллер домена не может обновить, поскольку объект не существует.

Репликация останавливается в разделе каталога для объекта до тех пор, пока устаревший объект не будет удален с исходного контроллера домена или не будет отключен параметр строгой согласованности репликации.

Когда ServerB говорит ServerA: «Привет, в существующий объектA были внесены некоторые обновления». Затем ServerA говорит: «Подождите, что? У меня вообще нет objectA. Пришлите мне весь объект!» Если нет строгой согласованности. В случае строгой согласованности ServerA говорит: «Что подождите? Как вы ожидаете, что я обновлю несуществующий объект?

Чтобы узнать, есть ли у вас устаревшие объекты на контроллере домена:

repadmin /removelingeringobjects ServerName ServerGUID DirectoryPartition /advisory_mode 

ServerGUID - это известный хороший эталонный DC. Я знаю, что вы это уже знаете ... и как создать скрипт для выполнения этой строки на всех контроллерах домена ... (foreach ($DC In $(Get-ADDomain).ReplicaDirectoryServers) { }) ...

Вам нужен хороший источник постоянного тока, чтобы сравнивать его, в конечном итоге. Если у вас нет известного хорошего источника постоянного тока или вы не знаете, вам просто нужно выбрать его. Конечно, это должен быть GC с возможностью записи. Это относительно - если все контроллеры домена согласны с существованием объекта и его атрибутов ... тогда это не устаревший объект.

foreach($GC In $(Get-ADForest).GlobalCatalogs) { repadmin /removelingeringobjects $_.name 85d158d2-a006-4fff-b1e5-f9b6eaabab2b '$directoryPartition'

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

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

Редактировать: это это партийная линия Microsoft по этому вопросу, и то, что они, вероятно, расскажут вам, если вы им позвоните.

Наконец, исправить это может быть больше проблем, чем того стоит, если только это не вызывает у вас проблем. Ненавижу это говорить, но AD все еще может нормально функционировать с устаревшими в нем объектами.

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

for each $sourceDC in $allDCs
    for each $targetDC in $allDCs
        if ($targetDC <> $sourceDC) then
            run repadmin with $sourceDC and $targetDC
        end if
    next
next

Этот процесс описан здесь: http://blogs.technet.com/b/glennl/archive/2007/07/26/clean-that-active-directory-forest-of-lingering-objects.aspx

Однако взгляните на ReplDiag. Он автоматизирует процесс, запустив repadmin за вас против всех комбинаций исходных и целевых DC. Затем следует /advisory_only чтобы проверить наличие каких-либо других устаревших объектов.