Постановка проблемы:
Как известно, Exchange 2003 не поддерживает сосуществование двух организаций и процесс переезда ящиков между организациями Exchange.
В статье рассматриваются нюансы переподключения старых почтовых ящиков к новым учетным записям в новом лесу.
Немного теории:
Если появляется необходимость слияния двух лесов AD, то для решения можно использовать специальные утилиты миграции содержимого пользовательских ящиков, Как например Exmerge утилиту. Предлагаемые решения при слиянии организаций заключаются в сохранении и переносе учетных записей в новый лес, и разворачивании новой Exchange организации с нуля. Выглядит это так:
- Перенос учетных записей пользователей в новый с SID history в новый лес Active Directory
- Разворачивании новой Exchange 2003 организации с пустыми ящиками
- Экспортом старых ящиков с помощью ExMerge в PST файлы Outlook и перенос фалов в новый лес
- Импорт содержимого PST файлов с помощью ExMerge в новые почтовые ящики в новом лесу
Схема является стандартной, если новый лес действительно является новым, и ранее не содержал пользователей. Новые учетные записи образуются путем миграции из старого леса с SID history.
Но рассмотрим ситуацию, что существуют два леса AD в одной организации достаточно долго не связанные доверительными отношениями (они физически изолированы) развивались параллельно и обслуживают в реальности одних и тех же сотрудников. При этом пользователи данной компании имеют персональные учетные записи в обоих лесах. Получается, что сотрудник Иванов Иван в лесу Forest1 имеет учетку ivanov@forest1.local и в то же время имеет свою же учетную запись в лесу Forest2 00-iivanov@forest2.local Данные учетные записи не являются одинаковыми, поскольку атрибуты samscountname и SID будут принципиально разные. Но эти две учетки являются идентификацией одного и тоже человека в реальности. И в этом следующая проблема. Exmerge в данном случае не сможет сделать автоматический импорт ящиков в новый лес.
В этом случае возникает вопрос об управлении учетными данными (IdM) и синхронизации объектов разных служб каталогов. Но это другие дебри и программные продукты, которые могут обеспечить такую функциональность на этапе слияния двух лесов внутри одной организации. Это Forefront Identity Manager. Вопрос о приобретении FIM для миграции устаревшей версии Exchange 2003, к тому же снятой с поддержки в апреле 2014, звучит как-то необоснованно. И почему возникает необходимость поддержки Exchange 2003 с истекшим жизненным циклом для заказчика, я предлагаю опустить.
Решение:
Ввиду отсутствия денег на проект миграции решение следует максимально упростить. Метод заключается в переезде файлов почтовой базы Exchange 2003 в новую организацию Exchange. И далее монтирование этой базы на новом Exchange сервере в новом лесу.
Проверяем функциональность Exchange 2003 в исходном лесу. База содержит ящики и письма пользователей.
Размонтируем базу во время окна обслуживания сервера.
Проверяем целостность базы утилитой eseutil /mh. Проверяем состояние - Clean Shutdown
Копируем файлы базы STM и EBD на новый сервер EX03 в новом лесу. Продолжительность операции зависит от объема передаваемых данных скорости сетевых подключений и других факторов.
В исходном лесу все работы завершены.
В новом лесу, подключаем только что перенесенную базу. Я использовал старые пути и буквы дисков. Получаем сообщение при попытке ее смонтировать:
В свойствах базы отмечаем галку, что бака восстановлена из бекапа. Так как в AD информация о базе отсутствует или устаревшая.
После этого база успешно монтируется.
Давайте откроем список почтовых ящиков. Мы видим, что ящики переехали в новый лес. Но радоваться пока рано. Отображаются старые пользователи.
Для обновления информации из AD запустим Mailbox Cleanup Agent. Агент обновляет информацию об отключенных ящиках. Входит в задачи обслуживания почтового сервера. Подробности можно узнать тут http://support.microsoft.com/kb/324358
Мы же в данном случае запустим его принудительно.
Exchange System Manager - Servers - First Storage Group - Mailbox Store - Maiboxes - ПКМ - Reconnect
После указанной процедуры все перенесенные ящики окажутся отключенными. Дело в том, что в лесу forest2.local у пользователей Active Directory еще нет Exchange атрибутов, таких как msExchMailboxGuid. Так вот картина будет следующая, все перенесенные почтовые ящики станут отключенными.
Теперь нам надо просто подключить старый ящик к новому идентичному пользователю.
Тем самым сделать новые Exchange атрибуты на новый пользователей в AD. ПКМ по ящику - reconnect mailbox
Из AD выбираются идентичные пользователи. Но это не значит что нельзя подключить ящик совсем другому сотруднику. Просто наша цель подключить ящик идентифицированный с конкретным человеком исходя из его ФИО и атрибутов AD Displayname в новом леcу forest2.local. Ищем в AD соответствующего сотрудника:
Ящик подключен к новому пользователю AD. А в реальности - к прежнему сотруднику. Осталась маленькая деталь. Восстановить значение атрибута mail. Без него невозможно залогиниться на OWA.
Итак теперь нам предстоит проверить доступ к этому ящику через OWA. В лесу forest2.local обращаемся к Outlook Web Access через браузер по пути:
http://EX03.forest2.local/Exchange где EX03 - имя нового сервера Exchange 2003
Как видим ящик успешно подключен.
Выводы:
В статье рассмотрен недокументированный способ переезда ящиков разработанный лично мной. Осуществлен переезд постовой базы в новую Exchange организацию. Ящик подключен новому пользователю ручным способом.
Утилиты ADMT и Exmerge в данном случае использовать было нельзя, так как ADMT не копирует Exchange атрибуты, а Exmerge необходимо сохранение SID history ADMT. К тому же миграции лесов AD не происходило и не планировалось.
Остается открытым вопрос автоматизации с помощью Powershell подключения сразу множества ящиков к новым пользователям в новом лесу. Исследования показали, что для успешного подключения ящиков необходимо восстановить атрибуты пользователя в AD, конкретно:
- DispayName
- msExchMailboxGuid
Экспортировать эти данные из старого леса не составит проблем с помощью PowerShell. Далее подкорректировав название почтового домена эти атрибуты добавить идентичным по Displayname пользователям нового домена с помощью скрипта.
Об автоматизированном переподключении ящиков - в следующей части статьи.
