Перевести компьютер из одного домена в другой

Обновлено: 07.07.2024

Active Directory - от теории к практике. Часть 4 - перенос учетных записей в домен.

В прошлых материалах мы рассказали как правильно развернуть и настроить инфраструктуру Active Directory, сегодня мы поговорим о том, как правильно ввести в структуру AD уже существующие рабочие станции и учетные записи пользователей. Следуя нашим рекомендациям вы сможете избежать ряда потенциальных проблем и осуществить переход к AD наиболее безболезненно.

Очень редко когда структура Active Directory создается с нуля, гораздо чаще службы каталогов разворачиваются уже на базе существующей сети, где каждый пользователь имеет свою, настроенную согласно его потребностям, учетную запись, свой набор ярлыков, папок, программ, настроек. При переходе от локальной учетной записи к учетной записи Active Directiory все эти настройки окажутся потерянными и учетную запись пользователя нужно настраивать заново.

А сколько таких учетных записей? Явно не одна и не две, а если принять во внимание, что все равно что нибудь забудете или упустите из виду, то становится понятно, что процесс перевода инфраструктуры от обычной сети к службе каталогов способен превратиться в настоящий ад, как для администратора, так и для сотрудников. Что же делать? Не спешить и, для начала, внимательно прочитать нашу статью.

К сожалению не одни только ученые записи способны вызвать затруднения при переходе на Active Directory, поэтому самое время вспомнить о том, что такое SID. SID компьютера - это уникальный идентификатор безопасности, который генерируется при установке системы и используется в качестве основы при создании прочих идентификаторов (для пользователей, групп и т.п.). Хотя в настоящее время многие специалисты считают проблему дублирующегося SID преувеличенной, например см. статью М. Руссиновича "Миф о дублировании SID компьютера", мы не рекомендуем рисковать и включать в домен машины с одинаковыми SID.

Когда может возникнуть такая ситуация? При клонировании уже установленной системы на несколько ПК, например столь любимыми многими утилитами Norton Ghost или Acronis. Появление в сети подобным машин может привести к неправильному применению групповых политик и некорректной работе некоторых сетевых служб, например WSUS. Мы не будем однозначно утверждать, что данные проблемы возникают именно от дублирующегося SID, но лучше предупредить возможные проблемы, чем потом заниматься их решением. Поэтому лучше позаботиться об уникальности SID до включения машин в домен и появления возможных проблем.

Для обеспечения уникальности SID следует использовать утилиту sysprep, о использовании которой мы рассказывали в данной статье, в Windows 7 данная утилита входит в состав системы и расположена в C:\Windows\System32\sysprep.

Также ни при каких обстоятельствах не допускайте клонирования уже включенной в домен системы - это верный способ получить вес спектр неприятностей связанных с одинаковыми идентификаторами. С этой темой тесно пересекается ситуация с заменой ПК сотрудника, когда новый компьютер должен иметь то-же самое имя, что и старый. При этом простое переименование старого ПК не даст нужного эффекта, для устранения возможных проблем старый ПК необходимо вывести из домена, ввести туда новый ПК под тем же именем, а затем снова ввести старый, но с новым именем хоста, если есть такая необходимость.

Итак, у нас есть некая рабочая станция за которой работает сотрудник Иванов и которую нужно ввести в домен. В первую очередь убедитесь что ПК имеет желаемое имя и при необходимости переименуйте компьютер, не забудьте перезагрузиться. Следующим шагом необходимо правильно настроить сеть, так как в нашей сети развернут DHCP-сервер достаточно установить автоматическое получение сетевых параметров и убедиться в получении правильных значений.

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

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

Теперь самое время включить наш компьютер в домен. Для этого перейдите в Свойства системы - Имя компьютера и нажмите кнопку Изменить. В открывшемся окне выберите Является членом домена и укажите имя домена в который мы хотим войти, затем нажмите OK, затем укажите имя и пароль пользователя имеющего право на включение компьютера в домен (по умолчанию администратор домена).

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

После перезагрузки можно попробовать войти под доменной учетной записью, которую нужно предварительно создать на любом из контроллеров домена. Для этого откройте оснастку Active Directory - пользователи и компьютеры, перейдите в папку User и создайте там нового пользователя.

Теперь в систему можно войти под именем нового пользователя. И убедиться в том, о чем мы говорили в начале статьи: работая под локальной учетной записью пользователь Иванов имел привычным образом расположенные файлы, папки и ярлыки, программы были соответствующим образом настроены, кроме того имелась учетная запись почты, избранное браузера и т.д. и т.п. Сейчас он имеет стерильно чистый профиль, который необходимо настраивать заново.

Поэтому самое время заняться переносом профиля локальной учетной записи в доменную. Для этого следует воспользоваться инструментом User State Migration Tool, который входит в состав Пакета автоматической установки Windows (AIK), скачать его можно здесь.

Данный пакет нет необходимости устанавливать на всех ПК, вполне достаточно будет установки на компьютер администратора или один из серверов. Искомый набор утилит находится в папке C:\Program Files\Windows AIK\Tools\USMT нам нужно будет скопировать их на целевую систему или сделать доступными по сети.

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

Внимание! Вы можете перенести профиль из 32-х разрядной системы в 64-х разрядную, однако обратный перенос из 64-х разрядной в 32-х разрядную не поддерживается!

Для создания файла переноса используется утилита ScanState с синтаксисом которой можно ознакомиться здесь. В нашем случае мы будем переносить локальный профиль пользователя WWW в профиль доменного пользователя ivanov. Для создания файла переноса войдите в систему под учетной записью администратора домена, перейдите в папку с нужной версией USMT (32 или 64 бит) и выполните следующую команду:

Синтаксис команды на первый взгляд довольно сложен, но это не так. Первый аргумент указывает расположение файла переноса, ключ /i: указывает какие правила переноса следует использовать, ключ /v: задает необходимый уровень детализации лога, сочетание ключей /ue: и /ui: исключает из переноса всех пользователей кроме WWW, а ключ /l: определяет расположение лога.

Результатом исполнения команды будет короткий отчет о выполненных операциях которые должны закончиться успехом.

Итак, файл переноса создан, но не спешите переходить ко второму этапу. Если вы уже входили в систему под целевым пользователем, то необходимо удалить или переименовать папку с профилем в каталоге C:\Users и удалить соответствующий профилю раздел в ветке реестра:

В противном случае при попытке восстановления профиля вы получите ошибку с кодом 71: LoadState return code: 71.

После того, как вы выполните данные операции можно переходит к восстановлению профиля при помощи утилиты LoadState, советуем ознакомиться с ее синтаксисом здесь. Для переноса профиля используйте следующую команду:

Структура команды во многом похожа на предыдущую, одноименные ключи имеют аналогичное значение, ключ /mu: указывает исходный профиль и профиль назначения, доменные учетные записи указываются как Domain\User. В нашем случае профиль локального пользователя WWW будет восстановлен в профиль пользователя interface31.lab\ivanov.

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

Данный метод можно использовать для операционных систем Windows Vista/7, для переноса профилей в среде Windows XP также можно использовать USMT несколько изменив синтаксис команд, но лучше воспользоваться утилитой moveuser, которая входит в состав Windows Server 2003 Resource Kit Tools (скачать). Точно также, как и в предыдущем случае, нет необходимости устанавливать пакет на каждую машину, достаточно скопировать утилиту moveuser которая находится в папке C:\Program Files\Windows Resource Kits\Tools.

Для переноса профиля также войдите на целевой ПК как администратор домена и выполните команду:

Синтаксис данной утилиты гораздо проще и его можно изучить запустив ее без аргументов. Ключ /y разрешает перезаписать профиль назначения если он существует, т.е. вы можете предварительно выполнить вход доменным пользователем на эту машину, это никак не помешает переносу, после переноса вход под локальным пользователем будет невозможен, если вы хотите продолжать использовать локальный профиль укажите дополнительно ключ /k.

Выполним вход под доменной записью пользователя Петров и убедимся что он может продолжать работу в домене с привычным рабочим окружением.

Как видим, использование специализированных утилит для переноса пользовательских профилей не вызывает затруднений и способно значительно облегчить работу системного администратора и свести к минимуму неудобства пользователей в процессе внедрения Active Directory.

Данная статья о миграции в случае, когда компьютер выходит из одного домена, и подключается к другому домену, или недоменный компьютер подключается к домену. Миграция будет осуществляться программой Profile Migration Wizard. Статью решил написать, так как миграция такого типа стала чаще встречаться, а работу программы нет просто понять. Дело в том, что на самом деле никакой миграции не происходит, так как данные никуда не перемещаются. Ну и просто меня попросили написать статью о ней ) На сколько я понял данная программа переписывает все SIDы и ACLы одного пользователя на другой. Именно SIDы и ACLы не позволяют применить способ копипаста, который работал в ХР (это было давно, и я могу ошибаться). У данной программы есть один минус (а может это и плюс): после миграции все пароли (в браузерах, в Outlook) сбрасываются. Возможно это сделано специально для безопасности. И так, приступим.

Миграцию профилей я буду показывать на примере двух доменов 2008 R2 и 2012. Клиентская ОС - Windows 8 Ent Eval x64. Для Windows 7 всё выполняется анналогично. Рекоменду сделать полные бекапы клиентских ОС. А так же экспортировать все пароли из браузеров . Конфигурация доменов:

В каждом домене были созданы по одному пользователю. В домене 2008 R2 - UserA, в домене 2012 - UserB. Если мигрирующих пользователей в Active Directory очень много, то можно использовать ADMT для миграции учётных записей из домена в домен. ADMT не поддерживается SBS редакциями, так как они не поддерживают доверительные отношения между доменами (к счастью, на помощь приходит межлессовая миграция почтовых ящиков Exchange вместе с учётками). Выводим и вводим Windows-8 из домена в домен (можно за один шаг просто перейти в новый домен, только не забудьте поменять DNS в настройках сетевой карты, иначе новый домен просто не "увидится"). Для проверки я создал текстовый файл на рабочем столе пользователя UserA.

Я снимаю галку для "входа по умолчанию" и ввожу имя новой учётной записи.

Вместо имён пользователей первого домена мы видим их SIDы, т.к. новый домен не может сопоставить чужие SIDы с именами. Но мы видим путь для профиля, по которому мы и определяем нужный профиль и указываем его.

Дальше программа делает фокус: перезписывает все SIDы и ACLы старого профиля на SIDы и ACLы нового пользователя. О чём собственно она и сообщает нам. Так как профиль чистый, нет никаких данных, установленных программ, то миграция длилась меньше секунды. Если вы будете мигрировать большие профили, то процесс может занять и час, а может и больше. Рекомендую перед миграцией почистить временные файлы интернета.

Заходим новым пользователем в систему. Проверяем кто мы в PowerShell. Проверяем путь к новой папке в "Мои Документах". И как видете в дереве папок есть только папка старого пользователя - usera. Это наверное второй минус программы. Но с другой стороны - она за бесплатно и так нам много сделала. Спасибо! Я не рекомендую вручную менять названия usera на userb - в настройках ваших программ уже указана именно эта папка usera. С этим придётся смерится. На этом всё.

К сожалению, на Майкрософтовских курсах, где я когда-то учился, вопрос миграции рассматривается достаточно «скомкано», вероятно, это связано с тем, что данный процесс происходит крайне редко, вероятно, просто не хватило времени на эту тему. Лишь однажды, уже слушая Exchange, Зинченко Максим, рассказывал нам, как мигрировать из домена с 2000 ной инфраструктурой в домен с 2003 инфраструктурой, но это так же не сильно отложилось в моей памяти. Посему хотелось бы об этом по подробней:

Многих системных администраторов отпугивает перенос объектов AD между лесами/доменами из-за громоздкости существующих руководств по данному процессу. В существующих публикациях раскрывается 100% возможностей средств Active Directory Migration Tool 3.1 (этот инструмент рекомендует Майкрософт, но есть еще и альтернативные инструменты, например Pontdiev Migration, но к сожалению они не бесплатны), немалая часть которых редко используется в реальных ситуациях, что и делает процесс подготовки к миграции долгим для многих администраторов, сталкивающихся с этим впервые (к таковым кстати отношусь и я). Классический сценарий требует избыточности в плане подготовки исходного и конечного доменов.

В представленном сценарии описывается процесс межлесовой миграции с минимальными вмешательствами в инфраструктуру исходного домена (например, без доверительных отношений), что несет в себе множество преимуществ. Перед выполнением данного сценария все же не стоит пренебрегать резервированием исходного и целевого доменов и созданием планов миграции и отката в исходную точку. Данная схема работает при минимальных логических изменениях в процессе для доменов любого уровня и на любых ОС, начиная с Windows Server 2000, в том числе и для Small Business Server’s и Essential Business Server’s.

В описываемом сценарии представлено два корневых домена под управлением ОС Windows Server 2008 SP2. Исходный домен SOURCE.LOCAL (FSMO-контроллером которого является сервер dc1.source.local, IP 10.8.2.251) содержит 158 пользователей и 8 групп безопасности, в которых они распределены. Конечный домен TARGET.LOCAL (dc2.target.local, IP 10.8.2.252). Цель – перенести все учетные записи пользователей (с сохранением паролей), группы безопасности и рабочие станции в конечный домен.

Подготовка исходного домена заключается в настройке DNS-пересылок и отключении DHCP-сервера. Все существующие пересылки необходимо удалить и создать обычную пересылку, указывающую на контроллер целевого домена.

Причем нам необходимо, чтобы IP-адрес контроллера целевого домена ссылался на его имя в FQDN-формате, для чего нужно добавить соответствующую PTR-запись в обратную зону.

Если же исходный домен-контроллер находится под управлением ОС Windows Server 2003, то можно ограничиться созданием пересылки на FQDN конечного домена без добавления в обратную зону PTR-записи контроллера конечного домена.

Наличие PTR-записи исходного домен-контроллера в обратной зоне также является необходимым условием.

Если целевой домен находится под управлением ОС Windows Server 2003, то в DNS достаточно ограничиться пересылкой на исходный домен по IP-адресу контроллера домена. В обратной зоне никаких изменений вносить не требуется при этом.

Registry path: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters
Registry value: AllowNT4Crypto
Type: REG_DWORD
Data: 1

В нашем случае команда будет выглядеть так:

Запускать командный файл придется каждый раз для запуска средства ADMT.

Генерация ключа для исходного домена на целевом контроллере командой:

Admt key /option:create /sourcedomain:ИМЯ_ИСХОДНОГО_ДОМЕНА /keyfile:ПОЛНЫЙ_ПУТЬ_К_КЛЮЧЕВОМУ_ФАЙЛУ

В нашем случае команда генерации ключа будет выглядеть так:

Admt key /option:create /sourcedomain:SOURCE.LOCAL /keyfile:C:\PWD.pes /keypassword:
Импортирование ключа для исходного домена на целевом контроллере командой:

admt key /option:import /sourcedomain: ИМЯ_ИСХОДНОГО_ДОМЕНА
/keyfile: ПОЛНЫЙ_ПУТЬ_К_КЛЮЧЕВОМУ_ФАЙЛУ
/ keypassword:ЗАДАННЫЙ_РАНЕЕ_ПАРОЛЬ

В нашем случае импортирование созданного ранее ключа будет выглядеть так:

admt key /option:import /sourcedomain:source.local /keyfile:C:\PWD.pes /keypassword:

Для миграция учетных записей пользователей необходимо запустить User Account Migration Wizard из меню Action. Далее необходимо ввести информацию об исходном и целевом доменах, указав при этом именно те контроллеры, которые были использованы при создании DNS-пересылок. В нашем случае это dc1.source.local и dc2.target.local. После выборки необходимых пользователей из исходного домена необходимо указать контейнер в целевом домене для размещения мигрированных объектов. Далее отмечаем опции Migrate Passwords, Do not update passwords for existing users и вводим контроллер исходного домена, на котором запущена служба PESSVC, в поле Password migration source dc. В нашем случае это dc1.source.local. В меню Account Transition Options отмечаем опции Target same as source и Migrate user SIDs to target domain. Далее будет предложено включить аудит учетных записей в исходном домене. Следует согласиться со всеми предложениями, после чего перезагрузка исходного контроллера будет необратима. После загрузки исходного контроллера необходимо запустить на нём службу PESSVC и продолжить миграцию учетных записей пользователей на конечном сервере. После чего необходимо ввести логин и пароль администратора исходного домена. В меню User Options отметить опции Translate roaming profiles, Update User Rights, Fix users’s group membership. В меню Conflict Management отметить опцию Do not migrate source objects if a conflict is detected in the target domain. С конфликтующими объектами лучше разобраться вручную. Меню с выбором исключений можно пропустить. Следует отметить, что в данном сценарии вместе с учетными записями пользователей также мигрируются перемещаемые профили, что делает данный процесс незаметным для конечного пользователя. Если в домене не используются перемещаемые профили, то рекомендуется заведомо их сделать таковыми.
Для миграции групп безопасности необходимо запустить Group Account Migration Wizard из меню Action. Далее необходимо ввести информацию об исходном и целевом доменах, указав при этом именно те контроллеры, которые были использованы при создании DNS-пересылок. В нашем случае это dc1.source.local и dc2.target.local. После выборки необходимых групп безопасности из исходного домена необходимо указать контейнер в целевом домене для размещения мигрированных объектов. В меню Group Options необходимо отметить опции Update user rights, Fix membership of group, Migrate group SIDs to target domain. В меню Conflict Management отметить опцию Do not migrate source objects if a conflict is detected in the target domain. Меню с выбором исключений можно пропустить. Никогда не следует выполнять миграцию таких глобальных групп безопасности как «Издатели сертификатов», «Администраторы DHCP», «Пользователи DHCP», DnsAdmins, DnsUpdateProxy, «Администраторы домена», «Компьютеры домена», «Контроллеры домена», «Гости домена», «Пользо¬ватели домена», «Администраторы предприятия», «Владельцы-создатели групповой политики», «Серверы RAS и IAS», «Администраторы схемы» и «Пользователи WINS» и их аналоги.
Миграция рабочих станций осуществляется через Computer Migration Wizard меню Action. Дойдя до меню Translate Objects можно отметить те опции, которые нам необходимы, после чего в Security Translation Options выбрать опцию Add (Add equivalent security references for target objects and have source reference intact). В следующем окне необходимо выставить временную задержку, по истечении которой клиентский ПК будет перезагружен (при условии, что агент мигрирования завершится успешно). Меню с исключениями можно пропустить. В меню Conflict Management отметить опцию Do not migrate source objects if a conflict is detected in the target domain. После того, как работа мастера завершится, будет запущено диалоговое окно управления агентами миграции ПК с перечнем всех выбранных ранее ПК, подлежащих переносу в новый домен. В разделе Agent Actions следует отметить опцию Run pre-check and agent operation и нажать Start. Со временем агент начнет перегружать клиентские ПК и выполнять процедуру POST-CHECK, которая может завершаться с ошибкой, если перед миграцией не были корректно настроены службы DHCP в обоих доменах. Чаще всего это свидетельствует о том, что клиентский ПК не получил корректных настроек от DHCP-сервера в конечном домене. По статистике примерно на 100 рабочих станций приходится 10-15, которые не обрабатываются агентом миграции. Такие ПК придется переносить вручную, если сходу не попытаться устранить проблему, которая, скорее всего, кроется в службах Workstation, Netlogon и RPC.

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

Здесь будет описана процедура переноса ящиков. Т.е. подразумевается, что пользовательские учетки вы уже перевели в новый лес. Если нет – эта процедура первоочередной важности, и должна быть успешно завершена до того как вы будете переносить сами почтовые ящики. Тоже самое касается переноса контактов и групп рассылки. Делается это с помощью Active Directory MIgration Tool 3.0 (ADMT v3.1), а руководство по применению ADMT – здесь

Перенос ящиков между доменами одного леса, или в пределах одного домена является очень уж тривиальной задачей. Однако, если понадобится, рассмотрим и этот вопрос. Перевод же компании между лесами AD, и по-сути, между организациями Exchange – представляется по первому времени – сложной задачей. Однако это не так. Сценарий переноса ящиков справедлив для всех случаев:
Exchange 2000 Server >
Exchange Server 2003 > => Exchange Server 2007
Exchange Server 2007 >

0. Как известно, перенести почтовые ящики из одного леса в другой при помощи графического интерфейса Exchange невозможно, и мы будем использовать EMS – Exchange Management Shell. PS:>_

Итак, учетки перемещены в новый лес Active Directory, переносим почтовые ящики:

1. Минимальные права для выполния переноса ящиков:
В исходной организации (лесу AD):
Администратор получателей Exchange, администратор сервера Exchange (Exchange Full Administrator в Exchange 2000/2003 и Exchange Recipient Administrator + Exchange Server Administrator в Exchange 2007) и членство в локальной группе администраторов, на сервере Exchange.
Эту учетку мы укажем параметром -SourceForestCredential

В целевой организации (лесу AD): такие же –
Exchange Recipient Administrator, Exchange Server Administrator в Exchange 2007 и членство в локальной группе администраторов, на сервере Exchange.
Эту учетку мы укажем параметром -TargetForestCredential

1.1 Для всех топологий с несколькими лесами, содержащих Exchange 2007, необходимо, чтобы в каждом лесу сервера GC (Global Catalog) работали под управлением Windows Server 2003 SP1, а лучше SP2. Тоже самое касается исходных лесов AD, хотя бы один GC должен быть под управлением Windows Server 2003 SP1 или выше, иначе командлет Move-Mailbox не сможет перенести оттуда ящики.

1.2 Содержимое Deleted Items в почтовых ящиках обычно не перемещается, и по этому поводу существует инструкция: «Настройка сохранения удаленных почтовых ящиков и элементов»

2. На целевом сервере Exchange 2007, где будет выполняться командлет Move-Mailbox, нужно провести объявить переменную $SourceCredential, и присвоить ей текущую учетную запись админа, выполняющего миграцию.
$SourceCredential = Get-Credential
Будут запрошены учетные данные. Нужно указать учетную запись администратора исходной организации Exchange.

3. Там же на целевом сервере Exchange 2007, объявляем еще одну переменную – админа целевой организации, выполняющего миграцию.
$TargetCredential = Get-Credential
И вводим учетную запись администратора целевой организации.

4. Все там же на целевом сервере:
Move-Mailbox -TargetDatabase "Target ServerFirst Storage GroupMailbox
Database" -Identity SampleUser -GlobalCatalog GC1.targetdomain.ru
-SourceForestGlobalCatalog GC2.sourcedomain.ru -NTAccountOU
"OU=MigrationOU,DC=targetdomain,DC=ru" -SourceForestCredential
$SourceCredential -TargetForestCredential $TargetCredential

Параметры GlobalCatalog и SourceForestGlobalCatalog используются для определения местоположения почтового ящика в исходном лесу и в лесу назначения. Если не указан глобальный каталог исходного леса или конечного леса, лес локального компьютера, на котором запущена команда Move-Mailbox, будет использован для определения используемого сервера глобального каталога. Чтобы переместить почтовый ящик между разными лесами, необходимо указать хотя бы один из этих двух параметров.

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

4.1 Если следует сохранить политики получателя в почтовом ящике после его перемещения, используйте параметр:
. -IgnorePolicyMatch:$true

4.3 для сохранения квот на размеры почтовых ящиков после переноса:
. -PreserveMailboxSizeLimit $true

4.4
-ValidateOnly – проверить права на выполнение миграции ящиков.

4.5
-WhatIf – проверить правильность составления всей команды.

По умолчанию команда Move-Mailbox не удаляет ни исходный почтовый ящик, ни исходную учетную запись пользователя. Если вы перемещаете почтовый ящик пользователя в новый лес, причем учетная запись уже перемещена при помощи ADMT, и необходимо удалить и исходный почтовый ящик, и исходную учетную запись после перемещения почтового ящика
4.6 Операции с исходным ящиком:
-SourceMailboxCleanupOptions DeleteSourceNTAccount
DeleteSourceMailbox – удалить исходный ящик,
CreateSourceContact – удалить учетку и создать вместо нее контакт. Используется для перенаправления почты из старого домена в новый, в ящики на сервере Exchange 2007.
MailEnableSourceAccount – переделать mailbox-enabled user в mail-enabled user с хостингом почтового ящика на Exchange 2007 в целевом домене, разница с предыдущим ключом – сохраняются права пользователя в исходном домене.

5. Остается только проверить успешность переноса ящика на целевой сервер, любым удобным для вас способом – OWA, Outlook, ActiveSync итд.

Чаще всего переезд на новый домен Active Directory может потребоваться в случаях, когда на старом домене были допущены критические ошибки на этапе планирования или домен имеет фатальные повреждения.

Во втором случае все относительно понятно, а вот границы наступления первого для многих очень размыты. Это может быть например миграция с одноуровневого домена (single-label domain) или что-то другое. Ниже в статье постараюсь пролить свет на эти окутанные туманом рассуждения.

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.

Переезд на новый домен Active Directory

Эта статья представляет собой описание моего исключительно субъективного опыта и взгляда на ситуацию. Буду рад увидеть в комментариях ваши мнения и примеры из личного опыта.

Объективные причины

А может оставить все как есть?

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

Именно об этом варианте я и собираюсь рассказать на примере доведения до ума старого домена, который был поднят ещё на Windows Server 2000.

Задачи

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

Начнем разбор с самого начала.

Резервное копирование

Как правильно бэкапить виртуальные КД и КД вообще можно написать очень много статей и сценарии будут разными для разных версий ОС. Чтобы кратко ознакомиться с ситуацией, советую почитать статью в блоге 1 .

Выполняйте контрольное резервное копирование между важными изменениями в ядре инфраструктуры;
Сохраняйте резервные копии до тех пор, пока вы не убедитесь в нормальном функционировании всех КД;
Резервное копирование выполняйте поддерживаемыми средствами (например VSS);
Обязательно убедитесь, что вы имеете восстанавливаемые резервные копии! Да, забэкапить мало, надо ещё и проверить а восстанавливаются ли бэкапы нормально или нет.

Я советую все изменения обкатывать на тестовой инфраструктуре, которую вы как раз сможете создать из существующих бэкапов.

Диагностика AD

Обязательно пройдитесь по всем КД и проверьте состояние их здоровья:

Проанализируйте ошибки AD DS, DNS и др. служб в просмотре осбытий;
Проверьте репликацию 2 и состояние КД командами repadmin и dcdiag;
Установите все обновления ОС.

Только при отсутствии проблем приступайте ко всем изменениям.

Имя домена

Теперь суть вопроса: чтобы пользоваться красивыми именами и логиниться во все доменные сервисы по адресу электронной почты достаточно создать дополнительный UPN-суффикс и назначить его всем нужным учеткам. При этом неважно какое у вас имя домена. Для переезда в облако доп. суффиксов достаточно (если у кого сомнения, читайте Локальная инфраструктура и Azure AD)

Перенос DNS-зоны _msdcs.ForestName

Это первое, с чего я начал. Почему? Нужно привести DNS в нормальное состояние, ведь от этого сервиса зависит здоровье AD в целом.

Для доменов, созданных на Windows Server 2000, зона _msdcs.ForestName располагается на уровне домена и желательно её перетащить на уровень леса, как это по умолчанию сделано на новых доменах AD на Windows Server 2003 и старше:

Сам процесс подробно расписан в официальной документации и на моем блоге в статье DNS-зона _msdcs.ForestName отсутствует.

Изменения вполне можно проводить в рабочее время, но все же обкатайте все на лабе.

Настройка защищенных динамических обновлений DNS

Вероятнее всего большинство разрешают незащищенные обновления DNS 3 . Тем не менее, согласно лучшим практикам рекомендуется разрешать динамические обновления только для авторизованных клиентов 4 .

Раз уж вы решили привести домен к эталонному виду, займитесь и DNS-записями. Тем не менее, не включайте слепо защищенные обновления, возможно в вашей инфраструктуре есть устройства со статикой вне домена, которым необходимо обновлять записи самостоятельно.

Не забывайте, что вы можете настроить обновление клиентских DNS-записей на стороне DHCP-сервера, если он развернут на Windows Server. Изменения можно проводить в рабочее время (я бы даже сказал рекомендуется проводить в рабочее время), будет возможность оперативно отлавливать проблемы пользователей.

Настройка зон обратного просмотра

Изменения можно проводить в рабочее время.

Обновление уровней леса и домена

Нет никаких причин сидеть на старых уровнях леса и домена 5 и лишь ограничивать себя в функциональности AD. Например пользуйтесь корзиной AD 6 , повысив уровень леса до 2008 R2 и активировав соответствующую функцию.

Повысьте до максимально возможных значений уровни леса и домена (зависит от того на каких версиях ОС у вас работают КД) 7 . Задача относительно безболезненная, можно выполнять её в рабочее время.

Переезд с FRS на DFS-R

Уже с Windows Server 2008 FRS не считается надежной и устарела, а на дворе 2017 год. Смело переезжайте на DFS-R, к тому же последние на сегодняшний момент версии ОС уже перестали поддерживать FRS вообще (то есть даже новые КД на Windows Server 2016 в домен вам не запилить).

Процесс миграции очень хорошо документирован и на некоторых шагах есть возможность откатиться назад, читайте мою статью Заметки: Миграция репликации SYSVOL с FRS на DFS.

Процесс миграции вполне возможно проводить в рабочее время.

Настройка межсайтовой топологии (если актуально)

Вопрос актуален далеко не для всех, только у кого ядро инфраструктуры размазано между несколькими площадками.

Строго говоря, сайты можно и не создавать, если между локациями есть стабильный канал с достаточной пропускной способностью и пингом <10мс (пришлось перечитать много литературы, чтобы натолкнуться на эту рекомендацию).

Best practice

Если вы прошли путь, который я расписал выше и который проходил сам и хотите сделать ещё лучше, то предлагаю посмотреть в сторону лучших практик администрирования AD DS. Читайте дальше.

Удаление лишних ролей

Идея в том, чтобы построить ядро инфраструктуры из абсолютно идентичных друг другу контроллеров домена (кроме ip и ролей fsmo разумеется). В случае утери любого из них не надо заморачиваться с его восстановлением, просто вычистите его остатки из AD и заведите новый с нуля.

Все поворачивается к вам совсем другим местом, если у потерянного КД имелись какие-то важные данных (многие организации держат и файловые помойки, и терминальные серверы и многое другое на одиночных КД). Таким образом вы лишаете себя той гибкости, которая изначально была заложена в архитектуру AD DS.

Вот пример списка установленных ролей и компонентов с полностью чистого контроллера домена:

Одна и та же версия ОС

Эта рекомендация намного важнее, чем может показаться на первый взгляд. Дело в том, что для разных ОС совершенно разный порядок восстановления из резервных копий, особенно дело касается виртуализованных КД. Разумеется различаются и нюансы администрирования.

Выполняйте плановый вывод контроллеров домена на устаревших ОС.