Миграция на Exchange 2016: вводные данные и подготовка

Давно я не брал в руки шашку. Поэтому миграция будет между крайними версиями 2010 и 2016 с пропуском версии 2013. Схема миграции в основном совпадает со схемой миграции 2007 → 2010. Кратко выглядит следующим образом:

• Установка первых серверов, формирование DAG, подготовка точек подключения клиентов
• Переключение клиентов с точек подключения Exchange 2010 на точки подключения Exchange 2016
• Миграция пользовательских данных
• Вывод из эксплуатации серверов Exchange 2010

Перед первой фазой категорически приветствуется ознакомление с документацией и пилотная миграция в изолированной среде.

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

• Имеется известная бага/фича в работе приложения Autodiscover в Exchange 2016. Приложение кеширует данные в течение двух часов. Сразу после миграции ящика Autodiscover продолжит отдавать клиенту закэшированные данные со старыми настройками клиента. Это приводит к тому, что клиент Outlook в течение жизни кэша перенаправляется на старый сервер. Обходных путей решения проблемы ровно два:

– делаем вручную или автоматически recycle пула Autodiscover, это приведёт к сбросу кэша и клиент получит новые данные при следующем обращении
– пересоздаём локальный почтовый профиль пользователя

• В старых версиях Exchange 2010 в инструкциях по планированию очень невнятно описаны рекомендации по планированию пространства имен для разных типов клиентов. В частности, сильно вскользь затронут момент с совпадением fqdn массива серверов CAS (CAS-Array) и точек подключения веб-клиентов (OA). В общем, это не рекомендуется делать. То есть RPC-клиенты будут обращаться к CAS-Array по одному доменному имени, а веб-сервисы должны быть доступны по другому. Если этого не придерживаться, то при миграции мы получим неработающих клиентов на новых серверах, как это описано тут. Связано это с тем, что Exchange 2016 про RPC-клиентов не знает вообще ничего. Всех клиентов он по умолчанию считает веб-клиентами. Сразу после миграции клиент попытается подключиться к CAS-Array (точка подключения для RPC-клиентов) на новом сервере, который про CAS-Array не знает ничего. На этом в общем то всё для клиента и закончится.

Самым правильным в данной ситуации, с моей точки зрения, будет поменять fqdn точки подключения веб-клиентов. Процедура эта проходит прозрачно для клиентов и не требует перезапуска, в отличие от смены fqdn точки подключения RPC-клиентов. По ссылке выше так же указан вариант с принудительным переключением всех клиентов на OA. Мне он нравится меньше, так как требует предварительных подготовительных работ.

• При использовании связки Windows Server 2008 R2 + Exchange 2010 после миграции ящика может поломаться авторизация клиента. Подробнее проблема описана в следующей статье базы знаний. Там же ссылка на обновление, которое это исправляет.
• Обновления, обновления, обновления… Обновляем всё до самых последних обновлений. Операционные системы на серверах и клиентах, серверы Exchange до последнего SP и RU, Outlook на клиентах.

Полезные ссылки:
Ambiguous URLs and their effect on Exchange 2010 to Exchange 2013 Migrations
Outlook Anywhere users prompted for credentials when they try to connect to Exchange Server 2013 or Exchange Server 2016