понедельник, 13 сентября 2010 г.

Миграция домена ADMT 3.2

Небольшая инструкция по миграции домена с использованием Active Directory Migration Tool версии (ADMT) 3.2.
Статья ещё в разработке и постоянно пополняется.

Дано: 2 домена в разных лесах- source.local, target.local. Уровень работы обоих лесов 2003 native.
В целевом домене есть КД с win 2008R2. В исходном домене поднят Project Server, в целевом - SharePoint.
Необходимо: произвести миграцию пользователей из source.local в target.local. При этом должны сохраниться права доступа к ресурсам, права к записям SharePoint и ProjectServer. Так же по возможности должны быть перемещены профили (локальные) для прозрачности перехода в новый домен для пользователей. Так же должен использоваться DHCP сервер целевого домена.

Решение:
Миграция пользователей и групп будет осуществляться с помощью утилиты ADMT 3.2 - согласно рекомендациям компании Майкрасофт, в случае если в целевом домене используется КД на базе ОС win 2008 R2 следует использовать данную версию утилиты ADMT).
Из постановки задачи видно, что миграция должна осуществляться с использованием истории SID, для сохранения прав доступа.
Настройка доверительных отношений.
Прежде всего необходимо настроить доверие между доменами. Открываем оснастку "Active Directory Domains and trusts". Правой кнопкой по названию домена - свойства.
В открывшемся окошке переходим на вкладку "Trusts"
По нажатию кнопки внизу окна "New Trust" начинаем создание доверительных отношений между доменами.
В первом окошке указываем имя домена, с которым хотим наладить "дружбу". ....(требуется дописать)
Вносим учётную запись целевого домена, под которой будет осуществляться миграция, в группу администраторов домена источника.
Настройка DNS.
Так же необходимо настроить DNS сервера доменов. Один из вариантов - расположить вторичные зоны (secondary) перекрёстно друг к другу: зону source.local в DNS target.local, зону target.local - в DNS source.local. Мной использовался так же вариант - перекрёстных зон заглушек (stub zone).

Установка ADMT
Для начала выясним какая версия утилиты ADMT требуется, исходя из следующей таблицы:

Версия ADMT
Платформа 
для
установки
Требования к домену-источнику (source domain)
Требования к целевому домену (target domain)
Поддерживаемые
платформы для миграции
Win Server 2003
Домен-источник может содержать КД под управлением  Windows NT, Windows 2000 Server, или Windows Server 2003. 
Нет требования к уровню работы домена.
Минимальный уровень целевого домена Windows 2000 native.
Windows 2000 Professional, Windows XP, Windows NT 4, Windows 2000 Server, и Windows Server 2003.
Windows Server 2008
Домен-источник может содержать КД под управлением Windows 2000 Server, Windows Server 2003, или Windows Server 2008. Нет требований к режиму работы домена, но ADMT v3.1 не может использоваться для миграции из Win NT4 домена.
Минимальный уровень работы целевого домена -Windows 2000 native.
Если целевой домен содержит КД под управлением Windows Server 2008 R2, необходимо использовать ADMT v3.2.
Для получения более полной информации ознакомьтесь с записью Базы Знаний Microsoft article 976659 .
Windows 2000 Professional, Windows XP, Windows Vista, Windows 2000 Server, Windows Server 2003, и Windows Server 2008.
Windows Server 2008 R2
Минимальный уровень работы домена-источника-Windows Server 2003.
Минимальный уровень работы целевого домена-Windows Server 2003.
Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, и Windows Server 2008 R2.

Дальнейшее описание основывается на использовании версии 3.2, т.к. в целевом домене присутствует КД (контроллер домена) под управлением ОС Windows Server 2008R2.
 Более подробно установка PES будет рассмотрена далее.
Active Directory Migration Tools версии 3.2, в отличи от предшествующих версий данной утилиты, требует установленного MSSQL сервера (может использовать издание Express). Подходят MSSQL 2005 SP3 и 2008 SP1, что примечательно с версией MSSQL 2008R2 утилита работать не может. Останавливаться подробно на развёртывании SQL сервера не буду, т.к. подходят параметры по-умолчанию. Дальнейшее описание основывается на использовании Win Server 2008R2 и MSSQL 2005 Std SP3 (просто был дистриб под рукой). Установка ADMT довольно простая, лишь пара вопросов мастера установки. Единственное что может вызвать сложность - указать базу для работы: не смотря на то что в текстовой подсказке указано ".\SQLExpress" по дефолту, у меня подключилось как просто "localhost", без указания инстанса.
Устанавливать утилиту необходимо в целевой домен.
Если в исходном домене присутствуют ПК, под управлением ОС Windows XP, Vista (до SP1), 2000, а КД целевого домена под управлением ОС Windows 2008 и выше, то необходимо на каждом контроллере целевого домена исправить (создать) ключ реестра:
HKLM\System\CurrentControlSet\Services\Netlogon\Parameters
ключ : AllowNT4Crypto 
тип: REG_DWORD
значение: 1. 
Включение политики аудита.
Так же необходимо настроить политику аудита в обоих доменах.
Для этого править групповую политику Default Domain Controller Policy: Computer Configuration-Polices-Windows settings-Security-Local-Audit
Устанавливаем политики "Audit account management" в Success и Failure, и "Audit directory service access" в Success.
Выключение фильтрации SID:
Выполняется в обоих доменах, во избежании возможных проблем при переносе истории SID.
Netdom trust TrustingDomainName /domain: TrustedDomainName /quarantine:No /userD:domainadministratorAcct/passwordD:domainadminpwd
Т.е. в нашем случае:
Netdom trust target.local /domain: source.local /quarantine:No /userD:administrator/passwordD:Pass
Более подробно о фильтрации SID можно посмотреть тут

Утилита Netdom входит штатно в windows 2008, для windows 2003 утилита входит в состав Windows 2003 Tools.


Установка PES
Для миграции паролей требуется утилита Password Export Server (PES) версии 3.1 (для всех версий утилиты ADMT). Скачать можно с офф.сайта Microsoft. Устанавливать в домене-источнике (source.local), используя при установке ключ, сгенерированный на компьютере целевого домена, на котором установлена утилита ADMT.
Генерируем ключ командой admt,
admt key /option:create /sourcedomain:<SourceDomain> /keyfile:<KeyFilePath> /keypassword:{<password>|*
Получившийся файл переносим на КД в исходном домене. При установке PES указываем путь на этот файл, и пароль, если указывали его при генерации ключа. Появляется служба с ручным режимом запуска. Рекомендуется запускать её только при миграции.


Права и ограничения
Для миграции компьютеров и локальных профилей пользователей утилите ADMT необходимы права администратора в исходном домене. Проще всего распространить групповую политику на добавление группы Domain admins целевого домена в локальную группу администраторов:

Создаём групповую политику, в редакторе переходим к пункту Computer conf.-Windown Settings- Security Settings-Restricted Groups. Клик правой кнопкой - добавить группу - вносим Administrators. В члены данной группы заносим Domain admins обоих доменов. ВНИМАНИЕ: данная политика заменит содержимое локальной группы Администраторы на указанные в политике (в рассмотренном случае - source\Domain Admins; targer\Domain Admin) плюс локальная запись Администратор. Всё остальные пользователи из неё убираются.
Так же рекомендуется для Windows XP выключить брандмауэр (firewall). Сделать это можно так же через групповую политику.


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

В исходном домене создаём локальную группу source_domain$$ (в нашем случае группа будет называться source$$). Не добавляйте в неё пользователей! Эта группа нужна для инициализации миграции, и проверки миграции SID.
  Открываем консоль ADMT. В открывшейся оснастке правой кнопкой на Active Directory Migration Tools - Group Account Migration Wizard.


Wizard page
Action
Domain Selection
Выбираем домены. В Source domain соотв. исходный, в target - целевой.
Group Selection
Выбираем "выбрать группы из домена" (Select groups from domain). В следующем пункте выбираем созданную группу source$$$.
Organizational Unit Selection
Выбираем подразделение в целевом домене, куда будет помещен объект миграции. Рекомендую создать отдельное подразделение, и все перенесённые объекты складывать в него.
Group Options
Отмечаем пункт "Migrate Group SIDs to target domain"
С остальных пунктов пометку выбора снимаем.
User Account
Вводим логин-пароль учётной записи с правами администратора в исходном домене.
Conflict Management
Выбираем "Do not migrate source object if a conflict is detected in the target domain".

После миграции просматриваем лог на предмет ошибок и предупреждений (не ленимся). Проверяем пункт "Migrate Security Identifiers" - должен стоять yes.

В логах может встретиться предупреждение о несовпадении схем доменов, и то что некоторые атрибуты не перенесутся. Это получается из-за несовпадений схемы :) в моём случае схема одного из доменов была расширена Exchange сервером. Вообщем не критично, но лучше сразу убедиться что вызывает данное предупреждение.

Миграция служебных учётных записей
Мастер миграции служебных записей (Service Account Migration Wizard) проверяет серевера, указанные администратором, на наличие служб, работающих под доменным учётными записями. Пароли таких записей не мигрируют. Для миграции: в оснастке ADMT выбираем пункт Service Account Migration Wizard. Далее выполняем следующую последовательность действий:

Wizard page
Action
Domain Selection
Выбираем домены. В Source domain соотв. исходный, в target - целевой.
Update Information
Выбираем Yes, update the information.
Computer Selection Option
Выбираем Select computers from domain. В пункте Service Account Selection, добавляем учётные записи из исходного домена, которые хотим мигрировать.
Agent Dialog
В открывшемся окне Agent Actions, выбираем пункт Run pre-check and agent operation, и запускаем Start. После окончания обязательно просмотреть лог миграции и Agent Detail на наличие ошибок и предупреждений.
Service Account Information
Выбираем любые учётные записи, которые не были отмечены как служебные, и жмём Skip/Include
Completing the Service Account Migration Wizard
Завершаем миграцию, нажатием Finish.

Миграция групп
Следующим этапом идёт миграция глобальных групп. (стоит сразу отметить, что встроенные группы не мигрируют). При дальнейшей миграции пользователей, членство в группах будет восстановлено автоматически.
Для миграции так же, как и в прошлых пункатх, открываем ADMT, выбираем "Group Account Migration Wizard". Далее действуем согласно таблице:

Wizard page
Action
Domain Selection
Выбираем домены. В Source domain соотв. исходный, в target - целевой.
Group SelectionВыбираем "Select groups from domain". Добавляем группы для миграции
Organizational Unit Selection
Выбираем подразделение в целевом домене, куда будут помещены группы после миграции.
Group Options
Выбираем "Migrate Group SIDs to target domain", с остальных пунктов необходимо снять галочки выбора.
User Account
Указываем учётные данные пользователя, имеющего права администратора в исходном домене.
Conflict Management
Выбираем пункт "Do not migrate source object if a conflict is detected in the target domain" (не мигрировать, в случае обнаружения конфликтов с объектами целевого домена).
После завершения работы мастера, изучаем лог на предмет ошибок. Принимаем меры, при необходимости. Мигрированные группы должны появиться в указанном подразделении в целевом домене.

Миграция учётных записей пользователей
Для миграции пользователей с переносом истории SID необходимо предварительно мигрировать все учётные записи. При этой миграции, учётные записи переносятся отключенными, со сгенерированным паролем. Пользователи продолжают использовать учётные записи в исходном домене. В дальнейшем будет произведена повторная миграция пользователей, но уже с необходимыми атрибутами.
    Открываем консоль ADMT, выбираем пункт "User Account Migration Wizard". Далее, согласно таблице:

Wizard page
Action
User Selection
Выбираем "Select users from domain", далее добавляем пользователей.  На следующей странице выбираем подразделение, куда разместить учётные записи после миграци.
Password Options 
Выбираем пункт "Do not update passwords for existing users" и "Generate complex passwords", для генерации пароля.
Account Transition Options
В "Target Account State" отмечаем "Disable target accounts", для отключения перенесенных записей в целевом домене. Включаем опцию "Migrate user SIDs to target domains"
User Options
Отмечаем пункты "Translate roaming profiles" и "Fix users’ group memberships", с остальных пунктов галочку снимаем.
Object Property Exclusion и Conflict Management
Снимаем галочку "Exclude specific object properties from migration". 
Conflict ManagementВыбираем пункт "Do not migrate source object if a conflict is detected in the target domain."

Перенос локальных профилей
Перед миграцией ПК, необходимо перенести локальные профили пользователей. На данном этапе целесообразно выделить группы пользователей, отражающих порядок миграции. Дальнейшие этапы мигарции проводить не над всем списком пользователей, а над этими группами.
На момент переноса профилей, и миграции ПК не должно быть активных пользовательских сессий. Для переноса (трансляции) профилей: в оснастке ADMT, выбираем пункт "Security Translation Wizard"
Wizard page
Action
Computer Selection
Выбираем пункт "Select from domain", и добавляем необходимые ПК, согласно группе миграции.
Translate Objects
Отмечаем пункт "User Profiles"
Security Translation Options
Отмечаем пункт "Replace"
Заканчиваем wizard
Заканчиваем wizard, жмём Готово. После закрытия мастера откроется окно Агента ADMT
ADMT Agent Dialog
Выбираем пункт "Run pre-check and agent operation" и запускаем
Настройки ADMT Agent При необходимости, можно предварительно запустить проверку Precheck, если нет уверенности в доступности ПК.
После завершения работы мастера и агента, просматриваем логи Агента на наличие ошибок.

Миграция ПК
После переноса профилей, следующим этапом будет миграция ПК в новый домен. Во время миграции на ПК не должно быть активных пользовательских сессий. В процессе миграции компьютер будет перезагружен.
Открываем ADMT, выбираем пункт Computer Migration Wizard

Wizard page
Action
Computer Selection и Organization Unit
Выбираем пункт "Select from domain", и добавляем необходимые ПК, согласно группы миграции. (те же пк, что и в прошлом пункте). Переходим на следующий пункт и выбираем подразделение, куда будут помещены компьютеры.
Translate Objects и Security Translation Options
Выбираем Локальные группы, и Права пользователей. В следующем пункте выбираем "Add"
Computer Options
В данном пункте выбираем, через какое время, после работы мастера, ПК будет перезагружен. По-умолчанию 5 минут.
Object Property Exclusion
В данном пункте можно выбрать, какие параметры схемы исключить из миграции.
Conflict Management
Выбираем пункт "Do not migrate source object if a conflict is detected in the target domain", дабы исключить перезапись объектов, если они уже существуют.
ADMT Agent DialogВыбираем пункт "Run pre-check and agent operation" и запускаем
После завершения работы мастера и агента, проверяем их лог файлы на наличие ошибок, и корректность переноса. В ходе работы агента, компьютер будет автоматически перезагружен, и включен в целевой домен.

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

Wizard page
Action
Выбор пользователей и OU для миграции
Выбираем пункт "Select from domain", и добавляем необходимые учётные записи, согласно группы миграции. (те же пк, что и в прошлых пунктах). Переходим на следующий пункт и выбираем подразделение, куда будут помещены компьютеры.
Параметры пароля
Отмечаем пункт Migrate Password.
Указываем сервер PES (настраивали в прошлых пунктах)
Account Transition Options
На данном пункте оставляем целевую учётную запись включенной (Target Account), исходную учётную запись выключаем (Source), либо указываем через сколько дней её отключить.
Отмечаем пукнт "Migrate user SIDs to target domain", для копирования истории SID в целевой домен.
Параметры пользователя
Указываем учётную запись, из под которой будет осуществляться доступ в исходный домен. Переходим на следующий пункт "User options", отмечаем пункты "Translate roaming profiles" (перенос перемещаемых профилей), "Update user rights" (обновление прав пользователей), "Fix users’ group memberships" (исправить членство в группах). Убрать галочку с пункта "Migrate associated user groups".
Object Property Exclusion
Убрать галочку "Exclude specific object properties from migration"
Conflict Management
Отмечаем пункт Migrate and merge conflicting objects. (мигрировать и объединить конфликтующие объекты)
Убираем галочки с пунктов "Before merging remove user rights for existing target accounts" (перед объединением (слиянием) - очистить матрицу прав пользователя), и "Move merged objects to specified target Organizational Unit" (переместить объект после объединения в указанное организационное подразделение).
Миграция серверов
Необходимый шаг в миграции домена. Порядок и расписание миграции необходимо продумывать с особой тщательностью, дабы избежать возможных проблем с недоступностью сервисов.
     Рекомендуемая практика: перенос серверов после миграции пользователей и ПК, но следует осознавать, что это лишь общая рекомендация. Пример из практики: исходя из некоторых соображений, перед миграцией пользователей, вначале была выполнена миграция сервера Project .
Перенос любого сервера требует индивидуального подхода и внимания к деталям (как пример - перенос MSSQL сервера в составе других служб).
Примеры переноса различных сервисов будут рассмотрены в следующих заметках. 

Заключение
В данное заметке рассмотрена процедура миграции пользователей, групп, ПК из исходного домена, в целевой, с помощью утилиты ADMT 3.2., рассмотрены основы работы с утилитой.

21 комментарий:

  1. Добрый день!
    Огромное спасибо Вам за статью, очень помогла во многих настройках. Делал всё как в статье, ошибок при настройке не возникало.
    К сожалению, меня преследует одна и та же ошибка при попытки миграции локальных профилей и компьютеров.
    Не сталкивались с такой проблемой? Или быть может знаете, в чём причина?
    http://s1.ipicture.ru/uploads/20120531/vx81REzK.jpg
    Спасибо!

    ОтветитьУдалить
  2. Этот комментарий был удален автором.

    ОтветитьУдалить
  3. Павел, спасибо, хорошая статья. Но у меня есть что дополнить/поправить для последующих «системных миграторов» :-) И хотелось бы, чтоб вы дополнили свою статью. На авторство я не претендую. Мне важнее, чтоб у последователей всё гладко проходило.
    Во-первых, на офф.сайте есть замечательное руководство пользователя на 260 стр. http://download.microsoft.com/download/c/2/a/c2a8ad1d-5ad8-4d4b-9bdd-7583e409896d/ADMTmigguide.doc
    И ознакомление с ним будет совсем не лишним.
    Дальше. Группа SourceDomain$$$ делается именно с тремя знаками доллара. У вас в одном месте с двумя, в другом с тремя. В-третьих эта группа создается не для "инициализации миграции", как написано у вас, а для включения аудита и дальнейшей проверки благополучной миграции SID. В-четвертых, SQL Express лучше использовать 2005(SP3). По крайней мере с ним ADMT устанавливается без вопросов. Можно, конечно, воспользоваться SQL Express 2008 (SP1), но тогда потребуются доп.телодвижения по подготовке экземпляра базы SQL для процедуры миграции. Все манипуляции с базой, разумеется, описаны в указанном выше руководстве. Более того, не подготовивши базу в SQLExpress2008(SP1) мы не сможем даже установить ADMT. Установщик не находит нужный ему экземпляр базы данных. Короче, чтобы не заморачиваться, лучше всё-таки SQLExpress2005SP3.
    И последнее, что хотелось бы отметить, это то, что параметр AllowNT4Crypto нужно править на эмуляторе PDC; это становится важно в тех случаях, когда контроллеров в исходном домене больше одного. Определить PDC легко с помощью команды: nltest.exe /dcname:[sourcedomain]

    ОтветитьУдалить
  4. Ещё несколько дополнений:
    1.Администратора целевого домена, от которого будет происходить миграция надо добавить в группу «Build-in\Администраторы» в исходном домене;
    2.Служба PES в домене исходнике должна стартовать от имени этого админа, которого мы сделали в п.1;
    3.Целевому админу надо делегировать право «Миграции истории SID». Для этого заходим в «AD - Пользователи и компьютеры». Правый щелчок на корень доменного дерева, там «Делегирование управления». Стартует мастер делегирования. В нём на первом шаге «Далее», на втором выбираем нужного нам админа, на третьем шаге «Создать особую задачу для делегирования», на четвертом переключатель в верхнем положении «этой папки, существующим в ней объектам ...», а вот на пятом шаге нужно поставить птичку на пункте «Миграция журналов SID»;
    4.В некоторых случаях, в дополнение к «Отключению фильтрации SID», которая, кстати, должна делаться в обеих доменах, требуется ещё включить «SID History on a trust». Для этого надо в обеих доменах выполнить команду:
    netdom trust {FQDN.domain.name} /domain:{FQDN.domain.name} /enableSIDhistory:yes
    Здесь повнимательнее, чтоб не перепутать имена исходного и целевого домена в этой команде. Если команда выполняется на исходнике, то на первом месте идет исходник, на втором идёт целевой домен. На втором домене всё наоброт. Сперва указывается целевой, потом исходный.

    ОтветитьУдалить
  5. я правильно понял, что при миграции домена все локальные настройки - раб стол, документы все будут перенесены автоматом?
    собираемся просто переводить на новый домен 150 пк, хотели выходить в НГ празники и вручную кажд комп обходить и переводить.

    ОтветитьУдалить
  6. Термин "перенесены автоматом здесь неуместен". Дело в том, что при миграции, отдельно мигрируются пользователи, отдельно группы, отдельно компьютеры. Это совершенно не связанные процессы. И можно мигрировать одно и не мигрировать другое. То есть админ сам выбирает, что ему надо мигрировать, а что нет. Так вот, при миграции компьютеров там заложен механизм, чтоб профиль пользователя подхватывался старый, а пользователь при
    этом находится уже в новом домене. Но для этого надо обладать админскими правами на клиентских компьюерах, потому как ADMT сама переводит из домена в домен и перегружает клиента. И ещё одно замечание. Подхватывание профиля у меня, например, не всегда корректно отрабатывало. В некоторых случаях приходилось руками подкладывать профиль. Закономерность я не уловил. Но что-то мне кажется, что пользователь на своем компьютере должен обладать админскими правами, по крайней мере при первом входе после миграции в новый домен.
    Управлять профилями проще всего через реестр hklm\software\microsoft\window nt\profilelist

    ОтветитьУдалить
  7. ок. спасибо.
    вы переносили в домен на win2008, а с какого?
    мы с 2003 попытаемся.

    ставим на целевом 2008 admt3.2., на 2003 ничего не надо ставить?
    доверит отношения настроены.
    после переноса пользователей, компьютеров, групп, на клиентской любой машине просто надо будет выбрать новый домен из списка и все, в случае удачной миграции, будет ок?

    ОтветитьУдалить
  8. Я мигрировал между двумя доменами 2008R2. Причем домены не связанные. То есть НЕ в рамках одного леса. Поэтому в моем случае потребовалась PES. В вашем случае 2003 ровным счетом ничего не значит. Миграция будет идти нормально.
    На клиенте, после миграции пользователя и компютера, да в свиске выбирается новый домен и вперед...

    ОтветитьУдалить
  9. дико извиняюсь, сколько весит admt3.2?
    версия 3.1 весит 60мб, а 3.2 скачивается на 4мб и не устанавливается - пишет,что не является приложением Win32

    ОтветитьУдалить
  10. У меня 4'325'656 байт. md5: 3cbf097a805556ca86f2a34aa5909778

    ОтветитьУдалить
  11. Подскажите пожалуйста. подойдет ли данное руководство для решения задачи миграции данной схемы?
    Исходный: система WinSRV2003, имя домена: source.domain.lan - Целевой: система WinSRV2008R2, имя домена: target.local. Опасение вызывает то. что исходный домен, третьего уровня.
    Спасибо.

    ОтветитьУдалить
  12. Вложенность домена абсолютно не играет роли.

    ОтветитьУдалить
  13. Noxyron
    ...Но что-то мне кажется, что пользователь на своем компьютере должен обладать админскими правами, по крайней мере при первом входе после миграции в новый домен...

    Не нужны админские права. Если профиль не подхватился. - или их много было на машине (бывает, что транслирует несколько первых, а остальные - "ленится". И даже ошибок не выдает при этом), или профиль пользователя подгружен был во время трансляции, - не любит ADMT открытых файлов. Лучше пользователя разлогинивать перед трансляцией. И можно ещё разделить процессы трансляции (занимает плохо предсказуемое время) и собственно миграции.

    ОтветитьУдалить
  14. А где взять ADMT? Ни одна ссылка не работает. Нет версии выше 2.0 на сайте Microsoft. А потому получается что и статья эта на данный момент бесполезна.

    ОтветитьУдалить
  15. ADMT v3.2 can be downloaded from Microsoft Connect (http://go.microsoft.com/fwlink/?LinkId=401534).

    ОтветитьУдалить
  16. Очень хотелось бы почитать про дополнительную миграцию почтового сервера, в связи с миграцией домена.

    ОтветитьУдалить
  17. Благодарю за статью и дополнения в комментариях.
    Чувствую уже очень скоро все это мне пригодится :)

    ОтветитьУдалить
  18. Спасибо за статью. Мигрировал 2008R2 в 2008R2. Возникла проблемы с правами на профиль пользователя. Этот пункт нужно делать после миграции компьютера, а не до, как он стоит в инструкции иначе возникает ошибка:
    "ERR2:7666 Unable to access server service on the machine 'source.domain'. Make sure netlogon and workstation services are running and you can authenticate yourself to the machine. hr=0x800706ba. The RPC server is unavailable."

    ОтветитьУдалить
  19. Есть необходимость мигрировать с AD Windows SBS 2003 в 2008 (ну или в 2012)
    С помощью ADMT удастся это сделать? То есть перенести нужно только сам сервер и службы DNS и DHCP.

    ОтветитьУдалить
  20. Есть два интересных момента!
    1) При миграции нет ошибок, но пользователи с 2003 леса при миграции в 2008 лес теряют атрибут почтового адреса! Я просто ума не приложу, почему у пользователя исчезает емейл...у меня на этом вся ЛДАП адресная книга в компании построена!
    2) У меня почтовый сервер создаёт ящики по ЛДАП, доменов на сервере несколько. Распознавание принадлежности пользователей к доменам осуществляется с помощью UPN самих пользователей. Но! При переносе, как на зло!, Выбирается не тот UPN для всех мигрировавших.
    Что и как можно сделать в этих случаях, подскажите! Ну очень много ручной работы будет в ином случае.

    ОтветитьУдалить