Подключение почтовых клиентов к Microsoft Exchange Server. Подход Microsoft к настройке OWA
Www.microsoft.com
Внутренние и внешние URL Exchange 2013 нужны для доступа к тем или иным службам из различного расположения — из локальной сети или интернета. По умолчанию при установке сервера заданы лишь внутренние URL и ссылаются они на fqdn сервера, а внешние URL отсутствуют полностью. .
Эта статья является пятой из цикла, в котором освещены вопросы обязательных задач по настройке сервера Exchange 2013 сразу после его установки. Если вам интересны другие задачи, рекомендую обратиться к головной статье по настройке — или основной статье тематики — .
Перейдем к основной цели этой статьи — изменению внутренних и внешних URL-адресов.
Настройка
Для этого проходим в директорию EAC — Серверы\Серверы — выделяем мышкой нужный сервер (у меня это exch02)\Изменить (значок карандаша) — Мобильный Outlook .
В поле Укажите имя внешнего узла (например, contoso.com) для подключения пользователей к вашей организации . прописываем необходимый нам внешний адрес. У меня это будет mail.bissquit.com. Также не лишним будет изменить имя внутреннего узла на аналогичное. Вам решать одинаковыми будут внешние и внутренние имена или разными, но сделать их идентичными выглядит более чем логично.
Если не меняли тип проверки подлинности, то вылезет предупреждение:
У меня нет более ранних версий Exchange, поэтому предупреждение игнорирую.
Через Powershell это сделать можно используя командлет Set-OutlookAnywhere :
PowerShell
Проверим результат:
Далее изменим настройки виртуальных каталогов, добавив в них внешний URL-адрес (по умолчанию он отсутствует) и задав аналогичный адрес для внутренних подключений. Через веб-интерфейс EAC можно выполнить соответствующие действия в каталоге Серверы\Виртуальные каталоги — выделить мышкой нужный каталог, нажать Изменить (значок карандаша), установить необходимые внутренние и внешние URL-адреса.
Повторить действия для каждого виртуального каталога, кроме Autodiscover (Default Web Site). Пример изменения свойств виртуального каталога ecp (Default Web Site) :
Для изменения настроек через PowerShell будет достаточно много команд, поскольку для каждого типа виртуального каталога существует отдельный набор командлетов:
Для изменения виртуального каталога панели управления — Set-EcpVirtualDirectory
.
Для изменения виртуального каталога Веб-служб Exchange — Set-WebServicesVirtualDirectory
.
Для изменения виртуального каталога служб Microsoft Exchange ActiveSync — Set-ActiveSyncVirtualDirectory
.
Для изменения виртуального каталога автономной адресной книги — Set-OabVirtualDirectory
.
Для изменения виртуального Outlook — Set-OwaVirtualDirectory
.
Для изменения виртуального каталога PowerShell — Set-PowerShellVirtualDirectory
.
Итак, ближе к делу:
PowerShell
Set-EcpVirtualDirectory "exch02\ecp (Default Web Site)" -InternalUrl https://mail.bissquit.com/ecp -ExternalUrl https://mail.bissquit.com/ecp Set-WebServicesVirtualDirectory "exch02\EWS (Default Web Site)" -InternalUrl https://mail.bissquit.com/EWS/Exchange.asmx -ExternalUrl https://mail.bissquit.com/EWS/Exchange.asmx Set-ActiveSyncVirtualDirectory "exch02\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl https://mail.bissquit.com/Microsoft-Server-ActiveSync -ExternalUrl https://mail.bissquit.com/Microsoft-Server-ActiveSync Set-OabVirtualDirectory "exch02\OAB (Default Web Site)" -InternalUrl https://mail.bissquit.com/OAB -ExternalUrl https://mail.bissquit.com/OAB Set-OwaVirtualDirectory "exch02\OWA (Default Web Site)" -InternalUrl https://mail.bissquit.com/owa -ExternalUrl https://mail.bissquit.com/owa Set-PowerShellVirtualDirectory "exch02\PowerShell (Default Web Site)" -InternalUrl https://mail.bissquit.com/PowerShell -ExternalUrl https://mail.bissquit.com/PowerShell
Set -EcpVirtualDirectory "exch02\ecp (Default Web Site)" -InternalUrl https : / / mail . bissquit . com / ecp -ExternalUrl https : / / mail . bissquit . com / ecp Set -WebServicesVirtualDirectory "exch02\EWS (Default Web Site)" -InternalUrl https : / / mail . bissquit . com / EWS / Exchange . asmx -ExternalUrl https : / / mail . bissquit . com / EWS / Exchange . asmx Set -ActiveSyncVirtualDirectory "exch02\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl https : / / mail . bissquit . com / Microsoft-Server -ActiveSync -ExternalUrl https : / / mail . bissquit . com / Microsoft-Server -ActiveSync Set -OabVirtualDirectory "exch02\OAB (Default Web Site)" -InternalUrl https : / / mail . bissquit . com / OAB -ExternalUrl https : / / mail . bissquit . com / OAB Set -OwaVirtualDirectory "exch02\OWA (Default Web Site)" -InternalUrl https : / / mail . bissquit . com / owa -ExternalUrl https : / / mail . bissquit . com / owa Set -PowerShellVirtualDirectory "exch02\PowerShell (Default Web Site)" -InternalUrl https : / / mail . bissquit . com / PowerShell -ExternalUrl https : / / mail . bissquit . com / PowerShell |
Переходим к следующей главе.
Настройки локального DNS-сервера
Поскольку мы указали одинаковые внутренние и внешние URL-адреса для сервисов Exchange 2013, нужно разобраться как правильно настроить записи локального DNS-сервера (забегая вперед, скажу, что это называется Split DNS).
Примечание: дело в том, что домен mail.bissquit.com будет разрешаться во внешний адрес шлюза и таким образом отправляться наружу и при попадании на шлюз разворачиваться обратно в локальную сеть. Страшного в этом ничего нет, но это явно лишний маршрут, который будет проделывать весь трафик, направляющийся к вашему Exchange 2013 из локальной сети..
На контроллере домена необходимо пройти в оснастку «DNS» и создать новую зону прямого просмотра:
Все настройки оставляем по умолчанию, только указываем необходимое имя, у меня это bissquit.com. После создания зоны необходимо добавить одну CNAME-запись. Нам нужно, чтобы mail.bissquit.com разрешалось во внутренний адрес сервера Exchange 2013:
Примечание: обратите внимание, что добавление к обслуживанию домена второго уровня может оказаться крайне плохой идеей, если этот домен (или его поддомены) подвязан к каким-то внешним ресурсам. В этом случае ваш локальный DNS-сервер будет считать себя ответственным за всю эту зону и возвращаться ответ, что, например, домена сайт не существует.
Запись создана, проверим как работает:
Имя mail.bissquit.com разрешается во внутренний адрес, все нормально, как нам и нужно. Однако при попытке «пропинговать» другой поддомен, для которого мы записи в новой зоне не создавали, разрешить имя не получается. Это происходит потому, что наш DNS-сервер считает себя ответственным (авторитативным) за весь домен bissquit.. Отправить DNS-запросы для записи сайт наружу можно с помощью делегирования:
В имени укажите необходимый домен:
Далее пропишите один (а ещё лучше несколько) из NS-серверов вашего провайдера, у которого администрируете DNS-записи. Если не знаете ни одного NS-сервера, запустите nslookup в командной строке, задайте тип записи (set type=ns), введите необходимое доменное имя (у меня это bissquit.com):
Ещё раз проверим:
Как видите, все работает. Спасибо статье на блоге Алексея. Небольшой недостаток этого метода в том, что нужно вручную прописывать все внешние поддомены. Правда у меня их пока немного, всего один.
Итак, на этом настройка DNS закончена. По большому счету к настройке внутренних и внешних URL-адресов администрирование сервера DNS относится лишь косвенным образом, но этот момент важно рассмотреть, поскольку в документации на Technet при выполнении настройки URL-адресов даются лишь общие сведения о том, какие записи DNS необходимо создать, но как это сделать и какие есть нюансы не объясняется:
После настройки внутреннего URL-адреса в виртуальных каталогах сервера клиентского доступа необходимо настроить частные записи DNS для Outlook Web App и других возможностей подключения. В зависимости от конфигурации нужно будет настроить частные DNS-записи так, чтобы они указывали на внутренний или внешний IP-адрес либо полное доменное имя сервера клиентского доступа. Ниже приведены примеры рекомендуемых DNS-записей, которые необходимо создать для подключения внутренних клиентов.
FQDN Тип DNS-записи Значение Mail.contoso.com CNAME Ex2013CAS.corp.contoso.com Owa.contoso.com CNAME Ex2013CAS.corp.contoso.com
Первая роль 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
- NLB кластер
Процесс создания кластера описан в статье Creating Network Load Balancing Clusters
Свойства кластера (Cluster Properties)
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 поддерживает режим, когда с одного клиента трафик может быть направлен на разные узлы кластера)
Пример настройки на CISCO коммутаторе:
arp IP10 MAC№1 ARPA
mac address-table static MAC№1 vlan 3 interface Po1 Po2
- Сертификаты
Сертификат для внешних публикаций
На 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.
Последовательность правил следующая:
- Exch2010OutlookAnywhere
- Exch2007OWA
- Exch2010ActiveSync
- 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, которые подключаются из внутренних сетях будут вводить логин и пароль несколько раз.
Приветствую всех читателей нашего Блога! Сегодня я расскажу вам о том, как за несколько минут настроить публикацию почтового сервера Exchange Server 2013 /2016 с помощью IIS ARR (Application Request Routing ). Но для начала немного о том, что такое публикация и для чего она нужна.Основная задача публикации это защита сервера от внешнего негативного воздействия. Сервер публикации Reverse Proxy (RP) , располагается в сети периметра (DMZ ) и передает (проксирует) запросы на почтовые сервера, в том случае, если запросы соответствуют определенным шаблонам. Логика работы RP на основе компонента ARR следующая: если поступает запрос с именем узла mail.contoso.com по протоколу HTTPS , тогда перенаправить запрос на ферму серверов mail.contoso.com . Все просто и понятно. Веб сервер используется по той простой причине, что в Exchange 2013/2016 ВСЕ подключения (кроме POP и IMAP конечно!) идут через HTTPS и неважно что вы используете, браузер или толстый клиент Outlook .
Некоторые особенности RP серверов на основе IIS ARR :
- Сервер RP
может не быть членом домена.
- Сервер должен иметь доступ к внутренней сети организации (конкретно к почтовым серверам) и внешней сети Интернет. Один из вариантов реализации это два сетевых адаптера
.
- RP должен разрешать FQDN
(полное доменное имя ex1-srv.contoso.com
, ex2-srv.contoso.com
и т.д.) почтового сервера в его IP адрес. Если в сети периметра не используется DNS сервер, необходимо прописать имена серверов и IP в файле C:\Windows\System32\Drivers\etc\hosts
.
- Убедитесь, что вы правильно настроили внутренние
и внешние URL
для виртуальных каталогов на почтовом сервере и правильно сконфигурировали сервера. Прежде чем приступать к публикации, проверьте, что все отлично функционирует в пределах локальной сети.
- DNS-суффикс
сервера RP
(в том случае, если он не включен в домен) нужно
настроить вручную
так, чтобы он был идентичен доменному (RP.contoso.com
).
- Убедитесь, что виртуальные каталоги (OWA, ECP, EWS и т.д.) опубликованы для внешних подключений с пространством имен mail.contoso.com
Приступим к установке.
1 ) Запустить PowerShell с привилегиями Администратора и выполнить
Import-Module ServerManager Add-WindowsFeature Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Net-Ext,Web-Http-Logging,Web-Request-Monitor,Web-Http-Tracing,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,NET-Framework-Core,NET-Win-CFAC,NET-Non-HTTP-Activ,NET-HTTP-Activation,RSAT-Web-ServerПроверим что все получилось, введя в браузере сервера RP
http://127.0.0.12 ) Устанавливаем 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://
- 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.
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)
- Goto one of the CAS server
- Open EMC
- Goto Server Configuration
- Select Client Access
- On the Middle top pannel, you can see the CAS server listed.
- 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.
