none
Невозможно удалить учетные записи с RODC после восстановления Writable доменконтроллера из предыдущей резервной копии RRS feed

  • Общие обсуждения

  • Добрый день!

    Подскажите, пожалуйста, может кто-то с таким уже сталкивался:

    после сбоя оборудования из резервной копии были восстановлены доменконтроллеры, с которых производится репликация на все RODC в филиалах. В день сбоя на все RODC записались некоторые учетные записи (компьютерные и пользовательские). После этого основные доменконтроллеры были восстановлены из резервной копии, на момент создания которой этих учетных записей еще не было.

    Теперь на всех RODC эти пользователи и компьютеры есть, а на контроллерах-источниках репликации их нет. Создать учетные записи с таким же именем естественно не получается. При помощи repadmin /removelingeringobjects их удалить тоже не получается. Единственный выход - dcpromo на всех RODC (их очень много) и повышение их снова до уровня доменконтроллера (проверено на одном RODC).

    Может быть есть какие-либо утилиты или способы удалить эти учетные записи без понижения/повышения всех доменконтроллеров?

    основные доменконтроллеры - Windows 2008R2, RODC - или 2008 Server или 2008R2

    заранее спасибо, если кто-то сможет помочь!



    3 апреля 2013 г. 10:16

Все ответы

  • Вы восстанавливали из дампа ВСЕ доступные для записи контроллеры домена?

    Проводилось ли авторитетное восстановление базы AD?


    Сергей Панченко

    3 апреля 2013 г. 10:27
  • Сергей,

    мы восстанавливали при помощи DPM только записываемые доменконтроллеры дочернего домена (в нем как раз и находятся все RODC) и 2 оставшихся доменконтроллера из корневого домена. В живых после сбоя остался только эмулятор PDC из корневого домена (на нем же роли RID и Infrastructure), но сейчас на нем этих учетных записей нет (AD имеет такой же вид как и на восстановленных доменконтроллерах).

    авторитетное восстановление базы не делали - понадеялись что все изменения за это время останутся на работавшем все это время PDC корневого домена и запишутся на восстановленные DC, но такое впечатление, что случилось все наооборот.

    3 апреля 2013 г. 11:33
  • Значит, в Вашем домене были восстановлены все доступные на запись DC. Так как Вы не провели авторитетного восстановления, то в Вашем (дочернем) домене сейчас нет ни одного DC с которого можно провести репликацию. Все DC Вашего С RODC репликация невозможна. Корневой DC и обладатель ролей уровня леса Вам не поможет - на нём нет полной информации об объектах Вашего домена. 

    А на RODC информация об объектах "висит" именно потому, что им неоткуда среплицироваться: все RWDC подняты из дампов и находятся в состоянии ожидания репликации. И такая ситуация будет до тех пор, пока один из RWDC  Вашего домена не будет авторитетно восстановлен.


    Сергей Панченко



    • Изменено Daemon-GTC 3 апреля 2013 г. 12:10
    3 апреля 2013 г. 12:04
  • Спасибо большое за ответ!

    Сейчас попробую сделать. Как закончу - напишу результат.

    3 апреля 2013 г. 12:45
  • Значит, в Вашем домене были восстановлены все доступные на запись DC. Так как Вы не провели авторитетного восстановления, то в Вашем (дочернем) домене сейчас нет ни одного DC с которого можно провести репликацию. Все DC Вашего С RODC репликация невозможна. Корневой DC и обладатель ролей уровня леса Вам не поможет - на нём нет полной информации об объектах Вашего домена. 

    А на RODC информация об объектах "висит" именно потому, что им неоткуда среплицироваться: все RWDC подняты из дампов и находятся в состоянии ожидания репликации. И такая ситуация будет до тех пор, пока один из RWDC  Вашего домена не будет авторитетно восстановлен.


    Сергей Панченко



    В данном случае полномочное (authoritative) восстановление не поможет. Дело в том, что на RWDC, восстановленных из копий, совсем нет объектов, застрявших на RODC - ни активных, ни захороненных. Если нет возможности удалить эти объекты, то RODC лучше переустановить - иначе возможны конфликты репликации из-за совпадения уникальных атрибутов (distinguishedName, sAMAccountName и т.п.) либо появления непредусмотренного доступа в пределах сайта с RODC из-за совпадения SID зависших и новых пользователей.

    Удалить эти зависшие объектв можно попробвать тем же методом, каким удаляются зависшие объекты из глобального каталога - он описан в статье 314282 MS KB  (см. также пример удаления без репликации в MSDN Library: http://msdn.microsoft.com/en-us/library/cc223303.aspx )

    PS Если бы в домене не было RODC, то полномочное восстановление тоже бы не потребовалось - контроллеры домена просто передали бы друг на друга полные версии своих каталогов, а стандартный механизм отслеживания версий и разрешения конфликтов обеспечил бы согласованность всех копий каталога.


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



    • Изменено M.V.V. _ 3 апреля 2013 г. 17:43
    3 апреля 2013 г. 17:35
  • В данном случае полномочное (authoritative) восстановление не поможет. Дело в том, что на RWDC, восстановленных из копий, совсем нет объектов, застрявших на RODC - ни активных, ни захороненных. Если нет возможности удалить эти объекты, то RODC лучше переустановить - иначе возможны конфликты репликации из-за совпадения уникальных атрибутов (distinguishedName, sAMAccountName и т.п.) либо появления непредусмотренного доступа в пределах сайта с RODC из-за совпадения SID зависших и новых пользователей.


    Я не претендую на истину, но как-то считал, что после восстановление из дампа КД хочет среплицироваться с одного из партнёров. Но, в данном случае, ни один из партнёров не готов к репликации (т.к. они тоже подняты из дампа и тоже ожидают первичную репликацию). В результате все сидят и ждут того, кто сможет отдать репликацию в домене.

    Сергей Панченко


    • Изменено Daemon-GTC 4 апреля 2013 г. 4:00
    4 апреля 2013 г. 3:59
  • Дык, КД всегда готовы реплицироваться (если только USN Rollback не обнаружат, конечно). А полномочное восстановление - это AFAIK очень простая штука: она всего лишь продергивает номер версии всех затронутых объектов и их атрибутов на большое число (100000 по умолчанию, но можно и конкретно указать в команде), чтобы объекты именно с восстановленного КД считались актуальными.


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

    4 апреля 2013 г. 7:46
  • Спасибо за ссылки. Попробую сделать то, что в них предлагается - может поможет
    4 апреля 2013 г. 9:04
  • Дык, КД всегда готовы реплицироваться (если только USN Rollback не обнаружат, конечно).

    И вовсе нет. Сам с разбегу когда-то на эти грабли наступил: нужно было перестроить RAID-массивы под обоими КД в домене. Сделал дампы с обоих, завалил первый (владелец всех ролей), поднял из дампа, пустил в работу, репликацию не проверил. Затем завалил второй, поднял из дампа, пустил в работу. И тут решил посмотреть, что с репликацией. А вот болт: оба КД бормочут, что партнёр не готов, реплицироваться не с кем и, вообще, жизнь не задалась. Тогда я и узнал, что такое полномочное восстановление. ;-)

    Сергей Панченко

    4 апреля 2013 г. 10:48
  • Интересно. Надо проверить на стенде.


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

    4 апреля 2013 г. 11:06
  • Спасибо за ссылки. Попробую сделать то, что в них предлагается - может поможет

    Забыл упомянуть сразу - при этом обязательно имейте в виду совет Daemon-GTC: если будете удалять объекты на RODC, то полномочное восстановление обязательно - иначе на RODC могут оказаться объекты и их атрибуты с бОльшими номерами версии, чем на RWDC и измененнные на RWDC атрибуты не среплицируются на RODC.

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



    • Изменено M.V.V. _ 4 апреля 2013 г. 11:09
    4 апреля 2013 г. 11:08
  • Дык, КД всегда готовы реплицироваться (если только USN Rollback не обнаружат, конечно). А полномочное восстановление - это AFAIK очень простая штука: она всего лишь продергивает номер версии всех затронутых объектов и их атрибутов на большое число (100000 по умолчанию, но можно и конкретно указать в команде), чтобы объекты именно с восстановленного КД считались актуальными.

    Опять же, не буду спорить, т.к. теоретических познаний мало, но на практике, когда КД поднимается (при рестарте или после дампа - не важно), он смотрит в DNS и ищет там партнёров по репликации. Если таковые есть - он пытается с ними связаться, чтобы получить последние изменения в БД AD. И пока он их не получит, он будет висеть в состоянии "не готов к репликации" и, соответственно, сам никому ничего не отдаст. Подобная ситуация случается и после падения питания (недавно был случай, когда под выключение питания попали все RWDC домена). Питание подали, все RWDC загрузились, но репликации нет: т.к. каждый из RWDC "знает", что его рубанули на всём скаку и, прежде, чем начать работать, он хочет получить последние изменения. А взять их неоткуда: никто ж из RWDC не знает, кто последним пал. ;-)

    PS. Если гасить все RWDC корректно, а потом поднимать начиная с эмулятора PDC, то тогда они как-то разбираются (правда, весьма не быстро) с проблемой и кто-то решается объявить себя целостным и отдаться свои знания другим. А вот при отключении из-за падения питания - грабли.  А ведь подъём из дампа почти равносилен подъёму после выключения питания: транзакционная база целостна на какой-то момент времени, но работал ли хотя бы один DC после этого момента времени она не знает.


    Сергей Панченко



    • Изменено Daemon-GTC 4 апреля 2013 г. 13:12
    4 апреля 2013 г. 13:04
  • Daemon-GTCM.V.V.  спасибо большое за помощь и подсказки!

    Полномочное восстановление я сделал (теперь буду знать - честно говоря, не падали у меня еще все DC одновременно). Но это действительно не помогло - обьекты-фантомы так и не удалились. через LDP и repadmin их удалить тоже не получилось, хотя при этом репликация работает и другие изменения, не касающиеся этих обьектов реплицируются нормально.

    Вместо DCPromo на всех RODC я пошел проще -  сделал новые OU в тех же сайтах с RODC (повезло, что они не в корне сайта лежат) и перенес туда все живые обьекты, а после этого удалил старую OU, вместе с удалением которой ушло все, что застряло на RODC.

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

    12 апреля 2013 г. 13:22
  • Daemon-GTCM.V.V.  спасибо большое за помощь и подсказки!

    Полномочное восстановление я сделал (теперь буду знать - честно говоря, не падали у меня еще все DC одновременно). Но это действительно не помогло - обьекты-фантомы так и не удалились.

    Не удалились ГДЕ? На RODC или на RWDC?

    Сергей Панченко

    12 апреля 2013 г. 13:39
  • на RODC - все записываемые DC свои обьекты поудаляли почти сразу. Правда восстановления всей базы я не делал - попробовал для начала восстановить OU одного сайта, где лежит один из обьектов, от которых я хочу наконец-то избавиться - у нас больше 150 сайтов и восстанавливать всю базу не хотелось бы - репликация сьела бы все каналы.

    Кстати, полностью они так и не удалились, а переместились в Deleted objects (причем отображаются они там тоже только на RODC).Сейчас я поставил значение tombstone в 2 дня - проверю дня через 3 удалится ли все содержимое папки (корзины у меня нет - уровень леса пока 2008 сервер).

    надеюсь конечно что удаление вместе с OU поможет - вполне может быть они в удаленных так и зависнут. я уже ни в чем не уверен :)



    • Изменено Yooj 13 апреля 2013 г. 11:50
    13 апреля 2013 г. 11:42