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

Недавно я был в среде, где было 120 контроллеров домена на более чем 100 сайтах по всему миру. Этот домен возник в эпоху Windows 2000 и со временем обновлялся, поэтому строгая согласованность репликации никогда не была установлена ​​по умолчанию для новых контроллеров домена и никогда не включалась ни на одном контроллере домена. В каталоге есть устаревшие объекты, и вы регулярно видите приличное количество конфликтующих объектов из-за этого.

Использование repadmin /removelingeringobjectsтребует знания двух вещей:

1. Какие DC имеют объекты в базе данных

2. DC, на котором нет отложенных объектов для использования в качестве эталонного DC.

Очевидно, что в будущем эта среда должна быть настроена таким образом, чтобы все новые контроллеры домена имели строгую согласованность репликации и repadmin /options * +strictзапускались для того, чтобы все текущие контроллеры домена использовали строгую согласованность репликации, но теперь это нарушит репликацию без очистки объектов .

Итак, мой вопрос заключается в следующем: в такой масштабной среде, где я бы не знал, какие контроллеры домена имеют вялые объекты, а какие нет, как я могу определить хороший эталонный DC для repadmin /removelingeringobjectsиспользования и как я могу гарантировать, что все 120+ Контроллеры домена очищаются от устаревших объектов, прежде чем применять строгую согласованность репликации и нарушать репликацию? Или просто включить строгий режим и посмотреть, repadmin /replsumчто ломается и с этим бороться?

Это займет некоторое время, чтобы исправить.

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

repadmin /options +DISABLE_OUTBOUND_REPL

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

Repadmin определяет, что это длительный объект, если этот объект существует на ServerA, но не на ServerB, где ServerB является эталонным 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 говорит: «Подождите, что? У меня даже нет объекта A вообще. Отправьте мне весь объект!» Если нет строгой последовательности. При строгой согласованности ServerA говорит: «Подождите, что? Как вы ожидаете, что я обновлю объект, который не существует?

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

repadmin /removelingeringobjects ServerName ServerGUID DirectoryPartition /advisory_mode 

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

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

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

Это повторно синхронизирует тот раздел каталога каждого GC в лесу с известным хорошим источником, который нужно указать в качестве 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проверяет наличие каких-либо дополнительных объектов.