Проверим что все получилось, введя в браузере сервера RP http://127.0.0.1

2 ) Устанавливаем Microsoft Web Platform Installer . В поиске Microsoft Web Platform Installer набираем ARR и устанавливаем пакет Application Request Routing 3.0 + дополнительные компоненты предложенные установщиком.

4 ) Переходим в Server Farms и создаем новую ферму серверов. Назовем ее Contoso.com

Добавим сервера в ферму (Если роли разнесены, то добавляем только CAS сервера). Вводим FQDN сервера и нажимаем ADD

Нажимаем Finish , затем YES на предложение создать правила.

5) Необходимо настроить ферму, в которую мы добавили наши почтовые сервера. Открываем ферму contoso.com и переходим в раздел Caching . Убираем чекбокс Enable Disk Cache и нажимаем Apply

Переходим в раздел Health Test . В качестве URL для проверки доступности серверов я укажу:

• https://autodiscover.contoso.com/Autodiscover/HealthCheck.htm

URL для проверки доступности имеет вид https:////HealthCheck.htm это URL по умолчания для Exchange Server 2013/2016. Для каждого протокола существует свой URL и его нет необходимости настраивать дополнительно, это все часть компонента Managed Availability . Можно указать другие URL для соответствующих протоколов:

• https://mail.contoso.com/EWS/HealthCheck.htm
• https://mail.contoso.com/OAB/HealthCheck.htm
• https://mail.contoso.com/OWA/HealthCheck.htm

Настройки для раздела Health Test (после внесения изменений, не забываем нажимать Apply )

После внесения всех настроек нужно проверить, что все работает. Нажмем Verify URL Test и убедимся, что все серверы прошли проверку, ответив Pass. Если сервер не будет доступен, то на него не будут пересылаться запросы от внешних клиентов. Компонент ARR выведет его из балансировки до тех пор, пока снова не “увидит” сервер клиентского доступа.

Переходим к разделу Proxy , выставляем настройки:

• Time-Out: 200 seconds
• Response Buffer threshold: 0

не забываем нажимать Apply после внесения изменений.

Load Balance, Monitoring and Management и Server Affinity не трогаем.

6 ) Переходим к созданию правил перенаправления запросов.

В оснастке IIS открываем URL Rewrite

Создаем правило для Autodiscover

Для добавления шаблона во вкладке “Conditions” нажать “Add” и ввести параметры:

Аналогично ввести “{HTTPS} ON”

В самом низу выбираем действие, которое необходимо выполнить, если запрос соответствует шаблону. В нашем случае, это перенаправление на ферму серверов (не забывайте выбрать https ) и чекбокс запрещающий выполнение следующих (нижних) правил.

Готово.

Аналогичным образом создаем правило для mail.contoso.com и, ели есть желание, для activesync.contoso.com .

В получившемся списке, первым должно идти правило Autodiscover , затем activesync , после mail . Правила отрабатывают по очереди, одно за другим. Перемещать правила в списке можно с помощью стрелок вверх и вниз, находящихся слева.

Последний штрих. Перейдите в “Request Filtering”

и задайте значение 2147483648 для параметра “Maximum allowed content lenght”.

Всё готово! Теперь необходимо настроить внешние DNS сервера, для разрешения имен Autodiscover и mail (а если настраивали, то и activesync ) в IP IIS ARR .

По просьбам трудящихся закрываем ECP

В 5 части этого цикла статей мы рассмотрели создание массива Client Access на каждом сайте Active Directory. Затем мы включили Outlook Anywhere, а также настроили параметры Outlook Provider, чтобы Outlook Anywhere клиенты могли подключаться при возникновении аварийной ситуации.

В этой части цикла мы продолжим с того места, на котором остановились в предыдущей части. Мы начнем с настройки внутреннего и внешнего URL адреса для служб CAS на каждом сервере Exchange 2010 на обоих сайтах Active Directory. Затем мы создадим группу DAG и выполним базовую настройку DAG.

Изменение внутреннего и внешнего Exchange 2010 CAS URL адреса для указания на HLB

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

Подводя краткий итог предыдущим частям этого цикла, можно сказать, что адрес ‘mail.exchangeonline.dk ‘ указывает на VIP адрес, настроенный на решении балансировки нагрузки в основном центре данных, а ‘failover.exchangeonline.dk ‘ указывает на VIP адрес, настроенный на решении балансировки нагрузки в аварийном центре данных. Это означает, что URL адреса нужно настраивать по-разному для каждого центра данных.

Outlook Web App (OWA)

Начнем с URL адресов для Outlook Web App (OWA). Для этого используем следующие команды:

Основной центр данных:

Set-OwaVirtualDirectory -Identity "EX01\OWA (Default Web Site)" -InternalURL /OWA -ExternalURL https://mail.exchangeonline.dk/OWA

Set-OwaVirtualDirectory -Identity "EX03\OWA (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/OWA -ExternalURL https://mail.exchangeonline.dk/OWA

Аварийный центр данных:

Set-OwaVirtualDirectory -Identity "EX02\OWA (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/OWA -ExternalURL https://failover.exchangeonline.dk/OWA

Set-OwaVirtualDirectory -Identity "EX04\OWA (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/OWA -ExternalURL https://failover.exchangeonline.dk/OWA

Рисунок 1: Настройка URL адресов для OWA Virtual Directory

Панель управления Exchange Control Panel (ECP)

Для панели управления Exchange Control Panel (ECP) мы используем следующие команды:

Основной центр данных:

Set-EcpVirtualDirectory -Identity "EX01\ECP (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/ECP -ExternalURL https://mail.exchangeonline.dk/ECP

Set-EcpVirtualDirectory -Identity "EX03\ECP (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/ECP -ExternalURL https://mail.exchangeonline.dk/ECP

Аварийный центр данных:

Set-EcpVirtualDirectory -Identity "EX02\ECP (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/ECP -ExternalURL https://failover.exchangeonline.dk/ECP

Set-EcpVirtualDirectory -Identity "EX04\ECP (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/ECP -ExternalURL https://failover.exchangeonline.dk/ECP

Рисунок 2: Настройка URL адресов для ECP Virtual Directory

Exchange ActiveSync (EAS)

Для Exchange ActiveSync (EAS) используем следующие команды:

Основной центр данных:

Set-ActivesyncVirtualDirectory -Identity EX01\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync

Set-ActivesyncVirtualDirectory -Identity "EX03\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync

Аварийный центр данных:

Set-ActivesyncVirtualDirectory -Identity "EX02\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync

Set-ActivesyncVirtualDirectory -Identity "EX04\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync

Рисунок 3: Настройка URL адресов для EAS Virtual Directory

Offline Address Book (OAB)

Для Offline Address Book используем следующие команды:

Основной центр данных:

Set-OABVirtualDirectory -Identity "EX01\oab (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/oab -ExternalURL https://mail.exchangeonline.dk/oab

Set-OABVirtualDirectory -Identity "EX03\oab (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/oab -ExternalURL https://mail.exchangeonline.dk/oab

Аварийный центр данных:

Set-OABVirtualDirectory -Identity "EX02\oab (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/oab -ExternalURL https://failover.exchangeonline.dk/oab

Set-OABVirtualDirectory -Identity "EX04\oab (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/oab -ExternalURL https://failover.exchangeonline.dk/oab

Рисунок 4: Настройка URL адресов для OAB Virtual Directory

Exchange Web Services (EWS)

Для Exchange Web Services (EWS) используем следующие команды:

Основной центр данных:

Set-WebServicesVirtualDirectory -Identity "EX01\EWS (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://mail.exchangeonline.dk/ews/exchange.asmx

Set-WebServicesVirtualDirectory -Identity "EX03\EWS (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://mail.exchangeonline.dk/ews/exchange.asmx

Аварийный центр данных:

Set-WebServicesVirtualDirectory -Identity "EX02\EWS (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://failover.exchangeonline.dk/ews/exchange.asmx

Set-WebServicesVirtualDirectory -Identity "EX04\EWS (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://failover.exchangeonline.dk/ews/exchange.asmx

Рисунок 5: Настройка URL адресов для EWS Virtual Directory

Unified Messaging (UM)

В этой тестовой среде мы не используем Unified Messaging (UM), но если у вас другие планы, вам нужно будет настроить для нее URL адрес с помощью следующих команд:

Основной центр данных:

Set-UMVirtualDirectory -Identity "EX01\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx

Set-UMVirtualDirectory -Identity "EX03\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx

Аварийный центр данных:

Set-UMVirtualDirectory -Identity "EX02\unifiedmessaging (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx

Set-UMVirtualDirectory -Identity "EX04\unifiedmessaging (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx

Внутренняя Autodiscover URI

Наконец нам нужно направить внутренний URI службы Autodiscover Service на FQDN решения HLB. Это можно сделать с помощью следующих команд:

Основной центр данных:

Set-ClientAccessServer ‘Identity EX01 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk

Set-ClientAccessServer ‘Identity EX03 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml

Аварийный центр данных:

Set-ClientAccessServer ‘Identity EX02 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml

Set-ClientAccessServer ‘Identity EX04 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml

Рисунок 6: Параметры Internal Autodiscover URI

Обратите внимание, что мы направили Exchange 2010 серверы в обоих центрах данных на один и тот же autodiscover URI. Также можно направить AutoDiscoverInternalUri на CAS серверах в аварийном центре данных на ‘https://failover.exchangelabs.dk/autodiscover/autodiscover.xml’ таким образом, вы можете оказаться в ситуации, когда SCP недоступны во время аварийной ситуации. Также межсайтовый трафик, генерируемый службой Autodiscover, будет оказывать меньшее влияние на канал WAN, так как запросы autodiscover состоят из мелких текстовых файлов XML.

Создание и настройка баз почтовых ящиков

Итак, мы закончили работу со стороной CAS, и теперь можем сконцентрироваться на создании баз почтовых ящиков, а также создании и настройке группы доступности баз данных (DAG).

В тестовой среде, используемой в этом цикле статей, я создал 12 баз почтовых ящиков, распределенных на двух серверах Exchange 2010 в основном центре данных, как показано на рисунке 7 .

Рисунок 7: Базы почтовых ящиков Exchange 2010

Примечание: Поскольку Outlook 2003 клиенты не используются в этой среде и публичные папки не используются в качестве репозиториев данных, здесь нет никаких баз данных публичных папок. Если у вас иная ситуация, следует учитывать, что нельзя использовать DAG функцию для защиты данных публичных папок (как это было в случае с CCR в Exchange 2007). Вместо этого нужно создать хотя бы одну базу данных публичной папки в каждом центре данных и добавить соответствующие серверы, содержащие эти базы, в список копий для каждой публичной папки.

Как вы видите, я назвал базы DAG01-MDB001, DAG01-MDB002 и т.д. Не потому что я ленив, а потому что просто нет необходимости в использовании длинных и сложных имен для этих баз данных. Для баз данных, являющихся частью группы DAG, лучше использовать стандарты именования, в которых имени базы данных предшествует имя группы DAG, к которой эта база принадлежит. Что касается путей к папкам баз данных и журналов, то лучше использовать нечто вроде E:\DAG_name\Database_name.edb и F:\Dag_name\Database_name.

Примечание: Когда у вас есть несколько копий базы данных, вам вовсе необязательно использовать выделенные LUN для лог файлов, вы можете просто использовать тот же путь, который указан для.edb файла (в нашем примере это ‘E:\DAG_name\Database_name’). Это полностью поддерживается и является рекомендуемым методом, если вы не используете аппаратное решение VSS резервного копирования для создания резервных копий своих баз данных Exchange. Следует ли говорить о том, что необходимо использовать точки подключения, поскольку в противном случае у вас быстро закончатся буквы дисков.

Добавление группы Exchange Trusted Subsystem к серверам Non-Exchange

Те из вас, кто уже разворачивал серверы почтовых ящиков на базе Exchange 2007 CCR или Exchange 2010 Mailbox, принадлежащих к группе DAG, должны знать, что лучше использовать транспортный сервер-концентратор (Hub Transport) на этом же сайте Active Directory в качестве сервера-свидетеля для CCR кластера или DAG.

Поскольку эта среда состоит из Exchange 2010 серверов с несколькими ролями, которые являются частью одной группы DAG, мы не можем использовать Exchange 2010 Hub Transport сервер в качестве сервера-свидетеля, а должны использовать традиционный файловый сервер Windows Server 2008/R2 для этой цели. По этой причине нам нужно добавить ‘Exchange Trusted Subsystem ‘ группу, созданную установкой Exchange 2010, в группу локальных администраторов на соответствующем файловом сервере. Это делается для того, чтобы правильные разрешения были предоставлены Exchange. Для этой цели входим на файловый сервер и открываем диспетчер сервера ‘Server Manager ‘. Разворачиваем ‘Конфигурацию (Configuration) ‘ > ‘Локальные пользователи и группы (Local Users and Groups) ‘ и открываем Свойства (Properties) группы Администраторов (Administrators) .

Рисунок 8: Поиск группы локальных администраторов на файловом сервере Windows Server 2008 R2

Теперь вводим ‘Exchange Trusted Subsystem ‘ в текстовое поле, как показано на рисунке 9 , и нажимаем OK .

Рисунок 9: Ввод группы Exchange Trusted Subsystem

Еще раз жмем OK .

Рисунок 10: Страница свойств группы администраторов

Как уже говорилось, этот шаг необходим только при использовании non-Exchange сервера в качестве сервера-свидетеля.

Создание и настройка группы DAG

Поскольку активные пользователи у нас постоянно находятся в каком-то одном центре данных (модель распределения пользователей активный/пассивный), для этого сценария будет достаточно одной расширенной группы DAG.

Для создания простой группы DAG запускаем мастер создания группы ‘‘. Для этого разворачиваем рабочий центр ‘Organization Configuration’ и нажимаем правой клавишей на ‘Mailbox ‘, после чего выбираем опцию создания новой группы ‘New Database Availability Group ‘ в контекстном меню. В мастере нужно указать имя группы DAG и ввести имя сервера-свидетеля. Наконец, нам нужно указать путь каталога свидетеля. Я назову группу DAG ‘DAG01 ‘ и буду использовать присоединенный к домену файловый сервер (FS01) в качестве сервера-свидетеля. Когда все готово, нажмите ‘New ‘.

Рисунок 11: Создание группы DAG

На заключительной (Completion) странице у нас появляется предупреждение о том, что группа ‘Exchange Trusted Subsystem ‘ не является членом группы ‘Локальных администраторов (Local Administrators) ‘ на указанном сервере-свидетеле. Эту ошибку можно проигнорировать, поскольку мы уже добавили эту группу.

Нажмите Завершить (Finish) для выхода из мастера (Рисунок 12 ).

Рисунок 12: Мастер DAG ‘ заключительная страница

Настройка альтернативного сервера-свидетеля

Когда речь заходит об использовании DAG, расширенной между двумя центрами данных (AD сайтами), рекомендуется предварительно настроить альтернативный сервер-свидетель, коим в данном сценарии будет файловый сервер (FS02) в аварийном центре данных.

Для этого нам сначала нужно добавить ‘Exchange Trusted Subsystem ‘ группу в группу локальных администраторов ‘(Local Administrators) ‘ тем же способом, который описан выше. Затем нужно указать FS02, как альтернативный сервер-свидетель на самом объекте DAG. Для этого открываем страницу свойств DAG ‘DAG01 ‘. В закладке ‘Общие (General) ‘ мы видим основной сервер-свидетель FS01 и каталог свидетеля для этого сервера. Ниже у нас есть возможность ввести альтернативный сервер-свидетель (рисунок 13 ). Делаем это и нажимаем ‘Применить (Apply) ‘. Оставьте страницу свойств открытой.

Р исунок 13: Указание альтернативного сервера-свидетеля

Назначение статических IP адресов группе DAG

Хотя можно использовать DHCP назначенные IP адреса для группы DAG, я предпочитаю использовать статические адреса, поэтому следующим шагом будет назначение статического IP адреса для группы DAG в каждом центре данных (в каждой подсети).

Примечание: Если вы хотите использовать DHCP назначенные IP адреса, можете пропустить этот шаг.

Чтобы задать статический IP адрес, перейдите в закладку ‘IP Addresses ‘. В закладке ‘IP Addresses ‘ задайте IP адрес в каждой подсети для группы DAG. Затем нажмите ‘OK ‘ для выхода со страницы свойств.

Рисунок 14: Назначение статического IP адреса группе DAG

Итак, мы создали и настроили простую группу DAG.

Первая роль 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 серверами в одном сайте, так и между сайтами.

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

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

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

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

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

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

В случае если почтовый ящик находится на 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

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

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

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

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

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

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

Проксирование происходит только в случае если почтовый ящик находится на 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)

Full Internet Name: Outlook.mailmig.com

Cluster Operation Mode: Multicast

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

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

Пример настройки на 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

В данном случае все публикации настроены на одном 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

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

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

https://mail.mailmig.com/OAB — InternalURL https://mail.mailmig.com/OAB

https://mail.mailmig.com/EWS/Exchange.asmx -InternalURL https://mail.mailmig.com/EWS/Exchange.asmx -BasicAuthentication $True –WindowsAuthentication $True

https://mail.mailmig.com/Microsoft-Server-ActiveSync -InternalUrl https://mail.mailmig.com/Microsoft-Server-ActiveSync

https://mail.mailmig.com/OWA -InternalUrl https://mail.mailmig.com/OWA

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, которые подключаются из внутренних сетях будут вводить логин и пароль несколько раз.

Информация, содержащаяся в этом документе, может относиться к функциям и продуктам предварительной версии и может претерпеть значительные изменения до окончательного коммерческого выпуска. Настоящий документ предоставляется "как есть" и служит только для информационных целей. Корпорация Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, в связи с этим документом

Советы по разработке с использованием EWS для Exchange.

Область применения: Exchange Online | Exchange Server 2013 | Office 365

В этой статье приведены общие сведения о создании приложения веб-служб Exchange (EWS). С помощью этих сведений можно определить, подходит ли API EWS для вашего приложения и какой тип реализации клиента вам нужен. Эта статья также содержит рекомендации по созданию приложений для Office 365, Exchange Online и версий Exchange, начиная с Exchange 2007, с использованием одной базы данных кода. Кроме того, она помогает решить, для какой среды лучше разрабатывать решения - для локальных серверов Exchange Server или Exchange Online.

Прежде чем приступать к созданию приложения, необходимо определить, подходит ли вам API EWS. Если вы разрабатываете решение для Exchange Server или Exchange Online, EWS - предпочтительная технология клиентского доступа. Разработка решений клиентского доступа для версий Exchange, начиная с Exchange 2007, в основном ориентировалась на EWS. EWS используется для работы новых функций клиентского доступа, реализованных в Outlook. К последним относится отображение состояния "нет на месте" и сведений о доступности, впервые доступное в Exchange 2007, а также функции подсказок и получения помещений, представленные в Exchange 2010. И для внутренних, и для внешних партнеров, разрабатывающих клиентские приложения Exchange, это говорит в пользу обязательности вложений в EWS.

API EWS - основной API клиентского доступа для клиентских приложений Exchange. Но в некоторых случаях для разработки клиентских приложений могут пригодиться другие API Exchange. Например, Exchange ActiveSync обладает следующими преимуществами перед EWS:

Чтобы сделать протокол Exchange ActiveSync более компактным, проведена разметка структуры XML.

Exchange ActiveSync позволяет с помощью политик управлять клиентским доступом и использовать другие надежные решения для обмена мобильными сообщениями на предприятии.

MAPI RPC/HTTP - это еще один вариант для программирования клиентских приложений Exchange. Но тем не менее MAPI RPC/HTTP не обладает интуитивно понятным интерфейсом для связи между клиентами и сервером.

Дополнительные сведения о технологиях разработки для Exchange см. в статье .

Существует несколько способов разработки для Exchange с использованием EWS. Выбор оптимального варианта зависит от платформы разработки, инструментов, доступных реализаций и требований к приложениям для организации. Для создания клиентских приложений EWS доступны четыре основных варианта:

управляемый API EWS;

• автоматически созданные прокси EWS;

  настраиваемый клиентский API EWS.

Управляемый API EWS

API веб-службы EWS может подойти вам больше, чем управляемый API EWS, по одной из следующих причин:

ваше приложение не использует.NET Framework;

вы не хотите распространять сборку управляемого API EWS;

для приложения требуются функции, не доступные в управляемом API EWS.

Дополнительные сведения см. в статье .

As you all know that the service connectivity for a mail server is the main concern to all of us. In Exchange server 2010, the connectivity is as same as Exchange server 2007. Once you migrate or install the new version, this should be tested with the proper credentials and certificate..or else, you will end up with your mail server IP going to the blacklist, because of the wrong pointers and configurations. First of all, do the internal test. Go to your computer start bar, right side where Date and time is showing, you will find the Outlook icon, hold Ctrl + right click on the outlook icon and click “Test Email Auto Configuration…”

Select the “Use AutoDiscover” and click Test..

Above one is a success one..If failed, do the below. The Exchange Web Service (EWS) is the web service that allows access to the Out of Office service. If either the internal or external URL for the EWS is missing or incorrect, OOF will fail and other services may not work as expected. Using Exchange Management Shell, check the URLs assigned to the web service virtual directory using the Get-WebServicesVirtualDirectory command

First goto CAS server

Type the following Power Shell command for EWS (Exchange Web Service)

Copy code Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl

You will get the result like below

InternalUrl:
ExternalUrl: https://mailv.domain.com/ews/exchange.asmx

InternalUrl: https://mailv.domain.com/EWS/Exchange.asmx
ExternalUrl: https://mailv.domain.com/ews/exchange.asmx

If this is not correct, you need to fix it.. This has to be done on Powershell command on the CAS server.

To do that…Copy code

C:\Windows\system32>Set-WebServicesVirtualDirectory -Identity “ECAS1\EWS (Default Web Site)” -InternalUrl -BasicAuthentication:$true

C:\Windows\system32>Set-WebServicesVirtualDirectory -Identity “ECAS2\EWS (Default Web Site)” -InternalUrl https://mail.domain.com/EWS/Exchange.asmx -BasicAuthentication:$true

C:\Windows\system32>Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl

Identity: ECAS1\EWS (Default Web Site)
InternalUrl: https://mail.domain.com/EWS/Exchange.asmx
ExternalUrl: https://mail.domain.com/ews/exchange.asmx

Identity: ECAS2\EWS (Default Web Site)
InternalUrl: https://mail.domain.com/EWS/Exchange.asmx
ExternalUrl: https://mail.domain.com/ews/exchange.asmx

Now you can see that the URL has been fixed. This is for Web Services.

Now for Autodiscovery….

C:\Windows\system32>Get-AutodiscoverVirtualDirectory

To see the settings

C:\Windows\system32>

C:\Windows\system32>Get-ClientAccessServer |fl identity,autodiscoverserviceinternaluri
Identity: ECAS1
https://mailv.domain.com/Autodiscover/Autodiscover.xml

Identity: ECAS2
AutoDiscoverServiceInternalUri: https://mailv.domain.com/Autodiscover/Autodiscover.xml

C:\Windows\system32>Set-ClientAccessServer -Identity ECAS1 -AutoDiscoverServiceInternalUri https://mail.domain.com/Autodiscover/Autodiscover.xml
C:\Windows\system32>Set-ClientAccessServer -Identity ECAS2 -AutoDiscoverServiceInternalUri https://mail.domain.com/Autodiscover/Autodiscover.xml

Now for the Outlook Web Apps, Exchange Control Panel, Exchange ActiveSync, Offline Address book…you have to go to Exchange Management Console (EMC)

1. Goto one of the CAS server
2. Open EMC
3. Goto Server Configuration
4. Select Client Access
5. On the Middle top pannel, you can see the CAS server listed.
6. Select one, on the bottom pannel, you will see like below.

Select each tab and then right click on the object and change the path as required. Once you done with the first CAS servr, do the same for the second as well.

Thats it…you are good to go for production.