Подготовка . Инвентаризация операционных систем на рабочих станциях, клиентов 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
(Да, это одна очень длинная строка. Но за то все просто и быстро.)
Устанавливаем на сервер:
Остальное, если потребуется, подскажет программа установки сервера Exchange 2013.
В качестве дистрибутива использовался не тот ISO, что выложен на MVLS (www.microsoft.com/Licensing/servicecenter), а тот, что в открытом доступе — KB2936880
Вводная.
Имеются два леса AD. Каждый лес состоит из одного домена: forest1.local и forest2.local . В одном лесу (forest1) расположены учетные записи пользователей. В другом лесу (forest2) развернута организация Exchange 2010 SP3, в которой находятся почтовые ящики пользователей из forest1. Зеркального отражения учетных записей пользователей нет.
Задача.
Развернуть в forest1 организацию Exchange 2010 и перенести контент пользовательских почтовых ящиков из forest2 в forest1.
Описание инфраструктуры.
Forest1
forest1.local
- forest1-dc1.forest1.local - контроллер домена
- forest1-cas1.forest1.local
- forest1-mbx1.forest1.local
- forest1-tmg1.forest1.local
Принцип именования пользователей - [первая буква имени][фамилия]. Например, Иван Иванов - iivanov
Forest2
Лес AD состоящий из одного домена - forest2.local
В лесу развернуты следующие сервера:
- forest2-dc1.forest2.local - контроллер домена
- forest2-cas1.forest2.local - сервер Exchange 2010 SP3 (CAS и Hub)
- forest2-mbx1.forest2.local - сервер Exchange 2010 SP3 (Mailbox)
- forest2-tmg1.forest2.local - межсетевой экран, прокси, обратный (реверсный, реверсивный и т.п.) прокси
Принцип именования пользователей - [имя].[фамилия]. Например, Иван Иванов - ivan.ivanov
Организация Exchange обслуживает SMTP домен - forest.com . Пользователи получают доступ к почтовым ящикам по Outlook Anywhere, OWA, ActiveSync.
Перенос почтовых ящиков.
Подготовка сетевой инфраструктуры.
Перед началом процесса переноса почтовых ящиков необходимо выполнить несколько предварительных условий:
- Обеспечить маршрутизацию трафика между двумя лесами (VPN Site-To-Site и т.п.).
- Настроить взаимное разыменование внутренних имен (передача зоны, зоны-заглушки, условная пересылка и т.п.)
- Убедиться, что сервера Exchange в обоих организациях доверяют сертификатам друг друга.
Подготовка серверов клиентского доступа.
Инициировать передачу контента почтового ящика можно, как из исходного леса (в моем примере -forest2), так и из конечного леса (в моем примере - forest1). Если команда на перемещение инициируется из конечного леса, то параметр должен быть разрешен в исходном лесу. Если команда на перемещение инициируется из исходного леса, то параметр Mailbox Replication Service Proxy (MRS Proxy) должен быть разрешен в конечном лесу.
Я буду инициировать перенос контента почтовых ящиков из конечного леса, поэтому включить MRS Proxy я должен на сервере forest2-cas1.forest2.local .
Set-WebServicesVirtualDirectory -Identity "Forest2-Cas1\EWS (Default Web Site)" -MRSProxyEnabled $true
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -MRSProxyEnabled $true
Подготовка пользовательских учетных записей в конечном лесу.
Я буду переносить почту для пользователя Семен Петров, который имеет следующие параметры:
- Отображаемое имя в обоих лесах - Семен Петров
- Имя пользователя в Forest1 - spetrov
- Имя пользователя в Forest2 - semen.petrov
- Почтовый адрес - [email protected]
Перед началом переноса контента необходимо подготовить пользовательские учетные записи в конечном лесу (forest1). Это выполняется в два этапа.
Первый этап подготовки пользовательских учетных записей в конечном лесу.
На первом шаге необходимо всех пользователей в конечном лесу, чьи почтовые ящики будут переноситься, сделать пользователями с включенной поддержкой почты (Mail User).
Второй этап подготовки пользовательских учетных записей в конечном лесу.
На втором шаге необходимо, с помощью скрипта Prepare-MoveRequest.ps1 , скопировать некоторые атрибуты пользователя из исходном лесу.
Prepare-MoveRequest.ps1 -Identity ‘[email protected]’ -RemoteForestDomainController forest2-dc1.forest2.local -RemoteForestCredential (Get-Credential forest2\adm) -UseLocalObject
Я передаю в скрипт параметр -UseLocalObject . Это необходимо сделать, т.к. у меня в конечном лесу уже существует пользователь с включенной поддержкой почты.
Перенос контента почтового ящика из исходного леса в конечный лес.
Перенос контента осуществляется с помощью командлета New-MoveRequest .
New-MoveRequest -Identity "semen.petrov" -Remote -RemoteHostName forest2-cas1.forest2.local -RemoteCredential (Get-Credential forest2\adm) -TargetDeliveryDomain "forest1.local"
Что в это время происходит у пользователя?
После переноса контента почтового ящика у пользователя появится следующие сообщение:
После перезапуска Outlook пользователь подключиться к серверу Exchange, который расположен в его собственном лесу.
Перемещение почтовых ящиков Exchange 2013 из одной БД в другую можно достаточно легко выполнить через EAC (Exchange Admin Center), но в этой статье я рассмотрю вариант переноса с помощью powershell, т.к. веб-интерфейс даже версии SP1 достаточно сырой и периодически возникают ошибки в заданиях при банальном перетаскивании ящика из одной базы в другую.
Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — .
Перемещение почтовых ящиков Exchange 2013
Для создания запросов перемещения ящиков между базами данных используется командлет New-MoveRequest . Пример полной команды будет выглядеть следующим образом:
C:\Windows\system32>New-MoveRequest -Identity «[email protected]» -TargetDatabase «Name of you target database» -BatchName «Enter your request name» -BadItemLimit «200»
Запрос на перемещение сделали, отлично. Но что, если ящик имеет либо большой размер, либо огромное количество элементов и вы просто хотите отследить прогресс операции, который в самом начале показался в столбце PercentComplete ? Тут наступает самое интересное, потому что для отслеживания прогресса выполнения задания нам будет нужен уже другой командлет, вот он: Get-MoveRequestStatistics .
Пример использования на основе данных из команды в начале статьи:
C:\Windows\system32>Get-MoveRequestStatistics -Identity [email protected]
А вот и вывод команды:
Справа можно увидеть столбец с процентом выполнения задачи.
Следует отдельно рассказать о параметре BadItemLimit командлета New-MoveRequest : он отвечает за количество поврежденных элементов, которое будет пропущено. По умолчанию, если его не указывать, он равен 0 и Microsoft строго рекомендуют его не трогать. Однако если в ящике присутствуют поврежденные элементы, запрос будет завершаться с ошибкой и ящик останется в той же самой базе данных. На моей практике при переносе двух сотен ящиков из одних баз в другие (при миграции с Exchange 2010 на 2013) было не больше 2-4 ящиков с хотя бы одним поврежденным элементом, при том что 2010 сервер работал несколько лет. Поэтому можно сделать вывод, что при грамотном администрировании Exchange случаев с присутствием поврежденных элементов у вас будет достаточно мало.
Также хочу отметить, что если значение BadItemLimit у вас больше 50, то нужно принудительно указать ключ AcceptLargeDataLoss , по крайней мере так написано на Technet, но реально я всегда ставил количество элементов 200 и меня ни разу никто не спросил о том, согласен ли я на «большие потери данных» и не запретил при этом выполнение команды (см. первый скриншот, параметр AcceptLargeDataLoss там не указан).
Надо отметить, что концепция Exchange 2013 состоит в том, что центры администрирования включают в себя только базовый функционал, минимальный набор. Для получения же доступа к тонким параметрам, а зачастую даже к некоторым функциям (например, к операциям над Offline Address Book, но об этом в другой раз), нужно использовать исключительно Powershell.