Развертывание и миграция Exchange 2010. Часть 6 переход на новые серверы Mailbox 2010.

Во второй части, была описана установка роли Mailbox. Настроек сервера Mailbox может быть достаточно много, все зависит от предъявляемых требований. Одной из первых задач является создание баз данных и настройка их отказоустойчивости. В Exchange 2010 концепция отказоустойчивости хранения почтовых ящиков заключается в копировании журналов транзакции баз почтовых ящиков, расположенных на разных серверах Mailbox(не более 16 серверов). Серверы объединяются в группу доступности DAG. Основным компонентом DAG является Active Manager, который пришел на смену ресурсной модели кластера Exchange(2000.2003,2007). В состав Active Manager входят две роли — это PAM и SAM. PAM решает какая база должна быть активной или пассивной, SAM следит за отказами баз данных. В случае отказа SAM передает информацию PAM и происходит переключение вышедшей из строя базы данных. DAG имеет зависимость от Failover Cluster -, поэтому сохраняется принцип кворумная модели — кластер существует, пока большинство узлов в кластере — доступно.  

Перемещение почтовых ящиков можно выполнять после того, как были настроены серверы Mailbox, переключен пользовательский трафик на новые серверы CAS 2010 и настроена маршрутизация SMTP между серверами Hub Transport 2007 и 2010.
Изначально было перемещено порядка 30 почтовых ящиков, так называемая пилотная группа. В ходе перемещения были собраны кейсы и их решения.
В моем случае было всего несколько кейсов:

1. При перемещении почтового ящика в пределах одного сервера исходный ящик не удален. Проблема известная и вроде бы решена еще до SP3,  но как оказывается не до конца

http://social.technet.microsoft.com/Forums/exchange/en-US/6043b74f-a41e-4674-b2b1-08c3b1a3afbd/mapiexceptionunexpectedmailboxstate-unable-to-delete-mailbox-hr0x80004005-ec2634

Решение:

Вывод всех почтовых ящиков помеченных как SoftDdelete в определенной базе:

Get-MailboxStatistics -Database «Database Name in Here» | Where-Object {$_.DisconnectDate -Notlike $NULL} | Format-Table DisplayName, DisconnectDate, MailboxGuid, DisconnectReason –Wrap

Удаление всех отключенных почтовых ящиков с пометкой SoftDelete в определенной базе:

$Mailboxes = Get-MailboxStatistics -Database «Database Name in Here» | where {$_.DisconnectReason -eq “SoftDeleted”}
$Mailboxes | foreach {Remove-StoreMailbox -Database $_.database -Identity $_.mailboxguid -MailboxState SoftDeleted}

Удаление выбранного почтового ящика в базе данных

Remove-StoreMailbox -database “Mailbox name in here” -identity “User Alias here” -MailboxState SoftDeleted

2. Запрос на перемещение почтового ящика — Queued не изменяет статус. При попытке удалить Запрос на перемещение возникает ошибка

Решение:

Ошибка связана с административными акаунтами, процесс AdminSDHolder снимает разрешения объекте пользователя для группы Exchange Servers. Для временного восстановления разрешений в закладке Advanced Security поставить галочку Include Inheritable permissions from the objects parent. 

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

Import-Module ActiveDirectory

Get-ADUser -LDAPFilter «(objectcategory=person)(samaccountname=*)(admincount=1)»

3. После миграции у одного из пользователей в Outlook появились ошибки синхронизации:

9:33:31 Синхронизатор версии 14.0.7010
9:33:31 Синхронизация почтового ящика »Иванов Иван Иванович»
9:33:31 Ошибка синхронизации папки
9:33:31                   [8004010F-501-8004010F-0]
9:33:31                   Ошибка операции клиента.
9:33:31                   Банк данных Microsoft Exchange
9:33:31                   Дополнительные сведения содержатся по адресу URL:
9:33:31                   http://www.microsoft.com/support/prodredirect/outlook2000_us.asp?err=8004010f-501-8004010f-0
9:33:31 Готово

Похожая ошибка обсуждалась на форуме: http://social.technet.microsoft.com/Forums/exchange/en-US/79b40a4b-ea8f-4fd9-b060-70dd8ba4b4ba/error-synchronizing-folder-8004010f5018004010f0-exchange-2010-and-outlook-2010-multiple. В моем случае кейс решен путем пересоздания  профиля пользователя Outlook.

После того, как все обращения были решены, начался этап массовой миграции почтовых ящиков.

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

В случае если при создании запроса на перемещение п-я не указывать целевую базу данных система будет балансировать перемещение п-я между базами. База данных для VIP пользователей была исключена из балансировки с помощью командлета Set-MailboxDatabase и параметра IsExcludedFromProvisioning.

Пользователи перемещались пулами от 100 до 200 пользователей, так как между Exchange 2007 и Exchange 2010 поддерживается Online миграция, задания запускались непрерывно.

Пример скрипта миграции пользователей с стандартным профилем:

• «mig_to_exch2010.ps1» файл PS1. Скрипт миграции.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

Get-Content c:\migration\move_mailbox.txt | New-MoveRequest -BadItemLimit 10 |export-csv C:\migration\logMove.txt -encoding «unicode»

• «mig_to_exch2010.cmd» файл CMD. Файл запуска миграции через task sheduler.

Powershell.exe -NoExit -ExecutionPolicy Remotesigned -File «C:\migration\mig_to_exch2010.ps1»

• «move_mailbox.txt» файл TXT. Файл с мигрируемыми пользователями.

Развертывание и миграция Exchange 2010. Часть 5 переход на Hub(до миграции ящиков).

После того, как пользовательские подключения переведены на новые серверы CAS, необходимо настроить маршрутизацию почтового трафика SMTP для Hub 2010.

Сервер Mail01-srv обеспечивает маршрутизацию исходящего и входящего трафика SMTP. В конечной топологии маршрутизацию между инфраструктурой Exchange и внешними почтовыми серверами будут обеспечивать серверы Edge. Изменить маршрутизацию SMTP планируется после миграции всех почтовых ящиков на новые серверы.

На схеме ниже изображена маршрутизация SMTP в процессе перехода с Exchange 2007 на Exchange 2010.

На некоторое время необходимо настроить маршрутизацию между Hub Transport 2007 и 2010. Для этого на серверах Exchange должны быть настроены принимающие соединители с типом аутентификации «Exchange Server Authentication» и разрешением «Exchange Servers».

На новых серверах Hub Transport 2010 изменять принимающие соединители нет необходимости. На сервере Mail01-srv существует принимающий коннектор в котором добавлено внешнее имя сервера (mail.mailmig.com) не соответсвующее FQDN сервера, что не позволит установить тип аутентификации Exchange Server Authentication. Решить вопрос можно, создав новый принимающий соединитель типа «Internal» и указав IP серверов Hub 2010 в разделе удаленной сети(Remote Network). На рисунке отображены настройки принимающего соединителя сервера Mail01-srv.

Exchange 2013 Poster

Постер для Exchange 2013 http://sdrv.ms/KeFxOu файл Ex2013Architechture

Развертывание и миграция Exchange 2010. Часть 4 переход на CAS 2010.

Первая роль Exchange, которую необходимо переключить на новые серверы является Client Access. Причина в том, что CAS 2007 является точкой подключения клиентов(кроме MAPI RPC) и в случае если почтовые ящики пользователей переместятся на новые серверы, клиенты потеряют доступ к OWA, Anywhere, ActiveSync, POP, IMAP. В организации с Exchange 2010 сервер клиентского доступа может проксировать и перенаправлять запросы пользователей на другие серверы Exchange CAS 2010/2007 и Exchange 2003. При подключении пользователей к CAS в случае если почтовый ящик находится на Exchange Mailbox 2010 пользователь получает доступ, в случае если почтовый ящик находится на Exchange Mailbox 2007, CAS 2010 перенаправляет или проксирует подключение на другие серверы CAS.

Проксирование

В случае с проксированием, клиент получает доступ к серверу CAS 2007, подключившись к CAS 2010. CAS 2010 является прокси-сервером.

Проксирование поддерживается следующими клиентами:

• Outlook Web App,
• Exchange ActiveSync(EAS)
• Exchange Control Panel (ECP)
• POP3, IMAP4
• Exchange Web Services

Перенаправление

В случае с перенаправлением, клиент получает от сервера ответ с ошибкой доступа к ресурсу и новый URL для повторного доступа. Клиент повторно пытается получить доступ к URL, указанному в ответе от сервера. Перенаправление поддерживается как между CAS серверами в одном сайте, так и между сайтами.

Перенаправление поддерживается следующими клиентами:

• OWA
• ECP
• EAS

Как на время миграции клиент определяет на каком сервере находится почтовый ящик пользователя?

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

• HomeDB(место размещения почтового ящика)
• msExchangeVersion(версия Exchange, где находится почтовый ящик)
• MSExchServerSite (мое предположение, что именно по этому атрибуту Microsoft Exchange Active Directory Topology определяется принадлежность Exchange к сайтам)
• Authentication Token
• InternalUrl и ExternalUrl (если существуют)

В рассматриваемом примере разбираются случаи только для Exchange 2007 и Exchange 2010 в одном сайте AD.

OWA

В случае если почтовый ящик находится на Mail01-srv и значение ExternalUrl существует, произойдет перенаправление запроса на CAS 2007.

EAS

В случае если почтовый ящик находится на Mail01-srv и значение ExternalUrl и InternalUrl существуют, возможно несколько вариантов:

1. Клиенты не поддерживают автообнаружение

В случае если клиент не поддерживает функцию Autodiscover, сервер CAS 2010 выполняет проксирование подключений на сервер CAS 2007(Internal URL)\Microsoft-Server-ActiveSync\Proxy

2. Клиенты поддерживают автообнаржуние

В случае если клиент поддерживает Autodiscover и значение ExtrenalUrl существует, сервер CAS 2010 отвечает клиенту (HTTP error code 451) сообщением, где находится новое имя подключения, указывающее на CAS 2007.

POST /Microsoft-Server-ActiveSync/default.eas User=user&DeviceId=foo&DeviceType=PocketPC&Cmd=Settings&Log=

RdirTo:https%3a%2f%2flegacy.mailmig.com%2fMicrosoft-Server-ActiveSync_Error:MisconfiguredDevice_ 443 mailmig\user xxx.xxx.xxx,xxx MSFT-PPC/5.2.5082 451 0 0 17

Для возможности проксирования тип авторизации для виртуальной директории  CAS2007 (InternalURL value) \Microsoft-Server-ActiveSync\Proxy должен быть Integrated Windows(значение по умолчанию).

В случае если клиент поддерживает Autodiscover и значение ExtrenalUrl не существует ($null) происходит проксирование.

С функцией автообнаружения существует следующий нюанс — некоторые устройства поддерживают Autodiscover, но не могут корректно отработать 451 ошибку и обновить профиль ActiveSync, если таких устройств не много, можно посоветовать пользователям сменить вручную URL на сервер на CAS 2007(legacy.mailmig.com)

В рассматриваемой инфраструктуре было приблизительно 600-700 устройств от разных производителей и мной было решено использовать только проксирование, чтобы избежать такой ситуации.

ECP

В Exchange 2007 нет такой виртуальной директории, поэтому этот вопрос в моем случае был не актуален.

P.S При конфигурировании ECP нужно обратить внимание на то чтобы типы аутентификации у ECP и OWA были одинаковые.

EWS

Сервис автообнаружения(autodiscover) предоставляет клиентам Exchange Web Services URL. Для клиентов с почтовыми ящиками на Mailbox 2007 будет возвращена ссылка на EWS CAS 2007, для клиентов с почтовыми ящиками на Mailbox 2010 будет возвращена ссылка на EWS CAS 2010.

P.S.

Проксирование происходит только в случае если почтовый ящик находится на Mailbox 2010 в другом сайте Active Directory. Например если пользователь подключился к CAS-1 в сайте Site-1 и его почтовый ящик находится на почтовом сервере, размещенным в Site-2, сервер CAS-1 будет проксировать подключение на сервер CAS-2 в сайте Site-2 в соответствии с настройками EWS InternalUrl на CAS-2. Проксирование происходит не зависимо от того существует ли значение ExternalUrl или нет.

POP/IMAP

В случае если почтовый ящик пользователя находится на Exchange 2007, сервер CAS 2010 проксирует подключения на CAS 2007.

Outlook Anywhere

CAS 2010 всегда проксирует подключения на Exchange 2007 Mailbox роль. Outlook Anywhere на Exchange 2007 необходимо отключить.

В итоге после перехода на новые серверы CAS  все пользовательские подключения (кроме MAPI Exchange 2007) были переключены на CAS 2010. Схема подключений изображена на рисунке ниже.

Настройка Exchange CAS 2010

1. NLB кластер

Процесс создания кластера описан в статье Creating Network Load Balancing Clusters

Свойства кластера (Cluster Properties)

IP: IP10

MAC: MAC№1

Full Internet Name: Outlook.mailmig.com

Cluster Operation Mode: Multicast

Правила портов (Port Rules)

IP-адрес кластера	Начальный порт	Конечный порт	Тип	Affinity	Описание
IP10	80	80	Tcp	single	Переключение клиентов с 80 на 443 порт
IP10	110	110	Tcp	Single	POP3
IP10	995	995	Tcp	Single	POP3 SSL
IP10	135	135	Tcp	Single	MAPI RPC
IP10	143	143	Tcp	Single	IMAP
IP10	993	993	Tcp	Single	IMAP SSL
IP10	443	443	Tcp	single	HTTPS OWA
IP10	1024	65535	Tcp	Single	MAPI RPC

Single Affinity —  трафик от клиента передается только на один узел кластера. (Exchange 2013 поддерживает режим, когда с одного клиента трафик может быть направлен на разные узлы кластера)

В режиме Multicast на кластерных адаптерах узлов сохраняются MAC адреса, а  так же добавляется Multicast MAC (MAC№1) кластера, таким образом  узлы кластера отвечают с Multicast MAC-ом и Unicast IP – это могут не поддерживать некоторые маршрутизаторы. В этом случае трафик за пределы VLAN не будет маршрутизироваться. Решить вопрос можно созданием статической записи в ARP таблице сетевого устройства, статья Catalyst Switches for Microsoft Network Load Balancing Configuration Example

Пример настройки на CISCO коммутаторе:

arp IP10 MAC№1 ARPA

mac address-table static MAC№1  vlan 3 interface Po1 Po2

1. Сертификаты

Сертификат для внешних публикаций

На ISA сервере добавлен только один IP и уже опубликованы различные сервисы на 443 порту, поэтому в моем случае на Listener придется заменить весь сертификат. Новый сертификат должен содержать следующие имена:

• Mail.mailmig.com
• Legacy.mailmig.com
• Autodiscover.mailmig.com
• Имена других опубликованных сервисов

Сертификаты для CAS 2010

В данном примере создан один сертификат для двух узлов CAS. Созданный сертификат экспортируется с приватным ключом на второй сервер CAS.

$data = New-ExchangeCertificate –GenerateRequest –SubjectName “C=com, O=MAILMIG Organization, CN=mail.mailmig.com” –DomainName mail.mailmig.com, srv-mx03.mailmig.com, srv-mx04.mailmig.com, pop.mailmig.ru, autodiscover.mailmig.com –FriendlyName “CAS Certificate” –KeySize 1024 –PrivateKeyExportable:$true

Set-Content -path «c:\CAS_SAN_cert.req» -Value $Data

Certreq -submit -attrib «CertificateTemplate:Webserver» -config «srv-dc01\MailmigCA»   CAS_SAN_cert.req CAS_SAN_cert.cer

Certreq –accept C:\CAS_SAN_cert.cer

Enable-ExchangeCertificate –thumbprint(штампсертификата) –services IIS, POP, SMTP

Сертификаты на CAS 2007

Если в сертификате присутствует FQDN имя сервера CAS 2007, менять сертификат нет необходимости.

Создание массива CAS

New-ClientAccessArray -Fqdn «outlook.mailmig.com» -Site «Default-First-Site-Name»

Настройка DNS

Создание новых записей:

• Outlook.mailmig.com — IP10, внутренняя зона DNS
• autodiscover.mailmig.com — IP10, внутренняя зона DNS
• legacy.mailmig.com — IP1, внутренняя зона DNS
• legacy.mailmig.com — IP3, внешняя зона DNS

Изменения текущих

• mail.mailmig.com — IP10, внутренняя зона DNS

P.S

В данном случае все публикации настроены на одном IP3, но если новые правила будут публиковаться на новых IP, в нужно будет изменить записи mail и autodiscover во внешней зоне mailmig.com.

Настройка Outlook Anywhere

Enable-OutlookAnywhere -Server:srv-MX03.mailmig.com -ExternalHostName:mail.mailmig.com -SSLOffloading $false –Defaultauthenticationmethod basic

Enable-OutlookAnywhere -Server:srv-MX04.mailmig.com -ExternalHostName:mail.mailmig.com -SSLOffloading $false –Defaultauthenticationmethod basic

На Exchange 2007 была настроена авторизация Basic, поэтому я решил так же настроить Basic, хотя рекомендуемый тип NTLM. В дальнейшем можно изменить.

Настройки URL на CAS 2010 srv-mx03.mailmig.com

Те же самые настройки необходимо будет сделать на srv-mx04.mailmig.com. По сути параметр ExternalUrl не нужно указывать в этих командлетах, так как на этапе установки CAS 2010 он был добавлен(ExternalCASServerDomain) и значения ExtrenalUrl уже настроены.

Set-OABVirtualDirectory srv-MX03\OAB* -ExternalURL https://mail.mailmig.com/OAB —InternalURL https://mail.mailmig.com/OAB -BasicAuthentication $True –WindowsAuthentication $True

Set-WebServicesVirtualDirectory srv-MX03\EWS* -ExternalURL https://mail.mailmig.com/EWS/Exchange.asmx -InternalURL https://mail.mailmig.com/EWS/Exchange.asmx -BasicAuthentication $True –WindowsAuthentication $True

Set-ActiveSyncVirtualDirectory –ExternalUrl https://mail.mailmig.com/Microsoft-Server-ActiveSync -InternalUrl https://mail.mailmig.com/Microsoft-Server-ActiveSync -Identity srv-MX03\Microsoft-Server-ActiveSync* -BasicAuth $True –WindowsAuth $True

Set-OWAVirtualDirectory srv-MX03\OWA* -ExternalUrl https://mail.mailmig.com/OWA -InternalUrl https://mail.mailmig.com/OWA -WindowsAuthentication $True –FormsAuthentication $False

Set-ECPVirtualDirectory srv-MX03\ECP* -ExternalUrl https://mail.mailmig.com/ecp -InternalUrl https://mail.mailmig.com/ecp -WindowsAuthentication $True –FormsAuthentication $False

Настройки URL на CAS 2007

Set-OABVirtualDirectory srv-MX03\OAB* -ExternalURL https://legacy.mailmig.com/OAB —-InternalURL https://mail01-srv.mailmig.com/OAB -BasicAuthentication $True –WindowsAuthentication $True

Set-WebServicesVirtualDirectory srv-MX03\EWS* -ExternalURL https://legacy.mailmig.com/EWS/Exchange.asmx -InternalURL https://mail01-srv.mailmig.com/EWS/Exchange.asmx -BasicAuthentication $True –WindowsAuthentication $True

Set-ActiveSyncVirtualDirectory –ExternalUrl https://legacy.mailmig.com/Microsoft-Server-ActiveSync -InternalUrl https://mail01-srv.mailmig.com/Microsoft-Server-ActiveSync -Identity srv-MX03\Microsoft-Server-ActiveSync* -BasicAuth $True –WindowsAuth $True

Set-OWAVirtualDirectory srv-MX03\OWA* -ExternalUrl https://legacy.mailmig.com/OWA -InternalUrl https://mail01-srv.mailmig.com/OWA -WindowsAuthentication $True –FormsAuthentication $False

После того как на серверах Exchange все настройки сделаны, осталось изменить правила на ISA Proxy01-srv

Правила описаны «как есть», возможно их можно было оптимизировать, например убрать лишние пути в правиле CAS 2010 OutlookAnywhere.

Последовательность правил следующая:

1. Exch2010OutlookAnywhere
2. Exch2007OWA
3. Exch2010ActiveSync
4. Exch2010OWA

Листенер, применяемый во всех правилах публикации почтовых систем.

Правило для OWA CAS 2007

Правило для OWA CAS 2010

Правило для OutlookAnywhere

Правило для EAS

С переключением на новые серверы CAS у меня возник один нюанс — связан он с тем, что SSO при перенаправлениях с CAS 2010 на CAS 2007 работает только в случае авторизации FBA. Так как на ISA только один IP на «внешнем» адаптере и для него уже сделан листенер  с авторизацией FBA и делегированием авторизации NTLM, внутренним пользователям OWA при перенаправлении на legacy придется вводить логин и пароль повторно. В этом случае можно сделать следующее:

Указать mail.mailmig.com во внутренней зоне DNS на «внутренний» адаптер ISA сервера(IP2), а в правиле OWA указать принимать подключения из объекта-сети, где находятся пользователи(в моем случае это Internal). После того, как были изменены настройки возникло две проблемы, первая связана с тем, что в службу тех. поддержки начали обращаться пользователи с проблемой что у них не доступен Интернет, вторая проблема возникала у пользователей Outlook, при старте которого через небольшое время появлялась табличка логона, при этом сообщения отправлялись и принимались. Первая проблема была связана с тем, что сервис wpad был настроен на 80 порту и тот же порт был включен на листере. Вторая проблема заключалась в том, что на CAS 2007 была изменена настройка по умолчанию для Autodiscover, которая вместо FQDN сервера указывала на mail.mailmig.com в этом случае подключение проходило через ISA c использованием не Integrated Windows а FBA. Поэтому такого рода настройки лучше проводить на выделенных IP, а так же необходимо продумывать все мелочи, исходя из этого мы с заказчиком решили, что так как миграция почтовых ящиков на новый сервер будет не продолжительной те не многочисленные пользователи OWA, которые подключаются из внутренних сетях будут вводить логин и пароль несколько раз.