MKB phpBB

Источник: http://www.osp.ru/win2000/2009/11/13000860/
Источник: http://www.osp.ru/win2000/2010/02/13001755/
Windows IT Pro/RE № 11 за 2009 год

Объединение разнородных доменов Active Directory

При слиянии компаний этап планирования процесса объединения AD становится решающим для успеха
Эрик Ракс (ebrux@mvps.org) — старший администратор сети Windows в крупной консалтинговой компании

В современном бизнесе слияния и поглощения компаний происходят постоянно. Сегодня администратор отвечает за домен Active Directory (AD) и организацию Microsoft Exchange Server, а завтра ему приходится решать задачу слияния двух предприятий. Как приступить к ней?
В предлагаемой статье рассматриваются некоторые вопросы миграции 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» (https://support.microsoft.com/kb/321721) объясняется, как сформировать политику получателя, новый виртуальный SMTP-сервер в организации Exchange и контакты таким образом, чтобы система электронной почты выглядела единой для клиентов и внутренних пользователей. Построение аналогичной структуры в среде Exchange 2007 описано в статье «How to Configure Exchange 2007 to Route Messages for a Shared Address Space» (https://technet.microsoft.com/en-us/lib ... 76395.aspx).

Как показано на рисунке, электронная почта для New.com по-прежнему направляется на существующий сервер электронной почты в штаб-квартире компании New.com. Сообщение, поступившее сотруднику Old.com на адрес New.com, перенаправляется сервером Exchange на почтовый сервер Old.com. Если сотрудник Old.com отправляет сообщение, первичный адрес (для ответа) — New.com. Конечная цель — направлять всю электронную почту в одну организацию Exchange, но описанный прием позволит выиграть время для проведения миграции.
Информация «свободен/занят». Для слияния компаний требуется безупречная связь всех сотрудников друг с другом, а для этого обычно приходится проводить очень много совещаний. К сожалению, по умолчанию отдельные организации Exchange не располагают общей информацией о календаре или занятости. Руководитель, который пытается назначить встречу с сотрудником другой компании, получает в Outlook знаки # вместо расписания удаленного пользователя.
Препятствие можно без труда обойти, организовав совместное использование информации «свободен/занят» в двух частях компании. Microsoft предоставляет бесплатный инструмент Inter-Organization Replication (http://www.microsoft.com/downloads/deta ... 8b0c52430e), который реплицирует общие папки и информацию «свободен/занят». Инструмент не распознает кластеров, при его установке на узле кластера возникают ошибки, поэтому обладателям кластера Exchange потребуется автономный сервер Exchange для репликации. Назначая имя пользователя и пароль, не забудьте указать перед именем пользователя имя домена: DOMAIN\USERNAME.
Период актуальности информации «свободен/занят», реплицированной между организациями Exchange, может составлять до 30 минут; обязательно сообщите об этом пользователям. Приложение состоит из двух частей: программы Replication Configuration и службы Replication. В статье компании Microsoft «Installing, configuring, and using the InterOrg Replication utility» (https://support.microsoft.com/kb/238573) описаны этапы использования этого инструмента.
Доверительные отношения. Руководителям компании необходимо безопасно (и не всегда через электронную почту) обмениваться файлами данных — документами, электронными таблицами, презентациями и т. д. После объединения доменов процесс прост, но требуется решение для немедленного удовлетворения нужд бизнеса. Чтобы предоставить пользователю одного домена разрешение на использование ресурсов другого домена, необходимо организовать доверительные отношения для леса или домена. Далее в статье будет показано, как организовать простые доверительные отношения для леса.
Можно найти и другие быстро и просто решаемые задачи. Выслушайте пожелания сотрудников и предложите решения, чтобы выиграть время для тщательного планирования полной миграции, одновременно помогая выполнить переход остальным подразделениям компании.

На пути к миграции
После того как немедленные нужды бизнеса будут удовлетворены, требуется подготовить подробный план миграции домена AD и организации Exchange. Если имеется лишь несколько пользователей, компьютеров и серверов, то во многих случаях достаточно просто добавить эти объекты в домен с помощью сценариев и других методов. Но если домен более крупный, полезно подумать о применении сторонних инструментов. Такие поставщики, как Quest и NetIQ, выпускают продукты для оценки и даже моделирования миграции.
Возможно, вместо использования сторонних инструментов удастся обойтись бесплатной утилитой Active Directory Migration Tool (ADMT) компании Microsoft. Новейшая версия, ADMT 3.1, совместима с 64-разрядной средой; ее можно получить в центре загрузки Microsoft (http://www.microsoft.com/downloads/deta ... 2DFB746059). В 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 объекта мог быть перенесен в новый домен вместе с объектом. Этот процесс будет описан далее.

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

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

• Зарегистрируйтесь на контроллере домена (DC) в одном из доменов (любом) и откройте оснастку AD Domains and Trusts.
  Щелкните правой кнопкой мыши на домене и выберите пункт Properties.
  Щелкните на вкладке Trusts, выберите New Trust и нажмите Next.
  Введите имя FQDN другого домена: для этого нужно сначала правильно настроить серверы пересылки DNS.
  Выберите двусторонний тип доверительных отношений (Two-way).
  Выберите Both this domain and the specified domain на странице Sides of Trust, чтобы создать доверие одновременно из обоих доменов.
  Введите имя пользователя и пароль администратора другого домена, затем нажмите Next.
  Просмотрите настройки, затем нажмите кнопку Next.
  Щелкните Yes, confirm the outgoing trust, затем Yes, confirm the incoming trust, чтобы DC обеспечил корректные доверительные отношения.
  Нажмите кнопку 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» (https://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.

При установке 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.

Переходим непосредственно к слиянию сетей Active Directory (AD) и Exchange Server, которые эксплуатировались в двух компаниях.
Миграция пользователей и компьютеров
Администраторы, выполнившие всю подготовительную работу, описанную в первой части статьи, готовы к перемещению объектов AD из домена Old.local в домен New.local. Это важно делать не торопясь, у вас должно быть достаточно времени для решения всех возникающих проблем. Подготовьте все необходимое и начните с миграции собственных данных, затем переместите других пользователей и компьютеры ИТ-подразделения. Если вы начнете с себя, то сможете устранить все несообразности до того, как в процесс миграции будут вовлечены данные остальных сотрудников компании.
В ходе первой попытки перенести объект из одного домена в другой средство миграции AD Active Directory Migration Tool (ADMT) сообщит вам о некоторых дополнительных процедурах установки, которые ADMT выполняет за пользователя. Примите варианты, предлагаемые в диалоговых окнах; тем самым вы дадите санкцию на активацию средств аудита и на создание особой группы Domain$$$. При последующих попытках миграции объекта система уже не будет предлагать вам выполнить эти процедуры.
Чтобы переместить пользователей, сделайте следующее.

1. Зарегистрируйтесь на выделенном сервере миграции, который был создан по инструкции, изложенной в первой части статьи, и запустите программу ADMT.

2. Правой кнопкой мыши щелкните на элементе Active Directory Migration Tool и в открывшемся меню выберите пункт User Account Migration Wizard, как показано на экране 4.

3. Введите имена исходного и целевого доменов. Выбранные контроллеры доменов DC должны быть объединены каналами связи с высоким быстродействием.

4. Выделите учетные записи пользователей домена. Надо сказать, что объекты «пользователь» не перемещаются, а копируются; поэтому я рекомендую переносить пользователей большими группами — или даже всех сразу.

5. Выберите целевую организационную единицу Organizational Unit (OU), где будут располагаться пользователи в новом домене.

6. Перенесите пароли. Не забывайте, что для этого необходимо установить компонент Password Export Server (PES) в соответствии с инструкциями, изложенными в первой части статьи. Кроме того, проследите, чтобы служба PES выполнялась на исходном контроллере домена; по умолчанию эта служба NT настроена на выполнение в режиме Manual.

7. Параметру Target Account State задайте значение Target same as source. Кроме того, можно отключить учетные записи в исходном домене, если вы не хотите, чтобы пользователи регистрировались в старом домене.

8. Обязательно установите флажок Migrate user SIDs to target domains.

9. Введите имя администратора домена и пароль для регистрации в исходном домене.

10. На странице мастера Group Options установите флажки Update user rights и Fix users' group memberships.

11. Ни одно свойство на странице Group Object мастера не должно быть исключено. Проследите, чтобы все флажки были сброшены.

12. Не переносите исходный объект при наличии конфликта.

Процесс миграции каждого объекта «пользователь» занимает всего несколько секунд; по завершении миграции вы получаете отчет с указанием числа исследованных и скопированных объектов, а также объектов, в которых были обнаружены ошибки. Осуществив миграцию нескольких пользователей, удостоверьтесь, что атрибут SID History заполнен корректно; для этого нужно просмотреть свойства пользователей в редакторе ADSI Edit.
По завершении миграции пользователей можно приступать к перемещению учетных записей их компьютеров. Помните: если при переносе пользователей данные копируются в новый домен, то при миграции компьютеров данные не копируются, а перемещаются. По этой причине мероприятия по переходу в новый домен следует планировать заблаговременно и все объяснить пользователям. Возможно, есть смысл коротко рассказать им о том, чем вы занимаетесь в данный момент. Чтобы пользователи могли без труда регистрироваться в домене New.local, предоставьте им соответствующий снимок экрана с необходимыми инструкциями.
Для перемещения систем в новый домен выполните следующие действия.

1. В оснастке AD Users and Computers консоли управления Microsoft Management Console (MMC) переместите объект «компьютер» в особую организационную единицу MigrationPrep, после чего перезапустите компьютер. В первой части статьи говорилось о том, что эта процедура отключает сетевой экран Windows Firewall и добавляет соответствующих пользователей или группы в группу Local Administrator Group.

2. Зарегистрируйтесь на сервере миграции и запустите инструментальное средство ADMT.

3. Правой кнопкой мыши щелкните на компоненте Active Directory Migration Tool и в открывшемся меню выберите пункт Computer Migration Wizard.

4. Введите имена исходного и целевого доменов.

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

6. Выберите целевую организационную единицу, в которую вы поместите компьютеры в новом домене. Для мониторинга этих систем я создал организационную единицу MigratedPC.

7. Устанавливать какие-либо флажки на экране Translate Objects не следует. Параметры защиты компьютеров мы перенесем в новый домен в рамках отдельной операции.

8. Флажок Replace в разделе Security Translation Options должен быть установлен. Чтобы открыть диалоговое окно User Rights Translate in Add Mode Only, нажмите ОК.

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

10. Не следует исключать какие-либо свойства на странице мастера Group Object; все флажки должны быть сброшены.

11. Не переносите исходный объект при наличии конфликта.

12. Нажмите кнопку Finish.

13. Проверьте страницу Migration Progress на наличие ошибок и устраните их. Начните с просмотра журнала ошибок.
    До настоящего момента процедура миграции компьютеров весьма напоминала процедуру миграции пользователей. Однако по завершении копирования объекта «компьютер» в каталог AD нам предстоит выполнить еще одну дополнительную операцию: компьютер нужно внести в новый домен New.local. Это можно сделать вручную или же с помощью средства ADMT. Завершив копирование объектов, в окне Migration Progress программы ADMT нажмите кнопку Close; на экране появится диалоговое окно Active Directory Migration Tool Agent Dialog, в котором можно дистанционно добавлять компьютеры в новый домен.

14. В окне Directory Migration Tool Agent Dialog выполните предварительную проверку; для этого нужно нажать кнопку Start. Чаще всего сбои при выполнении предварительной проверки объясняются проблемами, связанными с брандмауэром и с разрешениями.

15. Если предварительная проверка завершилась успешно, выделите пункт Run pre-check and agent operation и нажмите кнопку Start; тем самым вы добавите компьютер к новому домену и осуществите перезагрузку системы. Не забудьте заранее предупредить о своих планах пользователей.

Необходимо выполнить еще одну операцию. Перед тем как пользователи смогут впервые зарегистрироваться в системе, запустите мастер Security Translation Wizard с помощью компонента ADMT. Он обновляет настройки безопасности на рабочей станции; все файлы или папки, назначенные пользователю old\user, будут переназначены пользователю new\user. Профили пользователей также транслируются в домен New.local. Если пользователи зарегистрируются в компьютере до того, как вы выполните процедуру трансляции настроек безопасности, система создаст новый профиль, а все настройки пользователей останутся в старом профиле. Но если такое случится, не поддавайтесь панике. Просто зарегистрируйтесь в системе как пользователь с правами локального администратора, удалите новый профиль и запустите мастер Security Translation Wizard.
Для запуска Security Translation Wizard выполните следующие действия.

1. Правой кнопкой мыши щелкните на компоненте ADMT и в открывшемся меню выберите пункт Security Translation Wizard.

2. Выберите пункт Previously migrated objects.

3. Введите имена исходного и целевого доменов.

4. В новом домене выделите имена компьютеров, которые только что переместили. Если при выполнении описанного выше этапа 6 была создана организационная единица MigratedPC, найти эти компьютеры будет несложно.

5. Выделите целевую организационную единицу в разделе «новый домен».

6. Все флажки на странице мастера Translate Objects должны быть установлены.

7. На странице мастера Security Translation Options выберите параметр Add.

8. Не следует исключать свойства, указанные на странице мастера Group Object, — все флажки должны быть сброшены.

9. Установите флажок Do not migrate source object if there is a conflict.

10. Нажмите кнопку Finish.

11. Дождитесь открытия диалогового окна Active Directory Migration Tool Agent Dialog.

12. Выберите один компьютер для миграции в целях тестирования и выполните процедуру предварительной проверки, нажав кнопку Start. На это может уйти около минуты.

13. Если предварительная проверка пройдет успешно, выберите пункт Run pre-check and agent operation и нажмите кнопку Start.

По завершении процесса перемещения в новый домен учетных записей всех пользователей и их компьютеров вы можете осуществить миграцию серверов и всех связанных с ними учетных записей служб. Этот процесс аналогичен процессу перемещения пользователей и компьютеров. В компоненте ADMT реализован мастер Service Account Migration Wizard, но я пришел к выводу, что проще переносить учетные записи служб так же, как перемещаются типичные учетные записи пользователей, а затем вручную настраивать службы NT (например, службу SQL Server service). Впрочем, если вы эксплуатируете большое число серверов с учетными записями служб, возможно, затраты времени, связанные с использованием мастера Service Account Migration Wizard, будут оправданны.

Копирование почтовых ящиков Exchange
Компьютеры пользователей и серверы поддержки перемещаются в новый домен. Но для серверов Exchange такое решение вряд ли подходит. Современные версии Exchange тесно интегрированы со службой AD. Если вы переместили организацию Exchange в домен New.local, у вас уже не будет возможности подключить почтовые ящики в основном хранилище к объектам «пользователь» в AD. Вместо перемещения серверов Exchange целесообразно скопировать содержимое отдельных почтовых ящиков из старой организации Exchange в новую организацию Exchange, расположенную в домене New.local.
В Exchange 2003 и в более новых версиях имеется встроенный мастер миграции, который превосходно справляется с копированием групп почтовых ящиков из одной организации Exchange в другую, даже если они расположены в различных лесах AD. Ниже приводится описание простой процедуры копирования содержимого одной организации Exchange 2003 в другую организацию Exchange 2003.

1. Зарегистрируйтесь на сервере Exchange в домене New.local.

2. Последовательно выберите пункты меню Start, Microsoft Exchange, Deployment, Migration Wizard.

3. Выберите элемент Migrate from Microsoft Exchange.

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

5. Сбросьте флажок для сервера Exchange 5.5 и введите данные исходного сервера Exchange. Помните, что учетную запись администратора следует вводить в формате domain\user, как показано на экране 5.

6. Укажите диапазон дат (если это применимо).

7. Выберите один или несколько почтовых ящиков, которые вы хотите переместить. Можете выбрать все или выделять некоторые почтовые ящики с помощью клавиши Ctrl.

После этого начнется процесс копирования почтовых ящиков из старого домена в новый. В зависимости от размеров почтовых ящиков индивидуальных пользователей этот процесс может занимать от нескольких минут до нескольких часов (или даже дней). Кроме того, я обратил внимание, что нефрагментированный банк данных функционирует гораздо быстрее, чем фрагментированный. Скажем, если взять пустой почтовый ящик и направить туда 3000 сообщений, содержимое такого ящика может быть перемещено в течение нескольких минут. С другой стороны, для миграции почтового ящика с длительной историей эксплуатации (если он содержит те же 3000 сообщений, но полученных на протяжении последнего года) потребуется значительно больше времени, так как сообщения записаны на несмежных участках диска (не одно после другого). Большое влияние на скорость копирования содержимого почтовых ящиков могут иметь и другие факторы, такие, как производительность системы и быстродействие сети. Поэтому обязательно выполните несколько тестовых копирований почтовых ящиков, чтобы получить представление о том, какое время занимает этот процесс.

Приготовились — вперед!
Электронная почта — важный канал делового общения, поэтому при переходе на новую систему обработки электронной почты администратору следует проявлять особую осторожность. Вполне возможно, что, заблаговременно запретив пользователям работать с программой Outlook, вы сможете выиграть достаточно времени для перемещения почтовых ящиков, но вы не имеете возможности управлять потоком электронных сообщений — они по-прежнему будут приходить на почтовый шлюз вашей сети. Что бы вы ни делали, внешние сообщения будут поступать. Мне известны два метода, облегчающие переход на новую систему.
Метод очереди. Этот метод дает наилучшие результаты, когда применяется в компаниях с малым числом пользователей и хранилищем данных небольшого объема. Для реализации данного метода выполните следующие инструкции.

1. Отключите средства переадресации. Перед шлюзом будет формироваться очередь из сообщений электронной почты.

2. Скопируйте почтовые ящики со старого сервера Exchange в новую организацию.

3. Активируйте средства переадресации. Сообщения электронной почты будут поступать на новый почтовый сервер.

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

1. Скопируйте почтовые ящики со старого сервера Exchange в новую организацию. Используйте диапазон дат и копируйте только те электронные сообщения, которые поступили сегодня. В ходе данного этапа создается целевой почтовый сервер и конфигурируется пользовательская учетная запись для электронной почты.

2. Настройте шлюз электронной почты на новый сервер. Теперь поток электронных сообщений будет поступать на новый сервер.

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

Общие папки
Как я отмечал в первой части статьи, для перемещения папок общего доступа из одной организации Exchange в другую вы можете задействовать инструментальное средство Inter-Organization Replication. Еще одно решение — просто экспортировать все папки общего доступа в файл личных папок (PST), а затем импортировать их в новую организацию. Но какой бы метод вы ни использовали, выделите на миграцию достаточно времени; эти процессы порой протекают очень медленно. Определите, какие папки общего доступа нужно переместить на ранних стадиях проекта, и не откладывайте это дело до последней минуты.
Содержащиеся в почтовых ящиках сообщения копируются без особых сложностей, но при настройке адресов SMTP у вас могут возникнуть некоторые затруднения. Так, если вы имеете общий календарь с пользователем ITCalendar, а также общую папку с именем ITCalendar, один из этих объектов, вероятно, имеет SMTP-адрес ITCalendar.old.com, а второй — адрес ITCalendar2.old.com. При перемещении этих объектов тот из них, который будет перенесен первым, получит адрес без цифры 2. Если вы начнете процесс миграции с папки общего доступа, а потом перейдете к пользователю, тогда и пользователь, и общая папка получат неправильные адреса SMTP. Когда вы попытаетесь исправить адрес, Exchange проинформирует вас о том, что адрес, который вам нужен, уже используется.
Чтобы найти этот невидимый адрес и определить, кто или что его использует, задействуйте оснастку AD Users and Computers и выполните процедуру специализированного поиска следующим образом: proxyAddresses=smtp: ITCalendar.new.com. На экране 6 представлен пример такой процедуры специализированного поиска.

Когда вы перемещаете почтовые ящики Exchange внутри одной организации Exchange, Outlook и Exchange взаимодействуют в фоновом режиме, и пользовательские профили Outlook обновляются автоматически. Но когда почтовые ящики перемещаются в другую организацию Exchange, Outlook не может знать, куда именно переносить почтовые ящики. Здесь на помощь приходит компонент Microsoft Exchange Server Exchange Profile Redirector (ExProfRe.exe). Эта удобная, бесплатно распространяемая утилита помогает корректировать пользовательские профили Outlook с помощью сценариев регистрации.
Чтобы воспользоваться программой переназначения ExProfRe, создайте объект групповой политики (GPO) со сценарием регистрации. Скопируйте файл ExProfRe.exe в этот объект и создайте простой сценарий CMD, содержащий следующую команду:

exprofre.exe/targetgc=NEWDC1 /v/n/logfile=c:\UpdateProfile.log

Команду выполнять одной строкой. Файл ExProfRe вы можете загрузить на сайте Microsoft Download Center. Мой опыт показывает, что программа ExProfRe выполняется очень быстро и может изменить пользовательский профиль Outlook еще до того, как пользователь запустит Outlook, даже если Outlook располагается в папке Startup меню Start.

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

Моментальный снимок решения
Проблема
Требуется объединить инфраструктуры Active Directory и Exchange Server двух компаний.
Решение
Используйте инструментальное средство Active Directory Migration Tool (ADMT) для перемещения пользователей и компьютеров меньшей компании в более крупную, после чего с помощью интегрированного в Exchange Server мастера миграции перместите почтовые ящики в новую организацию Exchange в новой компании.
Необходимые ресурсы
ADMT, средство репликации Inter-Organization Replication, программа переадресации Microsoft Exchange Server Exchange Profile Redirector (ExProfRe.exe), каналы связи между двумя узлами
Этапы решения
Подготовьтесь к слиянию, следуя инструкциям в статье «Планируем объединение Active Directory. Часть 1».
Переместите учетные записи пользователей и компьютеры с помощью мастеров ADMT.
Скопируйте почтовые ящики Exchange в новую организацию Exchange и перенаправьте почту по новому адресу.
Переместите общие папки.
Измените настройки Outlook так, чтобы программа смогла находить новый сервер Exchange.
Уровень сложности
4 из 5