Миграция на Exchange 2019 часть 3 – подготовка к переносу почтовых ящиков

Проблемы при переезде ящиков

Иногда надо запустить Exchange host topology или что-то такое, а то ящик не едет.

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

Переезд ящиков – сам процесс

Генерирует тонны логов, следите за местом, может лучше включить циркулярочку (циркулярка так то зло). Учитывайте вот какой момент: На старой базе ящик может быть настроен как»параметры \ лимиты не соответствуют параметрам базы». При переезде, если ящик больше лимитов новой базы, то я даже не знаю как так смигирировать.

Аудит и прочие системные ящики

едут первыми, про это по ссылкам написано.

Иначе:

Не работают add-ins

There was a problem loading your options (“add-ins”)

Решение - переместить arbitration mailbox в базы на новом сервере.

https://supertekboy.com/2018/05/18/there-was-a-problem-loading-your-options/

Дырочки

Attacking MS Exchange Web Interfaces - Techniques for Attacking Exchange in Q2 2020

https://swarm.ptsecurity.com/attacking-ms-exchange-web-interfaces/

Проблемы

Exchange Server – There was a problem loading your options (“add-ins”)

https://supertekboy.com/2018/05/18/there-was-a-problem-loading-your-options/

SourceMailboxAlreadyBeingMovedTransientException has occurred

https://fromreallife.wordpress.com/2018/08/25/снова-kemp/

Выхватил эту проблему на одном ящике, не понятно почему.

Мониторинг и бекап

Не забывайте следить за местом на серверах

И вообще добавлять сервера в мониторинг

И главное, не отправляйте оповещения о проблемах в Outlook через Outlook. Нужен другой канал

Дописано в последний момент

Мелкие нюансы

По умолчанию на серверах работает restricted политика скриптов. В связи с этом при запуске Exchange management shell будет появляться ошибка запуска встроенных в Exchange скриптов, а так же не будет работать Exchange toolbox. Решается эта проблема переключением в режим unrestricted

Set-ExecutionPolicy unrestricted

Проблемы с календарем

Переезд проходит не мгновенно, ящики никто все сразу не возит, поэтому можно выхватить проблемы «ящик секретаря на старом сервере, календарь его коллеги уже на новом». При этом сам календарь отображаться будет, после двойного клика и ошибки «не подключено, не будет работать помощник / ассистент по планированию. Решение – переезд обоих на новые сервера.

Сообщение «администратор внес изменения, перезапустите клиента» - будет всплывать каждый раз, когда чей-то ящик(чужой), чей календарь был у вас открыт, переедет на новый сервер.

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

Кроме того, у части сотрудников служебные ящики подключены не делегированием календаря / полных прав, а напрямую, вводом логина и пароля, как такое отслеживать – не понятно, кроме как парсить логи и смотреть откуда было последнее подключение.

Пересоздание коннекторов

Коннекторы получения можно скопировать, можно пересоздать.

Скрипт копирования найдете сами, я предпочел перебрать коннекторы вручную и посмотреть что в них. Делается все как обычно через powershell

Почтовые правила при co-existance

Можно выхватить проблему, что после добавления новых правил на новом сервере (2019), старые (на 2010) нельзя будет редактировать. Достоверных данных о проблеме нет, откуда ее вытащил автор наброса понять невозможно.

EWS

Сломалась работа учеток, использующих имперсонацию в EWS, при доступе к ящикам на 2019. Починилось тем, что переделали идентификацию с SID на SMTP-адрес.

https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-identify-the-account-to-impersonate

Database

При открытии баз в EXCH19 с аккаунта, который находится в EXCH13 появляется ошибка - error Your request couldn't be completed. Please try again in a few minutes.

Решение - переместить админский ящик в 19

https://docs.microsoft.com/en-us/exchange/troubleshoot/administration/can't-manage-ex19-database-eac

Ошибки Server Manager

Ошибка при попытке сделать Refresh

Configuration refresh failed with the following error: The WS-Management service cannot process the request. The computed response packet size (515926) exceeds the maximum envelope size that is allowed (512000)

В консоли каждого из серверов видно ошибку по соседнему серверу

При отправке письма с ящика на старых серверах на ящик на новом сервере

Проблема связана с доменом. Запрещено слать на .test, .example, .invalid, or .localhost

Get-ReceiveConnector | fl -property *rej*

RejectReservedTopLevelRecipientDomains : False

Не работает!

Это особенность службы транспорта на версиях 2016+. Обойти невозможно, только пересоздать тестовый домен через .local или другие доступные имена.

https://social.technet.microsoft.com/Forums/en-US/e0fe3974-26f0-4fcb-bb2d-853e45b48811/setreceiveconnector-rejectreservedsecondlevelrecipientdomains-has-no-effect-on-rfc-2606-rejection?forum=Exch2016GD

https://social.technet.microsoft.com/Forums/en-US/5f9b814c-ada7-41a3-9f7b-755a9e058377/exchange-2016-failed-to-deliver-mail-after-a-new-installation?forum=Exch2016MFSM

Проблемы от трогания сертификата

An error occurred while using SSL configuration for endpoint 0.0.0.0:444. The error status code is contained within the returned data.

Application log усыпан ошибками

Не подключается PS

На новом сервере при запуске появляется ошибка

Плохо заходит в OWA/EC. HTTP ERROR 503 из прод подсети.

Просто открывается белое окно при входе через старые серверы и через новые. Telnet проходит.

Проблема связана с тем, что сертификат Microsoft Exchange Server Auth Certificate был удалён и в IIS сайт Exchange Back End остался без сертификата в привязках к HTTPS на 444 порту. Нужно просто забиндить имеющийся сертификат или создать новый, затем перезапустить IIS.

https://www.tune-it.ru/web/fender/blog/-/blogs/2825363

Не работает отправка с внешних сервисов на 587 порт

В GLPI при смене сервера на новый, при использовании 587 порта с TLS появляется ошибка отправки. В логах ошибок нет.

Проблема связана с тем, что на сервере по умолчанию используется TLS 1.0 и 1.1. На новых серверах Exchange поддерживается только 1.2.

Your meeting was found to be out of date and has been automatically updated

https://fromreallife.wordpress.com/2019/06/01/your-meeting-was-found-to-be-out-of-date-and-has-been-automatically-updated/

Про ВРЕМЕННЫЕ трудности и опасности

https://fromreallife.wordpress.com/2019/04/14/трудности-и-опасности/#more-3546

Для тех кто дочитал.

Каждая среда уникальна, имеет свои собственные наслоения легаси и палок, поэтому в перечне выше – далеко не полный список проблем, которые можно выхватить. Не приступайте к работам без точного планирования и плана отката, включайте в план работ проверки «заработало \ не заработало», старайтесь сложные действия выносить в не рабочее время, и разумеется не в периоды мораториев по работам (конец года, сдача отчетности, etc). Смотрите какие системы у вас ходят в почту и как именно – массы софта типа систем отчетности, мониторинга, всяких рассылок – вполне могут оказаться жестко приколоченными на IP адреса. Будьте готовы, что любой этап может пойти не так, читайте логи, проверяйте систему мониторинга. Простой пример: при миграции на новом сервере мониторинг может быть еще не включен, а место под логи базы - уже расходоваться в ходе миграции

Вывод из эксплуатации 2013

И это мы еще не рассмотрели вывод из эксплуатации старых серверов – сбор с них логов, проверка соединений, не рассмотрели всякого рода OWA и нестандартные клиенты.

Частично это рассмотрено ниже

Само по себе удаление серверов Exchange 2013 (всех, кроме последнего) – выполняется из панели управления и представляет из себя далее-далее-готово. Само собой делать это можно только после проверки логов и подключений – что туда точно, однозначно, совсем никто не ходит.

Мы столкнулись с тем, что очень старая СХД подключалась к почте (для отправки алертов ) по IP (не по доменному имени), случайно выяснили. IBM / Lenovo.

Exchange и ViPNet Client

Коллеги, моё вам предупреждение. Даже два.

1. ViPNet Client, будучи установленным на сервер Exchange (по крайней мере, 2019 CU7), вызывает периодические отказы в подключении к веб-сервисам. Выглядит так, как будто фаер то закрывает 443, то открывает. Возможно, это его недоIDS фолсит;

2. Самое главное: при сносе, он удаляет самоподписанные backend сертификаты для Exchange. Минус ECP, минус EMS, минус вообще всё. Было больно, до конца до сих пор не починился (самоподписанный серт новый сделал и назначил, ECP-EWS поднялись, но теперь после назначения внешнего сертификата чанга живёт до рестарта IIS, а далее начинает вести себя так, как будто backend сертов вновь нет; Autodiscover с точки зрения MCA настроен корректно, но на Outlook не отрабатывает и fallback'ится до GuessSmart, находящего IMAP, в общем, радости полные штаны).

Будьте осторожны.

адресные книги

Если у вас было более одной адресной книги, не забудьте ее прикрепить на почтовые базы.

Offline address book - OAB

В 2013 CU сколько-то было изменено поведение адресной книги по умолчанию – она стала не распространяемой. То есть, в какой-то момент вы можете с этим столкнуться

Offline address books in Exchange Server

https://docs.microsoft.com/en-us/exchange/email-addresses-and-address-books/offline-address-books/offline-address-books?view=exchserver-2019

Работа с OAB

https://www.howto-outlook.com/howto/oabupdate.htm

проверки –

Get-OfflineAddressBook | fl *vir*, *global*

GlobalWebDistributionEnabled

https://docs.microsoft.com/en-us/powershell/module/exchange/set-offlineaddressbook?view=exchange-ps

https://community.spiceworks.com/topic/2332405-ex2016-oab-virtual-dir-has-no-offline-address-book-assigned-outlook-oab-fails

Скрипты

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

Агент выполнения скриптов - Scripting Agent

Про задания в нем тоже надо вспомнить при переносе.

Выход наружу

Не рассмотрена тема проксей и публикации Exchange в онлайне – вместе с сервисами