none
Востановление связий DC RRS feed

  • Вопрос

  • Добрый вечер! Есть задача, не знаю как поступить правильно.

    В организации было два сайта, потом организация разделилась на две независимые фирмы, и один из адимнистраторов решил тупо удалить все вомозможные межсайтовые связи, пользователей, группы, домен контроллеры которые перешли с другой фирмой, решив таким образом "почистить ad". Теперь случилось то, что я так думаю ранее не кто не мог ожидать , фирмы эти решили объедениться! :) В общем в итоге: есть два домена разных организациях, dns имена одинаковые, второй домен в котором работет другой администратор сохранил  конфигурацию ad (т.е. ничего не удалаял там, правда все там в ошибках по части репликации и т.д. ). Можно ли востановить старые связи между контроллерами, предварително сделав Backup SystemState  одного из контроллеров домена, и синхранизнуть объекты (пользователей, компьютеры, группы), а потом выполнить Authoritative Restore необходимых объектов с предварительным отключение +Disable_Inbound_Replication. Или есть другие варианты, посоветуйте.


    MCP,MCTS,MCSA
    27 ноября 2010 г. 20:15

Ответы

  • Да верно в организации Б, на КД нет ролей FSMO. Да давно,сказали что пол года назадна, захвата fsmo не было. Думаю поступить так. Захватить роли на DC "Организации B" и путь живет эта организация своей жизнью  пока местный администратор руками или скриптом не пересоздаст пользователей в домене "Организации А" и далее заведет пользователей в домен "Организации B" заново, а после заменит профили рабочих станций что бы пользователи не плакали что у них теперь все подругому на рабочем столе. Думаю доверие между контроллерами "Организации А" и "Организации B" уже не полчиться коректно сделать после захвата fsmo. Есть ли варианты какие нибудь?


    MCP,MCTS,MCSA


    Если давно - то это хуже - Thomstone life time для удаленных объектов прошел - КД уже не объединить. А доверие в любом случае не удалось бы установить, даже после перименования одного из "осколков" - GUID домена то один и не меняется в течении всей "жизни" домена

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

    http://www.microsoft.com/downloads/en/details.aspx?familyid=AE279D01-7DCA-413C-A9D2-B42DFB746059&displaylang=en

    1.  В организации Б захватить роли

    2. поднять промежуточный КД - в новом домене, в новом лесу

    3. Установить с ним доверие с Организацией Б - и мигрировать туда пользователей, компьютеры, сервера и. т. д. (профили во время миграции также остаются с пользователями - ничего вручную с ними делать не нужно

    4. Разорвать предыдущее доверие и установить новое доверие промежуточного домена с Организацией А. Повторить процедуру миграции

    Впрочем если пользователей немного - то можно как и вы предлагаете "руками" пересоздать пользователей, перевключить раб. станции в домен и поправить пользовательские профили.

    • Помечено в качестве ответа Andrey Podlesnykh 28 ноября 2010 г. 15:28
    28 ноября 2010 г. 15:18
    Отвечающий

Все ответы

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

    В данный момент у вас как я понял в домене с одним GUID два набора держателей FSMO, возможно одинаковые SID пользователей, вероятно разные версии схемы и т. д. - посему правильный вариант только тот, что я предлагаю

    27 ноября 2010 г. 22:17
    Отвечающий
  • GUID один, держателем FSMO является один из контроллеров организации в котором поудаляли все связи с бывшим-вторым сайтом в другой организации в которой находился (когда работала межсайтовая репликация) контроллер, на этом контроллере хостится только gc. Поэтому у них после разрыва репликации еще работает аутентификация и авторизация. Вот мне нужно с контроллера который хостит только gc каталог мигрануть несколько ou и пользователей....эх если бы был systemstate того времени когда все работало....можно было бы востановить принудительно все что необходимо. Можно захватить роли, на контроллере на котором кроме gc нет ничего,  но тогда о доверии можно забыть так как после захвата ролей бывший хозяин fsmo считается мертвым и общаться с ним снова не рекомендуется.  Если смотреть в сторону варианта доверий например выполнить seize fsmo, удалить контроллеры которые считаютя не востребованными или мертвыми, переименовать dc, очистить dns от старых записей и потом уже настроит доверия? возможны ли проблемы в период настройки доверий или этот вариант не верный?  


    MCP,MCTS,MCSA
    28 ноября 2010 г. 12:43
  • GUID один, держателем FSMO является один из контроллеров организации в котором поудаляли все связи с бывшим-вторым сайтом в другой организации в которой находился (когда работала межсайтовая репликация) контроллер, на этом контроллере хостится только gc. Поэтому у них после разрыва репликации еще работает аутентификация и авторизация. Вот мне нужно с контроллера который хостит только gc каталог мигрануть несколько ou и пользователей....эх если бы был systemstate того времени когда все работало....можно было бы востановить принудительно все что необходимо. Можно захватить роли, на контроллере на котором кроме gc нет ничего,  но тогда о доверии можно забыть так как после захвата ролей бывший хозяин fsmo считается мертвым и общаться с ним снова не рекомендуется.  Если смотреть в сторону варианта доверий например выполнить seize fsmo, удалить контроллеры которые считаютя не востребованными или мертвыми, переименовать dc, очистить dns от старых записей и потом уже настроит доверия? возможны ли проблемы в период настройки доверий или этот вариант не верный?  


    MCP,MCTS,MCSA


    Не совсем понял ваш пост.

    Вы лучше обозначьте "Организация А" и "организация Б" и опишите существующее положение вещей в них, относительно AD. И из какой организации в какую вы хотите перенести ресурсы.

    PS: И все же повторюсь без миграции в промежуточный домен вам не обойтись.

    28 ноября 2010 г. 13:04
    Отвечающий
  • В "Организации А": контроллер домена держатель FSMO и глобального коталога домена lab.local.  В "Организации B" контроллер домена держатель глобального коталога  того же домена lab.local. "Организации А" и  "Организации B" находяться в териториально разных местах, настроена межсайтовая репликация. В "Организации А" удалили cвязи с сайтом  "Организации B" (имя контроллера  "Организации B", сайт линки, из DNS записи, пользователей и OU организации  "Организации B" ). Можно ли востановить старые связи между контроллерами "Организации А" и "Организации B"?


    MCP,MCTS,MCSA
    28 ноября 2010 г. 13:46
  • В "Организации А": контроллер домена держатель FSMO и глобального коталога домена lab.local.  В "Организации B" контроллер домена держатель глобального коталога  того же домена lab.local. "Организации А" и  "Организации B" находяться в териториально разных местах, настроена межсайтовая репликация. В "Организации А" удалили cвязи с сайтом  "Организации B" (имя контроллера  "Организации B", сайт линки, из DNS записи, пользователей и OU организации  "Организации B" ). Можно ли востановить старые связи между контроллерами "Организации А" и "Организации B"?


    MCP,MCTS,MCSA


    То есть в организации Б, на их КД нет ролей FSMO, то есть после разделения домена захват ролей не выполнялся?

    Как давно было разделение?

     

    28 ноября 2010 г. 13:51
    Отвечающий
  • Да верно в организации Б, на КД нет ролей FSMO. Да давно,сказали что пол года назадна, захвата fsmo не было. Думаю поступить так. Захватить роли на DC "Организации B" и путь живет эта организация своей жизнью  пока местный администратор руками или скриптом не пересоздаст пользователей в домене "Организации А" и далее заведет пользователей в домен "Организации B" заново, а после заменит профили рабочих станций что бы пользователи не плакали что у них теперь все подругому на рабочем столе. Думаю доверие между контроллерами "Организации А" и "Организации B" уже не полчиться коректно сделать после захвата fsmo. Есть ли варианты какие нибудь?


    MCP,MCTS,MCSA
    28 ноября 2010 г. 14:48
  • Да верно в организации Б, на КД нет ролей FSMO. Да давно,сказали что пол года назадна, захвата fsmo не было. Думаю поступить так. Захватить роли на DC "Организации B" и путь живет эта организация своей жизнью  пока местный администратор руками или скриптом не пересоздаст пользователей в домене "Организации А" и далее заведет пользователей в домен "Организации B" заново, а после заменит профили рабочих станций что бы пользователи не плакали что у них теперь все подругому на рабочем столе. Думаю доверие между контроллерами "Организации А" и "Организации B" уже не полчиться коректно сделать после захвата fsmo. Есть ли варианты какие нибудь?


    MCP,MCTS,MCSA


    Если давно - то это хуже - Thomstone life time для удаленных объектов прошел - КД уже не объединить. А доверие в любом случае не удалось бы установить, даже после перименования одного из "осколков" - GUID домена то один и не меняется в течении всей "жизни" домена

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

    http://www.microsoft.com/downloads/en/details.aspx?familyid=AE279D01-7DCA-413C-A9D2-B42DFB746059&displaylang=en

    1.  В организации Б захватить роли

    2. поднять промежуточный КД - в новом домене, в новом лесу

    3. Установить с ним доверие с Организацией Б - и мигрировать туда пользователей, компьютеры, сервера и. т. д. (профили во время миграции также остаются с пользователями - ничего вручную с ними делать не нужно

    4. Разорвать предыдущее доверие и установить новое доверие промежуточного домена с Организацией А. Повторить процедуру миграции

    Впрочем если пользователей немного - то можно как и вы предлагаете "руками" пересоздать пользователей, перевключить раб. станции в домен и поправить пользовательские профили.

    • Помечено в качестве ответа Andrey Podlesnykh 28 ноября 2010 г. 15:28
    28 ноября 2010 г. 15:18
    Отвечающий
  • Да верно в организации Б, на КД нет ролей FSMO. Да давно,сказали что пол года назадна, захвата fsmo не было. Думаю поступить так. Захватить роли на DC "Организации B" и путь живет эта организация своей жизнью  пока местный администратор руками или скриптом не пересоздаст пользователей в домене "Организации А" и далее заведет пользователей в домен "Организации B" заново, а после заменит профили рабочих станций что бы пользователи не плакали что у них теперь все подругому на рабочем столе. Думаю доверие между контроллерами "Организации А" и "Организации B" уже не полчиться коректно сделать после захвата fsmo. Есть ли варианты какие нибудь?


    MCP,MCTS,MCSA


    Если давно - то это хуже - Thomstone life time для удаленных объектов прошел - КД уже не объединить. А доверие в любом случае не удалось бы установить, даже после перименования одного из "осколков" - GUID домена то один и не меняется в течении всей "жизни" домена

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

    http://www.microsoft.com/downloads/en/details.aspx?familyid=AE279D01-7DCA-413C-A9D2-B42DFB746059&displaylang=en

    1.  В организации Б захватить роли

    2. поднять промежуточный КД - в новом домене, в новом лесу

    3. Установить с ним доверие с Организацией Б - и мигрировать туда пользователей, компьютеры, сервера и. т. д. (профили во время миграции также остаются с пользователями - ничего вручную с ними делать не нужно

    4. Разорвать предыдущее доверие и установить новое доверие промежуточного домена с Организацией А. Повторить процедуру миграции

    Впрочем если пользователей немного - то можно как и вы предлагаете "руками" пересоздать пользователей, перевключить раб. станции в домен и поправить пользовательские профили.Ерфттлы

    Many thanks for your reply!
    MCP,MCTS,MCSA
    28 ноября 2010 г. 15:30