none
Репликации мешает захороненный объект RRS feed

  • Вопрос

  • Ситуация. У нас есть дочерний домен с одним контроллером. У нас два контроллера. Наши два контроллеры -не единственные в лесу. В большой организации лес с пустым корнем (DC=rbrcompany,DC=com)и куча доменов. Наш Triuph.rbccompany.com , дочерний rc. triuph.rbccompany.com. Все контроллеры w2k3 sp2 еще.

    В общем, сегодня возникли проблемы с добавлением прав юзеру из дочернего домена.

    При попытке репликации через dssite-ошибочка «Задано недостаточно атрибутов для создания объекта.  Этот объект не может существовать, поскольку он был удален и собран в качестве мусора». Начали разбираться- оказывается 2 месяца назад они откатили единственный контроллер acronis. Но тогда репликация работала, по их словам и логу(прекратилась неделю назад)

    Вот с моего контроллера вывод dcdiag

       Testing server: Triuph\Triuph-DC01

          Starting test: Replications

             [Replications Check,TRIUPH-DC01] A recent replication attempt failed:

                From RC-DC01 to TRIUPH-DC01

                Naming Context: DC=RC,DC=Triuph,DC=rbrcompany,DC=com

                The replication generated an error (8606):

                Задано недостаточно атрибутов для создания объекта.  Этот объект не

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

                The failure occurred at 2015-03-05 19:13:02.

                The last success occurred at 2015-02-24 07:57:42.

                14386 failures have occurred since the last success.

             REPLICATION-RECEIVED LATENCY WARNING

             TRIUPH-DC01:  Current time is 2015-03-05 19:13:21.

                DC=RC,DC=Triuph,DC=rbrcompany,DC=com

                   Last replication recieved from RC-DC01 at 2015-02-24 07:56:

    В логах видно, что есть один захороненный объект

    Репликация Active Directory обнаружила существующие объекты в следующем разделе, который был удален с локальных контроллеров домена (DC) базы данных Active Directory. Не все прямые или транзитивные партнеры репликации провели репликацию с удалением до того, как прошло количество дней, заданное как время жизни захоронения.  Объекты, которые были удалены и для которых выполнена операция сбора мусора в разделе Active Directory, но которые продолжают существовать в доступных для записи разделах других контроллеров домена в том же домене, или в доступных только для чтения разделах серверов глобального каталога в других доменах этого леса, называются "призрачными" объектами. Это событие записано в журнал, поскольку исходный контроллер домена содержит призрачный объект, который не существует в локальной копии базы данных Active Directory контроллера домена. Эта попытка репликации была заблокирована.  

     Лучший способ устранения этой проблемы - это поиск и удаление всех призрачных объектов в этом лесе.

    Исходный DC (сетевой адрес для данного транспорта):

    a54ae5e9-7bda-4fb4-8546-aca85172d255._msdcs.rbrcompany.com

    Объект:

    CN=LIMAN-KSR,OU=Computers RC,DC=RC,DC=Triuph,DC=rbrcompany,DC=com

    GUID объекта:

    e6ac0aa5-3a34-483e-9784-0dfcd615d131

     

     и дана рекомендация

    выполнить

    repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC> /advisory mode

    изатембезAdvisory mode

    Вопрос 1) на каком контроллере это выполнять? На моем(одном, двух) или дочернем

    Вопрос2) не пойму по синтаксису 

    repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC>

    Дочерний домен: DC=RC,DC=Triuph,DC=rbrcompany,DC=com, контроллер называется RC-DC01

    Мой домен : DC=Triuph,DC=rbrcompany,DC=com, контроллеры называются TRIUPH-DC01, TRIUPH-DC02

    GUID дочернего a57ae5e8-7bda-4fb4-8546-aca85172d255

    Моих a59ae5a7-7bda-4fb4-8546-aca85172d254 и a23ae4a6-7bda-4fb4-8546-aca85172d226(например)

    Как правильно записать команду-это второй вопрос и где ее выполнять?

    Вопрос 3. Если захороненный обект только один-поможет ли?

    Вопрос 4. Я так понимаю, что если я сделаю нижеследующую настройку в реестре, то проблемы будут у меня при репликации с другими доменами

    To edit the registry to enable strict replication consistency
    1. Open a registry editor.

    2. Navigate to Strict Replication Consistency entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.

    3. Set the value in the Strict Replication Consistency entry to 0


    5 марта 2015 г. 17:37

Ответы

  • Значит так. После отката КД, восстановленного из образа диска, возникает USN Rollback (повторное использование уникальных последовательных номеров обновлений). Если в момент запуска никакой другой КД в лесу не был доступен, то AD может это состояние и не обнаружить.

    Приводит это к тому, что часть обновлений не была и никогда не будет передана из этого домена (если интересует - покажу статью в MS KB, где это разъяснено). Видимо, создание учетной записи компьютера, вызвавшего проблему пришлось как раз на этот потерянный промежуток.

    Что делать вам? В таком случае нужно не удалять объект через repadmin /removelingeringobjects (а удалять его, вообще говоря, надо на их КД, а не на вашем), а просто заново переразместить их раздел домена в вашем глобальном каталоге (и это, вообще-то, надо проделать во всех глобальных каталогах в лесу за пределами их домена , а не только в вашем домене).

    Это делается несколько другими командами (записано для того конкретного КД, на котором возникла проблема):

    repadmin /unhost TRIUPH-DC01.Triuph.rbrcompany.com "DC=RC,DC=Triuph,DC=rbrcompany,DC=com"
    
    repadmin /rehost TRIUPH-DC01.Triuph.rbrcompany.com "DC=RC,DC=Triuph,DC=rbrcompany,DC=com" RC-DC01.RC.Triuph.rbrcompany.com
    

    Подробнее про эти ключи команды repadmin можно посмотреть в справочной системе, Technet Library или же в этой статье в блогах MS

    PS Если интересно по синтаксису repadmin /removelingeringobjects то можно обсудить отдельно.

    PPS Интересно, в вашей большой организации за единый, вообще говоря, лес AD кто-нибудь отвечает? Если да, поставьте его в известность об этом инциденте. И про Acronis не забудьте, чтобы граждане, не умеющие обращаться с контроллерами домена получили своё причитающееся.


    Слава России!


    • Изменено M.V.V. _ 5 марта 2015 г. 18:24
    • Помечено в качестве ответа PVDPVDPVD 5 марта 2015 г. 19:22
    5 марта 2015 г. 18:21

Все ответы

  • Значит так. После отката КД, восстановленного из образа диска, возникает USN Rollback (повторное использование уникальных последовательных номеров обновлений). Если в момент запуска никакой другой КД в лесу не был доступен, то AD может это состояние и не обнаружить.

    Приводит это к тому, что часть обновлений не была и никогда не будет передана из этого домена (если интересует - покажу статью в MS KB, где это разъяснено). Видимо, создание учетной записи компьютера, вызвавшего проблему пришлось как раз на этот потерянный промежуток.

    Что делать вам? В таком случае нужно не удалять объект через repadmin /removelingeringobjects (а удалять его, вообще говоря, надо на их КД, а не на вашем), а просто заново переразместить их раздел домена в вашем глобальном каталоге (и это, вообще-то, надо проделать во всех глобальных каталогах в лесу за пределами их домена , а не только в вашем домене).

    Это делается несколько другими командами (записано для того конкретного КД, на котором возникла проблема):

    repadmin /unhost TRIUPH-DC01.Triuph.rbrcompany.com "DC=RC,DC=Triuph,DC=rbrcompany,DC=com"
    
    repadmin /rehost TRIUPH-DC01.Triuph.rbrcompany.com "DC=RC,DC=Triuph,DC=rbrcompany,DC=com" RC-DC01.RC.Triuph.rbrcompany.com
    

    Подробнее про эти ключи команды repadmin можно посмотреть в справочной системе, Technet Library или же в этой статье в блогах MS

    PS Если интересно по синтаксису repadmin /removelingeringobjects то можно обсудить отдельно.

    PPS Интересно, в вашей большой организации за единый, вообще говоря, лес AD кто-нибудь отвечает? Если да, поставьте его в известность об этом инциденте. И про Acronis не забудьте, чтобы граждане, не умеющие обращаться с контроллерами домена получили своё причитающееся.


    Слава России!


    • Изменено M.V.V. _ 5 марта 2015 г. 18:24
    • Помечено в качестве ответа PVDPVDPVD 5 марта 2015 г. 19:22
    5 марта 2015 г. 18:21
  • Я понял. 

    Очень интересно обсудить  "Если интересно по синтаксису repadmin /removelingeringobjects"

    Итак, операцию по удалению repadmin /removelingeringobjects выполняем на их контроллере.

    Повторю условия 

    repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC>

    Дочерний доменDC=RC,DC=Triuph,DC=rbrcompany,DC=com, контроллер называется RC-DC01

    Мой домен : DC=Triuph,DC=rbrcompany,DC=com, контроллеры называются TRIUPH-DC01, TRIUPH-DC02

    GUID дочернего a57ae5e8-7bda-4fb4-8546-aca85172d255

    Моих a59ae5a7-7bda-4fb4-8546-aca85172d254 и a23ae4a6-7bda-4fb4-8546-aca85172d226(например)

    Так как надо писать правильно(у меня ведь два контроллера и оба глобальные каталоги)

    На их контроллере даем команду

    repadmin /removelingeringobjects а вот что ставить как source DC-один из родительских контроллеров?

    Чей destination DC GUID? И что писать как  <NC>

    Укажите пожалуйста правильный синтаксис, я запутался

    Кроме этого, в приводимом вами примере(с unhoct и rehost непонятно также с синтаксисом. 

    Вы пишете,  (записано для того конкретного КД, на котором возникла проблема):

    repadmin /unhost TRIUPH-DC01.Triuph.rbrcompany.com "DC=RC,DC=Triuph,DC=rbrcompany,DC=com"
    
    repadmin /rehost TRIUPH-DC01.Triuph.rbrcompany.com "DC=RC,DC=Triuph,DC=rbrcompany,DC=com" RC-DC01.RC.Triuph.rbrcompany.com

    Но проблема то вроде на дочернем(fqdn RC-dc01.triuph.rbrcompany.com), а не родительском (fqdn Triuph-dc01.triuph.rbrcompany.com)

     как все же правильно писать

    и для repadmin /removelingeringobjects и для unhost/rehost.



    • Изменено PVDPVDPVD 6 марта 2015 г. 7:22
    5 марта 2015 г. 19:03
  • Команды написаны правильно.

    Текст события несколько дезориентирует. Проблема у вас - в глобальном каталоге на вашем КД: он получил не все обновления от контроллера домена, на котором находится единственная полная копия раздела домена. Поэтому частичную копию этого раздела лучше всего обновить полностью - что и делают указанные команды.

    Вот что произошло. Обновления, возникшие при создании объекта CN=LIMAN-KSR,OU=Computers RC,DC=RC,DC=Triuph,DC=rbrcompany,DC=com, ваш КД не получил - соответствующие им номера USN оказались меньше номера последнего принятого им (до восстановления из образа диска) обновления, поэтому он их не запрашивал. А номера оказались меньше из-за того, что текущий USN на образе диска, от которого начали отсчитываться USN последующих обновлений, был меньшим, чем этот последний принятый USN. Некоторая часть реально произведенных на восстановленном КД обновлений - с USN в диапазоне между этим текущим USN и последним принятым на вашем КД USN - вашим КД не запрашивались (так устроена репликация). А получил ваш КД только какое-то последующее обновление, когда  была обновлена лишь часть атрибутов проблемного объекта, и получил он только значения этих атрибутов - а потому, не имея всех обязательных атрибутов, создать этот объект в разделе глобального каталога он не может. В базе знаний MS про всё это можно прочитать здесь, в статье, посвященной Windows 2000, в которой исходно не было механизма обнаружения USN Rollback.

    Кроме перезагрузки раздела глобального каталога, в принципе, существуют ещё два способа решить эту проблему:

    1. Удалить объект с помощью repadmin /removelinegringobjects . В этом случае КД-источником должен был бы быть ваш КД TRIUPH-DC01.Triuph.rbrcompany.com, а GUID целевого КД - это GUID КД дочернего домена, a57ae5e8-7bda-4fb4-8546-aca85172d255. Я, однако, не уверен, что эта команда пройдёт - вобще-то раздел домена из частичной копии на GC в полную копию на контроллере домена в норме не реплицируется. Кроме того, в вашем случае есть риск удалить таким образом вполне работоспособную учётную запись компьютера.

    2. Если объект не удалён - "продёрнуть" номера USN в метаданных всех его атрибутов, чтобы при последующей репликации были переданы они все сразу, сделать это можно командой ntdsutil->authoritative restore->restore object либо обновив вручную каждый атрибут объекта. Я этот вариант решения проблемы не рекомендую, потому что он более трудоёмок - а такой объект может быть далеко не один.

    PS Официальное описание (на мой взгляд - не совсем полное), как бороться с этой ошибкой, есть в Technet Library .

    PPS Что на самом деле имеет смысл - это проверить с помощью repadmin /removelinegringobjects /advisory_mode разделы конфигурации и ForestDNSZones - в них тоже могли быть созданы на КД дочернего домена объекты, которые не были реплицированы из-за USN Rollback. Если такие объекты обнаружатся, то надо с каждым из них разбираться отдельно по методике, изложенной в указанной выше статье в Technet Library. Но это, вообще-то - головная боль админа, отвечающего за весь лес.


    Слава России!




    • Изменено M.V.V. _ 5 марта 2015 г. 22:03
    5 марта 2015 г. 21:57
  • Спасибо! 

    Подытоживая рутинную часть

    По первому варианту-синтаксис такой:

    repadmin /removelingeringobjects TRIUPH-DC01(мой КД)  a57ae5e8-7bda-4fb4-8546-aca85172d255(GUID дочернего) DC=RC,DC=Triuph,DC=rbrcompany,DC=com или же

    в качестве <NC> писать CN=Configuration,DC=rbrcompany,DC=com

    @@@@@@@@@@@@@@@@@@@@@

    А по второму случаю-вообще непонятно

    Так должно быть

    1. Command: repadmin /unhost <dc-name> <partition-name>

    2. Command: repadmin /rehost <dc-name> <partition to rehost> <good-source-dc>

    Вы даете пример

    1)repadmin /unhost TRIUPH-DC01.Triuph.rbrcompany.com(мой контроллер) "DC=RC,DC=Triuph,DC=rbrcompany,DC=com"(дочерняя партиция)

    2) repadmin /rehost TRIUPH-DC01.Triuph.rbrcompany.com(мой контроллер) "DC=RC,DC=Triuph,DC=rbrcompany,DC=com"(дочерняя партиция) RC-DC01.RC.Triuph.rbrcompany.com(good-source dc?)

    То есть, good-source-dc -это дочерний контроллер?

    И выполнять все эти команды надо на родительском?



    6 марта 2015 г. 3:10
  • Я там вслед за вами совершенно зря не проверил параметры repadmin /removelingeringobjects - потому что рассматривал этот вариант по остаточному принципу.

    Сейчас слазил в документацию. Так вот - всё наоборот: первый параметр - это имя КД (или имена - их может быть несколько), который содежит застрявший объект (в вашем случае - КД дочернего домена - rc-dc01.rc.triuph.rbccompany.com). Второй параметр - это GUID КД, откуда брать эталонную копию раздела. И в документации сказано, что это должна быть записываемая реплика раздела - а у вас таковой нет. Можете, конечно, попробовать подставить туда GUID вашего КД, содержащего частичную реплику, но это - на ваш риск, поскольку документации это противоречит. Короче, этот вариант я сильно не рекомендую.

    По /rehost: да, третий параметр - это КД дочернего домена: он единственный имеет полную копию раздела домена, так что её придётся считать хорошей - другой нет. Свой пример подтверждаю (ну, с точностью до пропущенных букв и т.п.) как именно те команды, которые нужно выполнить.

    Выполнять эту команду лучше на вашем КД - она изменяет именно его, но, в принципе, запускать её можно откуда угодно - главное, чтобы у пользователя, под которым запускается, были права администратора

    PS Раздел конфигурации проверять (я про это писал в прошлый раз) командой

    repadmin /removelingeringobjects rc-dc01.rc.triuph.rbccompany.com 59ae5a7-7bda-4fb4-8546-aca85172d254 "CN=Configuration,DC=rbrcompany,DC=com" /advisory_mode

    Для проверки, возможно (а для последующей корректировки - скорее всего), понадобится членство в группе Администраторы предприятия.



    Слава России!


    • Изменено M.V.V. _ 6 марта 2015 г. 11:20
    6 марта 2015 г. 11:19

  • Уважаемый mvv! Спасибо Вам за потраченное время. Короче, с repadmin /removelingeringobjects

    ничего не получается. Попрошу таки помощи Enterprise admin.

    У меня вроде как написал, что удаляет некие объекты-но по факту 0.

    но все таки пару вопросов.

    1) Можно как бы в реестре выставить 

    To edit the registry to enable strict replication consistency

    1. Open a registry editor.
    2. Navigate to Strict Replication Consistency entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
    3. Set the value in the Strict Replication Consistency entry to 0

    И после этого, пройдет репликация с поломанного партнера. Но правильно ли я опасаюсь, что потом проблемы уже у меня будут при репликации с другими доменами, где таких значений в реестре нет?

    И вопрос 2) по unhost/rehost

    У меня в родительском домене ДВА контроллера и оба глобальные каталоги.

    В злосчастном дочернем один и он тоже глобальный каталог

    Таки при unhost-делаем

    repadmin /unhost TRIUPH-DC01.Triuph.rbrcompany.com "DC=RC,DC=Triuph,DC=rbrcompany,DC=com"

    То есть с МОЕГО GC удаляем всю информацию о дочернем-"DC=RC,DC=Triuph,DC=rbrcompany,DC=com"

    И так надо делать на обоих моих глобальных каталогах?

    Далее, по /rehost

    repadmin /rehost TRIUPH-DC01.Triuph.rbrcompany.com "DC=RC,DC=Triuph,DC=rbrcompany,DC=com" RC-DC01.RC.Triuph.rbrcompany.com

    то есть, мы с моего GC TRIUPH-DC01.Triuph.rbrcompany.com добавляем в глобальный каталог

    информацию о "DC=RC,DC=Triuph,DC=rbrcompany,DC=com" и третий параметр RC-DC01.RC.Triuph.rbrcompany.com (их контроллер)

    Эту операцию мне надо делать по очереди на обоих своих глобальных каталогах? или на одном? И после этих операций нужно как-то чинить репликацию?



    • Изменено PVDPVDPVD 6 марта 2015 г. 12:27
    6 марта 2015 г. 11:57
  • 1. Отключать Strict replication consistency не торопитесь - при переразмещении (/rehost) раздела это не понадобится. И вообще её лучше не отключать - кроме тех случаев, когда это абсолютно необходимо.

    2. Операцию /rehost нужно проделать на обоих ваших глобальных каталогах. И не только на ваших, но и на глобальных каталогах всего предприятия: проблемы несреплицированного вовремя создания объекта компьютера касаются всех.


    Слава России!

    6 марта 2015 г. 12:26
  • И после этих операций по unhost/rehost нужно как-то чинить репликацию? Убивать-пересоздавать ее?

    С глобальными каталогами всего предприятия-я сообщил человеку, но это в данном случае ОЧЕНЬ веселая вещь. Я правильно понимаю, что если у меня репликация не пройдет(не починится с помощью unhost/rehost), то через 60 дней дочерний домен будет жить отдельной от всего предприятия жизнью?


    • Изменено PVDPVDPVD 6 марта 2015 г. 12:34
    6 марта 2015 г. 12:31
  • Нет, после этого репликацию дополнительно чинить не нужно - репликация перерзмещённого раздела (дочернего домена) должна восстановиться.

    Слава России!

    6 марта 2015 г. 12:33
  • /unhost /rehost отложил на вторник. Пусть любители акрониса свободно попразднуют.

    • Скажите, mvv, если все так просто-почему же ms в своих статьях делать dcpromo /forseremoval и metadata cleanup?
    • Нужны ли для /unhost /rehost enterprice admin rights(думаю-нет)
    • Между unhost и  rehost-сколько по времени паузу делать?  И одновременно ли делать на обоих GC или можно по очереди?

    6 марта 2015 г. 20:14
  • Принудительное удаление поражённого контроллера - это просто и надёжно, работает всегда. Другие варианты - сложно, вдруг не сработает.

    Членство в группе администраторов предприятия, скорее всего, не нужно. Не проверял.

    Делать можно по очреди. Пауза, вроде бы, не нужна. По-моему, вообще можно /unhost не делать, но не уверен, потому и не рекомендую.

    Глобальные каталоги можно таким образом лечить независимо. Начинать лучше с партнёров репликации контроллера проблемного домена, и дальше переходить к их партнёрам, партнёрам партнёров и т.д., но можно этим и не заморачиваться.


    Слава России!

    6 марта 2015 г. 20:30