Предварительный отказ от ответственности: я специалист по UNIX по дизайну и профессии. Тем не менее, я работал с Windows-боксами не менее десяти лет с точки зрения оперативной поддержки / настройки производительности.
Моя компания недавно приобрела другую компанию, и мы изучаем стратегии консолидации Active Directory между ними. У нас есть VPN-соединение между сайтами и быстрое и быстрое разрешение имен между двумя сайтами.
Я был бы признателен:
Я бы планировал отказаться от использования одного из лесов Active Directory и уничтожить его. Поддержка нескольких доменов, не говоря уже о нескольких лесах, Active Directory - это просто боль.
Если у вас нет большого количества пользователей / компьютеров или сложных разрешений файловой системы в неиспользуемом лесу, я бы даже не стал беспокоиться о таком инструменте, как Active Directory Migration Tool.
Инструменты миграции отлично подходят для быстрого выполнения задач, но если у вас есть время для установки доверительных отношений между лесами и преднамеренного перемещения, вы можете предоставить всем разрешениям для файлов, приложениям и любым другим службам, которые полагаются на Active Directory, настоящий верх тщательно проанализировать и ассимилировать приобретенную компанию в вашу Active Directory контролируемым и скоординированным образом, вместо того, чтобы переносить большой багаж из своей AD, который на долгие годы превратится в «унаследованный» жернов на вашей шее .
Я бы установил доверительные отношения между лесами, чтобы пользователи из одного домена могли входить в систему на компьютерах в другом. Тогда членство клиентских компьютеров в домене становится несколько несущественным. Я бы развернул несколько контроллеров домена для целевого домена в офисе приобретенной компании. Вы даже можете развернуть их как виртуальные машины на существующих контроллерах домена, несмотря на лицензирование Windows.
Я бы наметил, для чего используется групповая политика в неиспользуемом лесу, а также разместил сайты и подразделения в целевом лесу для размещения компьютеров по мере их перемещения. Вы, вероятно, обнаружите, что они на самом деле не используют групповую политику для чего-либо (кажется, к сожалению, это все еще так и через 9 лет после того, как на сцену вышли Active Directory и групповая политика), но определенно подумайте над этим.
Я бы развернул сценарий запуска с помощью инструмента «NETDOM» (см. http://technet.microsoft.com/en-us/library/cc781853(WS.10).aspx), чтобы исключить клиентские компьютеры из неиспользуемого леса и присоединить их к целевому лесу. Вход в систему пользователей будет продолжать работать так же, как и для неиспользуемых пользователей леса.
Переносить или нет пользователей и группы из неиспользуемого леса будет зависеть от количества пользователей и групп, а также от сложности простого воссоздания списков ACL пользователей, групп и файловой системы в целевом лесу.
Вы не упомянули Exchange. Если используется Exchange, вам следует беспокоиться о миграции почтовых ящиков между лесами и организациями. Я воздержусь от комментариев по этой проблеме, если вы не обновите и не скажете, что вам нужна информация о ней.
Вы рассматриваете два разных способа сделать это: 1. Доверие к домену (простое): создает связь между двумя вашими доменами, чтобы вы могли предоставить пользователям в домене доступ к общим ресурсам в домене B и наоборот. Вы также можете создать одностороннее доверие, которое работает только в одном направлении. 2. Миграция домена: переместите все объекты (пользователей, компьютеры и т. Д.) Из одного домена в другой. ADMT (средство миграции Active Directory) - это набор инструментов, который вы обычно здесь используете. Если в обоих доменах установлен Exchange Server, вы также смотрите на миграцию почтовых ящиков из одной организации Exchange в другую (между Exchange и Active Directory Forests существует взаимно-однозначное отношение, поэтому вы не можете просто переместить exhcange между лесами нашей эры).
Как отмечает Сэм, именно здесь вы захотите протестировать, протестировать и еще раз протестировать! Сама миграция не так уж сложна, но любая ошибка может быть потенциально катастрофической.
Эван Андерсон даст вам действительно хороший ответ на этот вопрос, но пока он не появится, я могу дать вам кое-что для исследования.
По сути, у вас есть «дерево» Active Directory. Это ваш домен. У вашей новой компании тоже есть такой. Их «дерево» - это их владения. Вы хотите поместить оба «дерева» в один и тот же «лес». Я не выгляжу симпатичным, это настоящие термины.
Я знаю только технически, чтобы знать, что я не знаю ответа. Google предоставляет некоторые хорошие результаты, но обязательно поговорите с кем-нибудь, кто знает, прежде чем вы это сделаете. Есть ли в другой компании кто-нибудь с большим опытом работы с Windows?
Кроме того, я бы рекомендовал взять книгу AD для используемой вами версии Windows Server. Они поучительны, и мне, как специалисту по Linux, иногда немного неприятно видеть их образ мышления, но обычно это работает. Это просто другое.
Удачи!
Обычно вы используете что-то вроде ADMT или Quest для миграции всех соответствующих объектов (пользователей, групп, компьютеров, серверов и т. Д.) Из домена (ов), принадлежащего одной компании, в домен другой.
Это требует серьезного планирования, и вам нужно будет смотреть на серверы от приложения к приложению. Некоторые вещи довольно легко переместить, например файловые серверы и серверы печати, в то время как другие, например SQL / SharePoint гораздо сложнее.
ADMT и аналогичные могут выполнять работу, касаясь всех машин за вас, а также копируя принципалов.
Сделайте сосуществование как можно короче. Запуск обоих доменов не приведет ни к чему, кроме проблем. Если одно AD явно лучше (где лучше = лучшая модель администрирования, мониторинга и т. Д.), Чем другое (или DC в одном из них закончился), перенесите пользователей на него. В противном случае настройте новый домен и перейдите на него в течение заранее определенного периода времени.