Переход с Exchange 2010 на Exchange 2013

Поэтапно

Подготовка. Инвентаризация операционных систем на рабочих станциях, клиентов Outlook, антивирусов. Выделение ресурсов для сервера Exchange 2013 и установка операционной системы. Проверка записей DNS и определение готовности к изменению пробросов на внешнем маршрутизаторе.

Установка сервера Exchange 2013 рядом с Exchange 2010.

Настройка и тестирование совместной работы двух серверов одновременно.

Переключение потока почты на Exchange 2013.

Перенос почтовых ящиков на Exchange 2013.

Выведение из работы сервера Exchange 2010.

Вводная: Все роли Exchange 2010 установлены на одном сервере. Нужно так же компактно переехать на Exchange 2013.

Подготовка

На этапе подготовки нужно проверить готовность сети предприятия к обновлению Exchange 2013.

Лучше всего, если операционная система на рабочих станциях —Windows 7 или более поздняя. Хотя доводилось видеть нормальную работу с Exchange 2013 под Windows XP SP3 из Outlook 2007. Однако, XP снята с поддержки и рассчитывать на неё не приходится. Если необходимо обеспечить работу клиентов под Windows XP, то от установки Exchange 2013 лучше воздержаться. Либо в тестовой среде найти надежный способ заставить их работать в такой конфигурации и только после этого возвращаться к данной затее. В крайнем случае пользователи под старыми или другими операционками всегда могут подключиться к почте браузером через OWA.

Клиенты Outlook 2003 не поддерживаются. Для более поздних желательно установить обновления (они приходят на WSUS, нужно только одобрить):
— для Outlook 2007 — KB2687404
— для Outlook 2010 — KB2687623
— для Outlook 2013 — KB2863911 (практика показала, что для SP1 — не нужно)

Если у вас не Outlook, то и Exchange, скорее всего, вам не нужен.

Пару слов про антивирус. Касперский 8 со включенным “Веб контролем” блокирует работу Outlook. Нужно либо отключить “Веб контроль”, либо настроить исключения, либо обновить все до Касперского версии 10.

Пару слов про DNS. Настройка DNS для почтового сервера ужеобсуждалась. За одно сразу можно добавить снаружи запись CNAME на тот же адрес, куда указывает основная запись MX. Что-то типа: “autodiscover CNAME mail”. Для возможности подключения клиентом Outlook снаружи, должен прослушиваться порт 443. Хотя, как и прежде можно настроить через IMAP или POP3 любого другого клиента.

Для небольшой организации (на 200…300 почтовых ящиков) под Exchange 2013 логично выделить в виртуальной среде сервер с 4…6 ядрами, 12 Гб ОЗУ, HDD: 100…120 Гб (системный диск) + Диск под почтовую БД. В нашем случае на Exchange 2010 файл базы данных EDB занимал около 120 Гб. Примерно таким он и остался после переноса на 2013. Нам места было не жалко сделали C+D = 120 + 500 (на вырост). ОС бралась русская — Windows Server 2012 R2. Обязательно установить все обновления.

ВАЖНО! У вас должен быть действующий центр сертификации. Если его по какой-то причине до сих пор нет, то самое время поднять. Тем более, что это не сложно. Без сертификатов Exchange 2013 работать НЕ будет. И еще есть нюанс: штатный центр сертификации (CA) Windows приходится немного допиливать, чтобы он поддерживал возможность задавать несколько имен в одном сертификате. По крайней мере в Windows 2008 R2 было нужно. Возможно, с тех пор Windows поумнел.

Установка

Сначала делаем резервную копию AD. Хотя, возможность последующего восстановления из неё весьма сомнительна. Штатными средствами на DC: Start — Administrative Tools — Windows Server Backup.

Для удобства выполнения всех манипуляций, связанных с установкой Exchange 2013, с одного сервера устанавливаем на него (на новый сервер Exchange 2013) средства администрирования. В Windows Power-Shell:

Import-Module ServerManager

Install-WindowsFeature RSAT-ADDS

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

(Да, это одна очень длинная строка. Но за то все просто и быстро.)

Устанавливаем на сервер:

Windows Management Framework 4.0

Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit

Остальное, если потребуется, подскажет программа установки сервера Exchange 2013.

В качестве дистрибутива использовался не тот ISO, что выложен на MVLS (www.microsoft.com/Licensing/servicecenter), а тот, что в открытом доступе — KB2936880

(http://www.microsoft.com/ru-RU/download/details.aspx?id=43103), файл Exchange2013-x64-cu5.exe. Он в 3 раза меньше и на много более свежий. Это самораспаковывающийся архив. Независимо от выбранного при скачивании языка (RUS/ENG), скачивается один и тот же файл. Язык интерфейса будет зависеть от системы, с которой он запускается.

Запускаем его и распаковываем на новый сервер (D:\Inst\exch2013\).

Дальнейшие манипуляции по подготовке AD нужно выполнять:
— от имени учетной записи с правами  «Администраторы схемы» и «Администраторы предприятия»,
— на машине в том же сайте AD, что и хозяин схемы.

У нас все права есть и новый сервер находится в том же сайте, что и хозяин схемы, поэтому выполняем все на новом сервере.
В командной строке с повышенными привилегиями переходим в каталог с установочным пакетом (D:\Inst\exch2013) и выполняем команду:

Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

После завершения расширения схемы нужно дождаться репликации с остальными DC. В одном сайте репликация должна проходить достаточно быстро, не больше 5 минут. Можно как-то проконтролировать завершение процесса с помощью repadmin. В общем, ждем 10 минут и переходим к подготовке AD:

Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms

При установке первого сервера в организации Exchange в этой же команде еще указывают имя новой организации Exchange. Но у нас Exchange уже действует, поэтому имя не нужно.

После завершения подготовки AD также ждем минут 10 и запускаем подготовку доменов:

Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms

Теперь нужно дождаться репликации на ВСЕ контроллеры домена, т.е. во всех сайтах. Межсайтовая репликация может происходить довольно долго, и, как правило, её расписание включает ночное время. Можно отложить процесс до завтра, либо инициировать репликацию принудительно через апплет “Sites and Services”. Но тогда уже перед продолжением нужно будет убедиться, что репликация закончилась.

Установку Exchange 2013 запускаем из уже распакованного дистрибутива командой setup.exe. Мастер установки делает проверки системы, если чего-то не хватает, то он либо сам поставит, либо сообщит, что нужно еще сделать. Сама установка достаточно тривиальна. Основных ролей теперь две: сервер клиентского доступа и сервер почтовых ящиков. Эти роли включают в себя все роли версии 2010, кроме пограничного транспортного сервера. В Exchange 2013 SP1 роль пограничного сервера может быть установлена отдельно. Мы её не использовали ни в 2010, ни в 2013. Сам сервер мы ставили в каталог по умолчанию, на диск C:, а для почтовых баз подготовлен диск D:.

Установка заняла минут 20.

Настройка

Вход в панель управления

В версии Exchange 2013 не предусмотрено той тупой графической консоли, которая была в Exchange 2010. Все управление выполняется через веб-интерфейс по адресу: https://имя_сервера/ecp. Но для входа в ECP нам нужно сначала создать администратора Exchange именно на сервере 2013.

Создаем в AD нового пользователя (например, AdminEX), включаем его в группу безопасности “Microsoft Exchange Security Groups\Organization Management”. Включаем для него почтовый ящик. Для этого на сервере Exchange 2013 в консоли “Exchange Management Shell” выполняем команду:

enable-mailbox -Identity AdminEX

теперь этим пользователем можно логиниться на панель управления Exchange 2013. Вводим в браузере: hppts://имя_сервера/ecp. Браузер перебрасывает на OWA. Логинимся там и оказываемся в панели управления Exchange 2013.

Настройка коннекторов

В новой панели ECP мы видим параметры обоих серверов: старого 2010 и нового 2013.

Виден общий для организации соединитель отправки: меню — поток обработки почты — соединители отправки. Открываем его свойства двойным щелчком и на странице “определение области” проверяем, что оба наши сервера (старый и новый) присутствуют в списке “Исходный сервер”. Если одного из них нет, то добавляем.

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

Конкретный сервер выбирается из выпадающего списка. Для старого сервера соединители сохранились, а для нового созданы вновь. Только для 2010 по умолчанию соединителей было две штуки, а для 2013 — пять. Если мы будем что-то настраивать, то в тех, что содержат в названии Frontend: “Client Frontend ИмяСервера” и “Default Frontend ИмяСервера”. А пока нам нужны соединители приема на обоих серверах для получения трафика друг от друга. Создаем на каждом новый соединитель:
Имя: Int (любое)
Роль: Интерфейс транспорта
Тип: Внутренний
IP-адреса: удаляем диапазон по умолчанию (0.0.0.0-255.255.255.255) и добавляем IP-адрес второго сервера.

Открываем вновь созданный соединитель двойным щелчком и на странице “безопасность” проверяем, чтобы стояли галочки “Проверка подлинности сервера Exchange” и “Серверы Exchange Server”. Остальные птицы лучше сбросить. На странице “определение области” должен быть указан порт 25.

DNS

В зависимости от традиций конкретного предприятия, могут быть разные варианты. Можно сделать, например, так: снаружи и изнутри почтовый сервер отзывается по одному и тому же имени, скажем, mail.mydomain.ru. Тогда на внутреннем DNS-сервере изменяем запись CNAME, которая связывала имя mail с именем почтового сервера, так, чтобы она теперь указывала на новый сервер. Если mail — это не псевдоним, а имя, то тоже все должно работать, только с именами в DNS нужно будет разобраться по обстоятельствам.

Вопреки расхожему заблуждению, настраивать запись autodiscovery в локальной сети НЕ нужно. Она все равно использоваться не будет. Хотя и вреда от неё тоже нет. А во внешней сети нужно сделать:
autodiscover CNAME mail.

Сертификат

Для почтового сервера необходим сертификат, который бы включал в себя все возможные имена для обоих серверов (старого и нового):
— локальное имя 2010 (например, ex2010.mydomen.loc),
— локальное имя 2013 (например, ex2013.mydomen.loc),
— короткое имя 2010 (например, ex2010),
— короткое имя 2013 (например, ex2013),
— внешнее имя почтовика (например, mail.mydomen.ru),
— внешнее AutoDiscover (например, autodiscover.mydomen.ru),
— имя почтового домена, т.е. то, что в электронном адресе после собаки (например, mydomen.ru).

В интерфейсе ECP меню “серверы — сертификаты” выбираем новый сервер из списка и создаем новый запрос на сертификат. Оставляем “Создать запрос на сертификат, подписанный центром сертификации”. Задаем понятное себе имя. Групповой НЕ делаем, выбираем имя сервера, “Укажите домены…” пропускаем,  проверяем список имен, включаемых в сертификат. Добавляем, если чего-то не хватает. Ставим курсор на внешнее имя вида “mail.mydomain.ru” и помечаем его “как общее имя” птичкой над списком. На следующем экране заполняем реквизиты организации и сохраняем запрос на сертификат. Запрос нельзя сохранить на локальномдиске. Это должно бить имя шары.

Открываем веб-интерфейс своего центра сертификации: http://имя_CA/certsrv

Щелкаем по верхнему пункту: “Request a certificate”, потом “advsnced certificate request”, теперь самый длинный “Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.” В окно на следующей странице копируем все содержимое только что сохраненного файла запроса. Для этого открываем запрос в блокноте, Ctrl+A, Ctrl+C, ставим курсор в окно Saved Request, Ctrl+V. Шаблон берем “Web Server”. Кнопка “Submit>”, ОК, Загрузить сертификат. Сохраняем полученный сертификат на диске.

Возвращаемся в ECP на страницу “серверы — сертификаты”, выбираем только что созданный запрос и завершаем выпуск сертификата.

Теперь созданный сертификат нужно назначить службам сервера. Открываем его двойным щелчком и на вкладке “службы” устанавливаем галочки: SMTP, IMAP, POP, IIS.

IMAP, POP

По умолчанию, как и в Exchange 2010 эти службы отключены. Если они используются, то их нужно включить в Службах Windows Server’а. Только теперь их не две, а четыре:
— Microsoft Exchange IMAP4 (MSExchangeImap4)
— Microsoft Exchange POP3 (MSExchangePop3)
— Внутренний POP3 Microsoft Exchange (MSExchangePOP3BE)
— Внутренняя служба IMAP4 Microsoft Exchange (MSExchangeIMAP4BE).

Базы данных для почтовых ящиков

Вполне можно использовать созданную автоматически базу почтовых ящиков, но было решено:
— расположить почтовые ящики пользователей на другом логическом диске,
— сделать две разные базы данных почтовых ящиков с разными настройками ограничений:
— Simple — общий размер ящика 2 Гб, хранить удаленные письма 14 дней, хранить удаленные почтовые ящики 30 дней;
— VIP — общий размер ящика 2 Гб, хранить удаленные письма 30 дней, хранить удаленные почтовые ящики 60 дней.

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

Создаем на втором диске структуру каталогов:
\Databases
—\Simple
——\db
——\logs
—\VIP
——\db
——\logs

Создаем новые базы почтовых ящиков в этих каталогах через меню “серверы — базы данных”. Создание баз тривиальное, но в отличие от Exchange 2010 есть нюанс. Для БД обязательно нужно указать конкретную автономную адресную книгу. Это в свойствах БД на вкладке “параметры клиента”.

Тестирование

В командной строке Exchange можно выполнить общий тест:

Test-ServiceHealth

Если в какой-то из ролей RequiredServicesRunning = False, то роль не работает.

Создаем (если еще не было) тестового пользователя с почтовым ящиком на старом сервере Exchange 2010 (через интерфейс 2010). Находим его на первой странице ECP Exchange 2013 “получатели — почтовые ящики”. Справа внизу ссылка: Переместить почтовый ящик в другую базу данных. Задаем базу Simple на новом сервере. По окончании переноса проверяем хождение почты с тестового ящика и обратно наружу на внешние адреса и внутри организации на адреса сервера 2010. Если какое-то направление не работает, еще раз проверяем коннекторы (соединители). Так же проверяем подключение клиента Outlook к этому ящику. Проверить нужно все хорошенько в условиях, приближенных к реальным: с установленным корпоративным антивирусом, с обычными для всех пользователей параметрами брандмауера и прочим. Если все в порядке, то теперь у нас работают оба сервера (2010 и 2013) и работоспособность не зависит от того, на каком сервере находится почтовый ящик пользователя.

Переключение потока почты

Просто на внешнем маршрутизаторе изменяем пробросы с внешнего почтового адреса по портам 25, 80, 110, 143, 443.
110 и 143 — если используются POP3 и IMAP4,
443 — для подключения клиентов OWA и Outlook снаружи,
25 — обязательно, сюда приходит почта со внешних адресов.

Снова все проверяем.

Перенос почтовых ящиков

Если ящиков совсем мало, то можно переносить их в ручном режиме. Выделять в списке получателей (можно по несколько одновременно с помощью Ctrl или Shift) и перемещать в другую базу ссылкой внизу правой панели. Когда выделено несколько ящиков, то ссылка эта сразу не видна, а нужно сначала нажать там же “Дополнительные параметры”.

Кроме того предусмотрен пакетный режим на странице “получатели — миграция”. Создаем новый пакет миграции. Адреса ящиков передаются в файле CSV. В этом файле достаточно одного столбца, например, с адресом электронной почты ящика. В первой строке только нужно обязательно указать имя этого поля — “EmailAddress”. Такой список легко получить, выгрузив из AD через сохраненный запрос. Создаем новый запрос. Тип: “Пользовательский поиск”. Включаем поле “Пользователь — Электронная почта”, условие: “присутствует”. В результате получилась строка запроса: “(&(objectCategory=user)(objectClass=user)(mail=*))”. Удаляем лишние колонки с экрана (или после выгрузки удаляем в Excell), потом выгружаем его правой кнопкой, Экспортировать список. Добавляем в первую строку правильный заголовок “EmailAddress”. Можно полученный файл разбить на куски, т.е. отдельные файлы, например, по отделам, и переносить почтовые ящики пользователей частями. Имеет смысл начать с маленькой порции (5…10 ящиков) из территориально ближайшего к техподдержке подразделения. Мало ли что, возможно придется оперативно решать неожиданно возникшие проблемы, не проявившиеся при тестировании. (О проблемах будет отдельная статья.)

Перенос происходит очень долго. На хорошем оборудовании порядок цифр: 100 Мб в минуту.

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

Примечание. Логично было бы переносить VIP’ов в последнюю очередь, когда уже будут отработаны все возможные ситуации и решены все проблемы, связанные с переездом.

ВАЖНО. Кроме почтовых ящиков пользователей в Exchange есть и служебные ящики. Переносим их из командной строки “Exchange Management Shell” на новом сервере.

Увидеть эти служебные ящики можно с помощью команды:

Get-Mailbox -Arbitration

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

Get-MailboxDatabase -IncludePreExchange2013 | FL Name,Server,AdminDisplayVersion

Версия 15 означает Exchange 2013, версия 14 — Exchange 2010.

Для переноса всех служебных почтовых ящиков из Excange 2010 в Exchange 2013 передадим результат выполнения команды Get-Mailbox на вход нового запроса на перемещение:

Get-Mailbox -Database <“Имя БД в 2010”> -Arbitration | New-MoveRequest -TargetDatabase <“Имя БД в 2013”>

Здесь имя базы данных можно скопировать из результатов предыдущей команды (Get-MailboxDatabase)

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

Get-Mailbox -Database <“Имя БД в 2010”>

Через интерфейс ECP Exchange 2013 не видно служебного почтового ящика DiscoverySearchMailbox, хотя он виден в интерфейсе Exchange 2010. Если ящик еще не перенесен, переносим остатки:

Get-Mailbox -Database <“Имя БД в 2010”> | New-MoveRequest -TargetDatabase <“Имя БД в 2013”>

Выведение из работы сервера Exchange 2010

Нужно только деинсталировать Exchange 2010 через “Панель управления — Программы и компоненты”. Запускаем программу установки Exchange 2010, сбрасываем все птички в выборе компонентов и таким образом деинсталируем Exchange 2010. Но прежде чем выполнить удаление старого сервера, программа установки проверит, можно ли это делать сейчас и выдаст соответствующие указания, которые можно выполнить и заранее. В частности:
— в соединителе отправки нужно удалить из списка исходных серверов Exchange 2010: меню — поток обработки почты — соединители отправки, двойной щелчок по соединителю — вкладка определение области;
— удалить автономную адресную книгу в интерфейсе Exchange 2010;
— удалить базу данных общих папок;
— удалить базу данных почтовых ящиков.

Когда все эти компоненты будут удалены, программа установки без ошибок завершит удаление Exchange 2010.

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

Снова проверяем хождение почты наружу, внутрь и внутри организации.

После того, как переезд будет закончен, не лишним будет убедиться, что получившаяся система все еще соответствует рекомендациям по настройке DNS для почтового сервера. Конкретнее, речь о том, чтобы в соединителе отправки на вкладке «определение области» поле FQDN соответствовало внешнему имени почтового сервера, тому имени, в которое разрешается внешний IP-адрес записью PTR на внешних серверах DNS.

Источник: здесь