После завершения переноса данных сервера почтовых ящиков на новые сервера и удаления старых можно приступать к переключению на новые транспортные сервера. Можно это делать сразу после установки первого транспортного сервера. Порядок не принципиален. Основная работа по переключению будет идти с DNS-сервером и коннекторами.

Для начала можно перенести транспортные правила со старых серверов на новые. Делается это через Exchange Management Shell на любом сервере Exchange 2010 следующим образом:

$file = Export-TransportRuleCollection -ExportLegacyRules
Set-Content -Path d:rules.xml -Value $file.FileData -Encoding Byte
[Byte[]]$Data = Get-Content -Path d:rules.xml -Encoding Byte -ReadCount 0
Import-TransportRuleCollection -FileData $Data

Для того чтобы новые транспортные сервера сервера могли отправлять почту необходимо для них создать во внешней DNS-зоне A-записи и MX-записи, ссылающиеся на эти A-записи. Чтобы при этом почта проходила спам-фильтры на принимающих серверах (при их наличии) необходимо так же проконтролировать, что провайдер в обратной зоне для внешнего ip-адреса транспортных серверов укажет в PRT-записях их dns-имена. Так же имеет смысл создать корректную SPF-запись, либо, если она уже существует – добавить в неё новые транспортне сервера.

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

В том случае если создаётся новый send-коннектор, старый можно отключать. Сразу удалять его не стоит – может пригодится, если по каким то причинам придётся его заново использовать. Если новые транспортные сервера были добавлены в существующий send-коннектор, то из него нужно удалить старые транспортные сервера. Но этот вариант, с моей точки зрения, менее красив, так как откатиться к старому send-коннектору в случае каких-либо проблем будет сложнее.

Если у нас имется специальный коннектор для приёма анонимных сообщений от внутренних smtp-серверов, то его необходимо перенести на один из новых транспортных серверов, а внутренние smtp-сервера перенастроить на использование в качестве смарт-хоста нового транспортного сервера. Если список ip-адресов внутренних smtp-серверов будет велик, то вручную его переносить на новый коннектор будет затруднительно. Используем для этого EMS:

$connector = Get-ReceiveConnector "EX2007HTRelay"
Set-ReceiveConnector "EX2010HTRelay" -RemoteIPRanges $connector.RemoteIPRanges

Так как send-коннектор для старых транспортных серверов мы отключили, то можно удалять из нешней DNS-зоны MX-записи, ссылающиеся на старые сервера. Так же можно удалить существующие для них PTR-записи. Затем отключаем Receive-коннекторы на старых серверах. После этого старые транспортные сервера перестанут отправлять и получать почту из внешнего мира.

Осталось удалить A-записи для старых транспортных серверов и почистить от них существующую SPF-запись. Затем через Programs and Features запускаем программу удаления Exchange 2007 и удаляем роли Hub Transport и Client Access Server (ранее мы уже переключили клиентский доступ на новые сервера), а так же Exchange Management Tools.

После удаления последнего сервера с ролью Hub Transport/Client Access Server миграция будет считаться завершённой.

Предыдущие версии гипервизора от MS (идущие в комплекте с Windows 2008 и Windows 2008 R2) обрабатывали удаление снимков виртуальных машин достаточно криво – необходимо было сразу после удаления снимка выключать виртуальную машину. В процессе выключения данные из снимка объединялись с родительским файлом vhd или avhd. Понятно, что после удаления снимка выключать виртуальную машину не всегда было возможно. В итоге могло быть несколько удалённых снимков, которые так и не были объединены в родительский файл. И вот в этот момент слияние всех этих оставшихся файлов превращалось в настоящий квест.

Относительно недавно стал доступен дистрибутив для разработчиков следующей версии Windows Server со следующей версией гипервизора на борту. Вот тут в комментариях Александр Станкевич задал интересный вопрос – “Раз уж появились различные “живые сценарии”, то и слияние (Merge) дисков, после удаления Snapshot’ов, теперь будет выполняться без необходимости выключения виртуальной машины?”

Вроде бы пока я не видел чтобы это утверждение кто-то проверил – так что, возможно, буду первым.

Что у нас имеется – свежеустановленная операционная система Windows Server 8 Developer Preview с ролью Hyper-V. Далее подключаем её в качестве хоста к VMM 2008 R2 (подключается!) и заливаем из библиотеки виртуальную машину. Так получилось, что это оказалась Windows 2003. Далее ставим разное ПО чтобы можно было сделать пару снимков, которые бы друг от друга немного отличались. В итоге получаем следующее. Имеется 2 снимка:

Физически они все три состояния виртуальной машины представляют три файла:

Первый файл – 2003std86.vhd – представляет собой состояние виртуальной машины на момент создания снимка “with Outlook”, второй файл представляет собой изменение состояния виртуальной машины на момент создания снимка “win2003test”, ну и в третьем файле находится изменение состояния виртуальной машины на текущий момент со времени предыдущего снимка.

Логично предположить, что если мы будем удалять второй снимок – то в его файл должно вставиться изменение состояния виртуальной машины из третьего файла. Если будем удалять только первый снимок – то второй файл будет объединён с первым. Попробуем удалить снимок “win2003test”. После удаления в поле статуса виртуальной машины появится текст “Merge in Progress”:

По завершении объединения в папке виртуальной машины у нас будут находиться следующие файлы:

Видно, что третий файл был объединён со вторым, за счёт чего последний стал чуть больше. Ну и для закрепления удалим оставшийся первый снимок “with Outlook”. Опять в поле статуса виртуальной машины появится “Merge in Progress” и по завершении у нас останется только один файл:

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

При попытке подключения общих папок в PFDAVAdmin выскакивает ошибка:

При попытке подключиться к почтовым ящикам – список почтовых ящиков формируется, но при раскрытии каждого ящика появляется ошибка:

Could not expand http://servername/exadmin/admin/domain.com/mbx/
username@domain.com/non_ipm_subtree/: The remote server returned an error:
(403) Forbidden.

Смотрим документацию по PFDAVAdmin:

If you select Public Folders, PFDAVAdmin tries to connect to the public 
store on the target Exchange server over Secure Sockets Lauer (SSL) port 443 
port and to populate the navigation pane with the top-level folders. If this 
connection fails, PFDAVAdmin retries the connection using port 80 (non-SSL).

То есть при подключении к общим папкам PFDAVAdmin пытается попасть на адрес https://servername/exadmin и если не получается этого сделать – пытается использовать адрес http://servername/exadmin. В моём случае по непонятной причине оба способа не срабатывают. Странно.

Далее, при попытке подключения к почтовым ящикам:

If you select All Mailboxes, the process is more complex. First, PFDAVAdmin 
obtains the properties of all HTTP virtual servers on that server. Next,it queries
a global catalog for all the mailboxes that are homed on that server, based on 
msExchHomeServerName. When it has the list of mailboxes, it reads each proxy 
address on each mailbox and tries to match it with the domain name on one of the 
HTTP virtual servers. Based on that information, an HTTP path is built to that 
mailbox. For Exchange Server 2003 Service Pack 1 (SP1) and later versions, 
PFDAVAdmin tries to connect to the mailboxes over Secure Sockets Layer (SSL) port 
443 first. If this connection fails, PFDAVAdmin retries the connection using port 
80 (non-SSL). For Exchange Server 2003 without a service pack, and for Exchange 
2000 Server, PFDAVAdmin uses only port 80 (non-SSL).

Подключение к серверу глобального каталога проходит успешно, так как список почтовых ящиков формируется. Затем опять попытка подключения на 443 порт сервера почтовых ящиков, и, в случае неудачи, на 80 порт. И опять не срабатывает.

Идём на сервер в IIS Manager. В свойствах сайта присутствуют оба порта – 80 и 443:

Смотрим свойства привязок. Особенно интересует 443 порт:

А вот и ошибка – по какой-то причине к 443 порту не привязано ни одного сертификата. Что с этиим делать? Самый простой вариант – отключить на папке ExAdmin SSL вообще:

После этого PFDAVAdmin начинает без проблем подключаться и к общим папкам и к ящикам пользователей.

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

  • Проверяем, что оставшиеся на старом сервере почтовые базы используют базу общих папок, расположенную на сервере Exchange 2010.

Самый простой способ проверить это – запустить следующую команду на старом сервере:

Get-MailboxDatabase -Server servername | fl Name,PublicFolderDatabase

Если используется старая база общих папок – исправляем:

Set-MailboxDatabase -Name "Old Mailbox Database" -PublicFolderDatabase
"New Public Folder Database"
  • После этого можно приступать к процессу удаления реплик общих папок со старого сервера.

Делается это скриптом MoveAllReplicas.ps1 на новом сервере:

MoveAllReplicas.ps1 -Server oldserver -NewServer newserver

Процесс этот занимает некоторое время. Но, учитывая, что реплики мы уже скопировали в новую базу, то процесс только осуществит удаление реплик с нашего старого сервера. Наблюдать за процессом можно с помощью команды Get-PublicFolderStatistics:

Get-PublicFolderStatistics -Server oldserver

Как только она перестанет показывать папки, находящиеся на старом сервере, можно приступать к следующему шагу. А что делать если одна или несколько папок не будут удаляться со старого сервера? Самый просто способ – выгрузить данные, находящиеся в этих папках в pst-файл с помощью Outlook, запомнить клиентские права доступа к ним, папки удалить, проконтролировать, что они удалились на обоих серверах. После этого создаём эти папки обратно, задаем клиентские права доступа и загружаем данные из pst-файла назад в новые папки.

  • Удаляем старую базу общих папок.

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

Get-PublicFolderDatabase -Identity "Old Public Folder Database" |
Remove-PublicFolderDatabase
  • Удаляем старые почтовые базы.

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

Get-MailboxDatabase -Server oldserver | Remove-MailboxDatabase

После этого можно удалить edb-файлы баз и логи. Они в процессе удаления объектов баз с почтового сервера не удаляются. Придётся это делать вручную.

  • Удаляем старый сервер почтовых ящиков.

Процесс запускается через Program and Features в панели управления сервера. Галки Mailbox Role и Management Tools надо будет убрать.

На этом процесс удаления сервера почтовых ящиков Exchange 2007 завершается.

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

Get-ClientAccessServer servername -AutoDiscoverServiceInternalUri
https://hq-hub.domain.com/Autodiscover/Autodiscover.xml

Права доступа для администраторов региональных офисов

Модель назначения прав доступа в Exchange 2010 по сравнению с Exchange 2007 претерпела сильные изменения. Подробнее с ней можно ознакомиться здесь. Попробуем по аналогии с Exchange 2007 дать полный доступ региональным администраторам к своим почтовым серверам, а также дать им полный доступ к своим региональным почтовым объектам и общим папкам. Для начала создадим области действия наших региональных администраторов. Для почтовых объектов:

New-ManagementScope "Region1 Recipients Scope" -RecipientRoot region1.local
-RecipientRestrictionFilter '(objectclass -like "*")'

И для серверов:

New-ManagementScope "Region1 Servers Scope" -ServerRestrictionFilter {ServerSite
-eq "Region1-Site-Name"}

Далее копируем роли из существующей группы ролей “Server Management” в нашу новую группу ролей, область действия которой будет ограничена только региональными серверами и сразу добавим в неё регионального админа (или группу админов):

$RoleGroup = Get-RoleGroup "Server Management"
New-RoleGroup "Region1 Server Management" -Roles $RoleGroup.Roles
-CustomConfigWriteScope "Region1 Servers Scope" -ManagedBy "region1 admin"
-Members "region1 admin"

По аналогии копируем роли из существующей группы ролей “Recipient Management” в нашу новую группу ролей, область действия которой будет ограничена только региональными почтовыми объектами и сразу добавим в неё регионального админа (или группу админов):

$RoleGroup = Get-RoleGroup "Recipient Management"
New-RoleGroup "Region1 Recipient Management" -Roles $RoleGroup.Roles
-CustomRecipientWriteScope "Region1 Recipients Scope" -ManagedBy "region1 admin"
-Members "region1 admin"

То же самое для общих папок – область действия – региональные сервера:

$RoleGroup = Get-RoleGroup "Public Folder Management"
New-RoleGroup "Region1 Public Folder Management" -Roles $RoleGroup.Roles
-CustomConfigWriteScope "Region1 Servers Scope" -ManagedBy "region1 admin"
-Members "region1 admin"

Перенос общих папок

Как и при миграции с Exchange 2003 на Exchange 2007 общие папки должны сначала отреплицироваться на новые сервера. Делается это внесением в свойства общей папки реплик на новые сервера почтовых ящиков, на которых будут находится базы общих папок. Если папок много, то ручное внесение реплик становится трудоёмкой задачей. Для упрощения процесса существует скрипт AddReplicaToPFRecursive.ps1. Он добавляет реплики в свойства указанной общей папки и во все дочерние папки. Запускается следующим образом:

AddReplicaToPFRecursive.ps1 -Server 2007MBX -TopPublicFolder ""
-ServerToAdd 2010MBX

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

AddReplicaToPFRecursive.ps1 -Server 2007MBX -TopPublicFolder "NON_IPM_SUBTREE"
-ServerToAdd 2010MBX

Следует помнить, что если размер общих папок превышает 20-30 Гб, то первую операцию выполнять необходимо крайне осторожно, иначе существует большая вероятность уронить транспортные сервера, которые просто не справятся с таким потоком писем и отключат транспортный сервис, который после этого придётся восстанавливать.

Перенос почтовых ящиков пользователей

По завершении репликации общих папок можно приступать к переносу почтовых ящиков пользователей. Для этого лучше использовать Exchange Management Console (узел Recipient Configuration → Mailbox → New Local Move Request) или командлет New-MoveRequest в Exchange Management Shell. Процесс запускается с серверов Exchange 2010.

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

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