В предлагаемой статье рассматриваются некоторые вопросы миграции AD и Exchange Server. Приведенные в статье процедуры — не единственный способ выполнить миграцию. На самом деле двух одинаковых миграций не существует. Моя задача — нарисовать общую картину и помочь организовать простую миграцию в тестовой среде. Прохождение по этапам процесса и знакомство с работой различных инструментов поможет спланировать переход в конкретных условиях.

Главное — планирование

Выполнить слияние двух доменов AD довольно просто; сделать это в активно используемой сети немного сложнее. Можно привести, например, такое сравнение. Заменить двигатель автомобиля довольно просто: процесс хорошо документирован, и соответствующие инструменты помогут справиться с задачей. Но как заменить двигатель в автомобиле, который движется со скорость 60 миль в час, причем сделать это так, чтобы пассажиры ничего не заметили?

Словом, без предварительного планирования нам ничего не добиться. Нельзя переоценить важность детального планирования при подготовке такого сложного проекта, как слияние компаний, особенно для задач с участием ИТ-подразделений. За пренебрежение планированием в конечном итоге придется заплатить. В планах необходимо предусмотреть:

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

Рассмотрим такой случай. Крупная компания New.com приобрела компанию Old.com меньшего размера. Предположим, что сетевые инженеры решили проблемы связи, применив VPN-туннель между сайтами, протокол Multiprotocol Label Switching (MPLS) или иное безопасное решение. Ни одно из названных мной мероприятий, разумеется, нельзя провести без объединения действующих сетей.

Простые шаги

На планирование и реализацию слияния AD и Exchange могут уйти месяцы — такая медлительность вряд ли понравится руководству компании. Другие подразделения также объединяют бизнес-процессы, и ИТ может оказаться узким местом. Чтобы сгладить переход, постарайтесь успешно реализовать простые шаги, чтобы создать впечатление объединенного предприятия.

Одна компания, одна электронная почта. Быстрый способ показать, что появилась единая компания — присвоить всем сотрудникам один суффикс электронной почты (например, new.com). В подробной статье Microsoft «How to share an SMTP address space in Exchange 2000 Server or in Exchange Server 2003» (support.microsoft.com/kb/321721) объясняется, как сформировать политику получателя, новый виртуальный SMTP-сервер в организации Exchange и контакты таким образом, чтобы система электронной почты выглядела единой для клиентов и внутренних пользователей. Построение аналогичной структуры в среде Exchange 2007 описано в статье «How to Configure Exchange 2007 to Route Messages for a Shared Address Space» (technet.microsoft.com/en-us/library/bb676395.aspx).

Как показано на рисунке, электронная почта для New.com по-прежнему направляется на существующий сервер электронной почты в штаб-квартире компании New.com. Сообщение, поступившее сотруднику Old.com на адрес New.com, перенаправляется сервером Exchange на почтовый сервер Old.com. Если сотрудник Old.com отправляет сообщение, первичный адрес (для ответа) — New.com. Конечная цель — направлять всю электронную почту в одну организацию Exchange, но описанный прием позволит выиграть время для проведения миграции.

Информация «свободен/занят». Для слияния компаний требуется безупречная связь всех сотрудников друг с другом, а для этого обычно приходится проводить очень много совещаний. К сожалению, по умолчанию отдельные организации Exchange не располагают общей информацией о календаре или занятости. Руководитель, который пытается назначить встречу с сотрудником другой компании, получает в Outlook знаки # вместо расписания удаленного пользователя.

Препятствие можно без труда обойти, организовав совместное использование информации «свободен/занят» в двух частях компании. Microsoft предоставляет бесплатный инструмент Inter-Organization Replication (www.microsoft.com/downloads/details.aspx?familyid=e7a951d7-1559-4f8f-b400-488b0c52430e), который реплицирует общие папки и информацию «свободен/занят». Инструмент не распознает кластеров, при его установке на узле кластера возникают ошибки, поэтому обладателям кластера Exchange потребуется автономный сервер Exchange для репликации. Назначая имя пользователя и пароль, не забудьте указать перед именем пользователя имя домена: DOMAIN\USERNAME.

Период актуальности информации «свободен/занят», реплицированной между организациями Exchange, может составлять до 30 минут; обязательно сообщите об этом пользователям. Приложение состоит из двух частей: программы Replication Configuration и службы Replication. В статье компании Microsoft «Installing, configuring, and using the InterOrg Replication utility» (support.microsoft.com/kb/238573) описаны этапы использования этого инструмента.

Доверительные отношения. Руководителям компании необходимо безопасно (и не всегда через электронную почту) обмениваться файлами данных — документами, электронными таблицами, презентациями и т. д. После объединения доменов процесс прост, но требуется решение для немедленного удовлетворения нужд бизнеса. Чтобы предоставить пользователю одного домена разрешение на использование ресурсов другого домена, необходимо организовать доверительные отношения для леса или домена. Далее в статье будет показано, как организовать простые доверительные отношения для леса.

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

На пути к миграции

После того как немедленные нужды бизнеса будут удовлетворены, требуется подготовить подробный план миграции домена AD и организации Exchange. Если имеется лишь несколько пользователей, компьютеров и серверов, то во многих случаях достаточно просто добавить эти объекты в домен с помощью сценариев и других методов. Но если домен более крупный, полезно подумать о применении сторонних инструментов. Такие поставщики, как Quest и NetIQ, выпускают продукты для оценки и даже моделирования миграции.

Возможно, вместо использования сторонних инструментов удастся обойтись бесплатной утилитой Active Directory Migration Tool (ADMT) компании Microsoft. Новейшая версия, ADMT 3.1, совместима с 64-разрядной средой; ее можно получить в центре загрузки Microsoft (www.microsoft.com/downloads/details.aspx?familyid=AE279D01-7DCA-413C-A9D2-B42DFB746059). В Exchange Server предусмотрен встроенный инструмент перемещения почтовых ящиков, но есть и инструменты независимых поставщиков. Далее в статье предполагается использование ADMT и встроенного инструментария Exchange, но общие подходы одинаковы для любых продуктов.

Полезный журнал SID

Если не удается полностью перенести все объекты в новый домен в течение нескольких часов, миграцию удобно разделить на несколько этапов. Некоторые пользователи и системные процессы могут продолжать работать из первоначальных доменов, а остальные будут перемещены в новый. При переносе учетных записей пользователей и групп копируются только имя объекта в новый домен; собственно, объекты совершенно новые; они получают новый идентификатор SID из нового домена. Проблемы могут возникнуть, когда пользователи с уже перенесенными учетными записями попытаются обратиться к ресурсам, которые остались в старом домене и не распознают нового идентификатора SID.

Одно из решений — задействовать SID History. Как показано на экране 1, пользователь в домене New.local, перенесенный из домена Old.local, имеет два идентификатора SID — новый, сформированный для домена New.local, и прежний, из старого домена, теперь атрибут SID History. Когда пользователь обращается к ресурсу в домене old.com, сервер файлов сопоставляет SID из домена old.com, и пользователю предоставляется доступ. Чтобы воспользоваться SID History, нужно отключить фильтрацию SID между доменами, чтобы идентификатор SID объекта мог быть перенесен в новый домен вместе с объектом. Этот процесс будет описан далее.

Экран 1. Новая учетная запись пользователя с двумя идентификаторами SID

Настройка разрешения имен и доверия лесов

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

Двусторонние доверительные отношения — обязательное условие миграции доменов. Доверительные отношения можно было установить раньше или же сделайте это сейчас. Перед созданием доверительных отношений оба домена должны иметь возможность разрешать полные имена (FQDN) в другом домене. Сопоставьте домены DNS с помощью вкладки Forwarders в диалоговом окне Properties сервера DNS. На экране 2 показана конфигурация, в которой компьютеры в домене New.local могут распознавать адреса компьютеров в домене Old.local. В итоге можно проверить связь с server1.old.local с любого компьютера в домене New.local.

Экран 2. Настройка серверов пересылки при запросах к DNS

Для подключения по имени к узлу в другом домене без использования FQDN добавьте оба домена (new.local и old.local) в окне настройки Advanced TCP/IP на каждом компьютере. Эта работа может быть утомительной, поэтому ее удобно выполнять с помощью групповой политики.

С помощью оснастки AD Domains and Trusts консоли Microsoft Management Console (MMC) создайте двусторонние доверительные отношения между доменами.

  1. Зарегистрируйтесь на контроллере домена (DC) в одном из доменов (любом) и откройте оснастку AD Domains and Trusts.
  2. Щелкните правой кнопкой мыши на домене и выберите пункт Properties.
  3. Щелкните на вкладке Trusts, выберите New Trust и нажмите Next.
  4. Введите имя FQDN другого домена: для этого нужно сначала правильно настроить серверы пересылки DNS.
  5. Выберите двусторонний тип доверительных отношений (Two-way).
  6. Выберите Both this domain and the specified domain на странице Sides of Trust, чтобы создать доверие одновременно из обоих доменов.
  7. Введите имя пользователя и пароль администратора другого домена, затем нажмите Next.
  8. Просмотрите настройки, затем нажмите кнопку Next.
  9. Щелкните Yes, confirm the outgoing trust, затем Yes, confirm the incoming trust, чтобы DC обеспечил корректные доверительные отношения.
  10. Нажмите кнопку OK, чтобы подтвердить сообщение о фильтрации SID; на следующем этапе фильтрация SID будет отключена.

Настройка службы Password Export Server

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

  1. Зарегистрируйтесь как администратор домена или пользователь с необходимыми правами на компьютере, на котором установлена программа ADMT.
  2. В командной строке создайте файл с расширением .pes с помощью команды ADMT:
              admt key/opt: create/sd: old/kf: c:\
  3. Скопируйте только что созданный pes-файл в DC в исходном домене (old.local).
  4. Установите Password Migration DLL на сервере Password Export Server (PES), запустив pwdmig.msi. PES можно получить из центра загрузки Microsoft; обязательно используйте PES из состава ADMT 3.1, если контроллеры домена — 64-разрядные. Установка PES проходит быстро, и по окончании появится запрос на созданный ранее pes-файл.
  5. Укажите, что служба Password Export Server запускается с правами администратора домена. Необходимо использовать формат domain\account.

После установки службы PES необходимо перезагрузить DC, поэтому учтите время простоя в своем плане. По умолчанию служба PES настроена на запуск вручную, поэтому она не запускается при перезагрузке сервера. Кроме того, необходимо изменить на 1 значение следующего параметра реестра типа DWORD: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\AllowPasswordExport. В целях безопасности, компания Microsoft рекомендует оставить службу PES отключенной, а параметру реестра присвоить значение 0, пока не будет достигнута готовность к миграции паролей. Дополнительные сведения можно найти в статье компании Microsoft «How to use Active Directory Migration Tool version 2 to migrate from Windows 2000 to Windows Server 2003» (support.microsoft.com/kb/326480).

Отключение фильтрации SID

Чтобы разрешить пересылку идентификаторов SID учетных записей пользователей и групп в обоих направлениях между доменами, нужно отключить компонент безопасности, именуемый SID filtering, в исходном домене. На DC в домене old.local domain введите команду

netdom trust old/domain: new
/quarantine: No
/UserD: Administrator
/passwordD: P@ssword

Вводить команду следует в одной строке. Если фильтрация SID отключена корректно, будет получено сообщение о прекращении фильтрации SID. Обратите внимание, что Netdom не устанавливается на серверах Windows 2003 и Windows 2000 по умолчанию, но находится на компакт-диске сервера в папке Support\Tools.

Создание сервера фильтрации

Проще выполнить миграцию с выделенного сервера. Он не обязательно должен быть мощным; достаточно простой виртуальной машины (VM) с Windows Server 2003 Standard. ADMT не функционирует с Windows XP. Сервер миграции должен быть членом целевого домена, New.com. Несмотря на доверительные отношения между двумя доменами, всегда регистрируйтесь в новом домене при переносе объектов из старой службы каталога в новую.

Еще один маленький, но важный шаг, который должен быть выполнен на старом домене перед переносом объектов в новый домен: добавьте учетную запись пользователя Domain Admins во встроенную группу Administrators в домене-источнике, как показано на экране 3.

Экран 3. Добавление целевой учетной записи пользователя Domain Admins в старый (исходный) домен

При установке ADMT на сервере миграции существует два варианта хранения данных миграции. Для миграции среднего масштаба можно выбрать бесплатный продукт SQL Express или использовать более мощную версию SQL Server для сложных проектов. Выбор зависит от конкретных обстоятельств. В целях упрощения примера в данной статье используется SQL Express.

Подготовка компьютеров и нового домена для миграции

Последний шаг в подготовке среды для миграции — убедиться в готовности собственно компьютеров. В новых версиях Windows используется брандмауэр, который блокирует попытки подключения со стороны ADMT. В документации мало сведений об используемых ADMT портах. Однако можно отключить брандмауэр XP как раз на время миграции. Для этого создайте объект групповой политики (GPO), который открывает брандмауэр и связывает его с организационной единицей (OU), именуемой MigrationPrep, а затем переместите компьютер в эту OU непосредственно перед миграцией. Также убедитесь, что целевая OU готова и применены все необходимые объекты GPO.

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

В руководстве по ADMT компании Microsoft (его можно получить в центре загрузки Microsoft) отмечается, что все целевые домены должны работать на собственном функциональном уровне Windows 2000, уровне Windows Server 2003 или функциональном уровне Windows Server 2008. Процесс необратим, поэтому убедитесь, что понимаете последствия, прежде чем поднимать функциональный уровень. Чтобы поднять уровень домена, откройте оснастку AD Users and Computers консоли MMC, щелкните правой кнопкой мыши на имени домена (new.local) и выберите команду Raise Domain Functional Level. На следующем экране выберите Windows Server 2003 и нажмите OK.

Подготовка и еще раз подготовка

Даже обычная подготовка к миграции AD может быть сложным процессом. Рекомендуется опробовать его в тестовой среде. Во второй части статьи будет показано, как перенести в новый домен учетные записи пользователей, компьютеры и группы. Кроме того, мы рассмотрим задачу миграции Exchange.

Эрик Ракс (ebrux@mvps.org) — старший администратор сети Windows в крупной консалтинговой компании

Рисунок. Маршрутизация электронной почты с использованием общего адресного пространства