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

Материал из Rosalab Wiki

Назначение

В этой инструкции описано подключение различных почтовых клиентов к серверу Microsoft Exchange. Цель - получить систему, по функциональности соответствующую Microsoft Outlook.

Входные данные

В примерах используется сервер Microsoft Exchange 2010 (v14.03.0361.001) Service Pack 3 Update RollUp 18. Тестирование производится внутри корпоративной сети. На DNS-серверах указаны внешние почтовые адреса для почтового сервера. На сервере Exchange должны работать:

OWA (Outlook Web Access) - веб-клиент для доступа к серверу совместной работы Microsoft Exchange
OAB (Offline Address Book) - автономная адресная книга
EWS (Exchange Web Services) - сервис, предоставляющий доступ к данным почтового ящика, хранящимся в Exchange Online (как часть Office 365) и в локальной версии Exchange (начиная с Exchange Server 2007)

Параметры сервера Exchange

Важным моментом для успешной работы не-Microsoft-клиентов на Exchange 2010 является проверка подлинности. Посмотреть её параметры можно на сервере Exchange с ролью CAS (Client Access Server). Запустите оснастку «Диспетчер служб IIS» и откройте вкладку «Сайты»/Default Web Site. Обратите внимание на проверку подлинности в трёх компонентах:

OWA - Состояние «Включён » для «Обычная проверка подлинности » и «Проверка подлинности Windows »:

OAB - Состояние «Включён » для «Обычная проверка подлинности » и «Проверка подлинности Windows »:

EWS - Состояние «Включён » для «Анонимная проверка подлинности », «Обычная проверка подлинности » и «Проверка подлинности Windows »:

Прослойки (посредники) и вспомогательные утилиты

DavMail

Некоторые почтовые клиенты не могут напрямую подключаться к Microsoft Exchange и требуют использования прослойки (посредника). В данном примере в качестве посредника используется прокси-сервер DavMail .

Установите DavMail , получив права администратора при помощи su или sudo:

sudo urpmi davmail

Запустите DavMail :

На вкладке «Main» в поле «OWA (Exchange) URL » введите адрес своего сервера в формате «https:///EWS/Exchange.asmx» или ссылку на OWA

в формате «https:///owa».

Запомните номера портов «Local IMAP port » и «Local SMTP port ». В данном примере это 1143 и 1025, соответственно.

Чтоб каждый раз не запускать вручную сервер DavMail , нужно добавить его вызов в автозагрузку.

Зайдите в меню «Параметры системы → Запуск и завершение → Автозапуск », нажмите на кнопку [Добавить приложение ] и в строке поиска введите «davmail», после чего нажмите [ОК ]:

Теперь локальный прокси-сервер DavMail будет запускаться при старте системы автоматически. Если вам мешает его значок в «Панели задач», есть возможность его спрятать. Для этого в файлe .davmail.properties отредактируйте строку davmail.server=false , поменяв false на true:

Sudo mcedit /home/<имя_пользователя>/.davmail.properties

Почтовые клиенты для подключения к Exchange

Теперь можно приступить к настройке почтовых клиентов.

Thunderbird

Mozilla Thunderbird является основным почтовым клиентом для дистрибутивов ROSA Linux и, скорее всего, он уже установлен в вашей системе и готов к работе. Если же нет, его можно установить из репозиториев ROSA. В данном примере используется версия 52.2.1.

Установите Thunderbird :

sudo urpmi mozilla-thunderbird

Добавьте русскоязычный интерфейс:

sudo urpmi mozilla-thunderbird-ru

Установите дополнение lightning, позволяющее использовать календари:

sudo urpmi mozilla-thunderbird-lightning

Запустите Thunderbird .

В разделе «Учётные записи » в пункте «Создать учётную запись » выберите «Электронная почта ». Появится окно приветствия.

В открывшемся окне нажмите на кнопку [Пропустить это и использовать мою существующую почту ].

В окне «Настройка учётной записи почты » введите в поля «Ваше имя », «Адрес эл. почты » и «Пароль » свои учётные данные.

Нажмите [Продолжить ]. Программа попытается найти подключения (безуспешно), и появится сообщение об ошибке:

Здесь вам понадобятся номера портов, которые вы запомнили при настройке DavMail .

Для категорий «Входящая » и «Исходящая » измените имя сервера на «localhost».
Укажите для «IMAP » порт 1143, а для «SMTP » - порт 1025.
В поле «Имя пользователя » укажите UPN (User Principal Name) - доменное имя пользователя в формате «ИмяПользователя@ДоменОрганизации.ru».
Нажмите на кнопку [Перетестировать ].

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

Создание календаря пользователя

В категории «Учётные записи » выберите пункт «Создать новый календарь ».
В появившемся окне выберите значение «В сети » и нажмите [Далее ].
Выберите формат «CalDAV » и в поле «Адрес » введите «http://localhost:1080/users/ /calendar»:

Создание адресной книги

Адресная книга Thunderbird не поддерживает протокол CardDAV и может быть подключена только к каталогу LDAP сервера Exchange.

Откройте существующие адресные книги, нажав на кнопку [Адресная книга ] и выбрав пункт «Файл → Создать → Каталог LDAP ».

В окне мастера укажите следующие параметры:
- Название - любое подходящее имя
- Имя сервера - localhost
- Корневой элемент (Base DN) - ou=people
- Порт - 1389 (из Davmail )
- Имя пользователя (Bind DN) - UPN-имя пользователя

Нажмите [ОК ]. Программа попросит ввести пароль.

Зайдите в меню параметров Thunderbird . В категории «Составление » выберите вкладку «Адресация » и под текстом «При вводе адреса искать подходящие почтовые адреса в» отметьте пункт «Сервере каталогов », выбрав имя вашей адресной книги.

Evolution

В репозиториях ROSA также доступен почтовый клиент Evolution (в данном примере используется версия 3.16.4).

Установите Evolution :

sudo urpmi evolution

Установите коннектор Exchange , совместимый с версией 2007 и более поздними:

sudo urpmi evolution-ews

Запустите Evolution .

В окне мастера нажимайте кнопку [Следующая ], пока не перейдёте на вкладку «Учётная запись ».
Заполните поля «Полное имя » и «Электронная почта ».
На вкладке «Получение почты » в списке «Тип сервера » выберите «Exchange Web Services».
В качестве имени укажите UPN-имя пользователя в формате «ИмяПользователя@ВашДомен.ru».
В поле «Host URL » введите «https://ИмяПочтовогоСервераExchange/EWS/Exchange.asmx .
В поле «OAB URL » введите URL автономной адресной книги.
В качестве вида аутентификации выберите «Basic».

При успешной настройке программа запросит пароль:

После ввода пароля Evolution получит доступ к вашему почтовому ящику, адресной книге и календарям.

По любым вопросам, связанным с этой статьёй, просьба обращаться по адресу [email protected].

С выходом Exchange 2010, клиенты Outlook MAPI используют роль сервера Client Access Server (CAS) на среднем уровне в качестве конечной точки RPC, что привело к тому, что данная роль является еще более важной, чем в предыдущих версиях продукта. По этой причине всем организациям (большим и малым) стоит задуматься о том, чтобы сделать эту роль постоянно доступной посредством установки нескольких серверов CAS на каждом сайте Active Directory, а также использовать компенсацию нагрузки протоколов и сервисов, предоставляемых этой ролью.

Поскольку у меня очень удачный опыт с устройствами от компании KEMP Technologies и поскольку эти устройства доступны даже для средних и малых организаций, которые, как правило, разворачивают полностью избыточные решения Exchange, состоящие из двух серверов Exchange 2010 с несколькими ролями, я использовал устройства LoadMaster 2000 настроенные в кластере (один узел активный и один - аварийный) в качестве базы для этой статьи. Моя конфигурация показана на рисунке 1 ниже.

Рисунок 1: Топология, используемая в этой тестовой среде

Примечание: очень важно выделить тот факт, что я никак не связан с компанией KEMP Technologies. К тому же мне не платили, чтобы я советовал читателям использовать устройства распределения нагрузки, поставляемые этой компанией. Я просто делаю это исключительно по той причине, что у меня есть очень удачный опыт работы с этими устройствами.

Как на счет обратных прокси, таких как TMG/ISA/IAG/UAG?

Можно ли использовать одно из этих решений для компенсации нагрузки различных протоколов и служб на сервере CAS? Конечно же, можно! По крайней мере, можно компенсировать нагрузку для всего, что идет по протоколам HTTP и HTTPS. Однако ни одно из этих решений не может выполнять компенсацию нагрузки для RPC трафика. Читайте дополнительную информацию в этом новостном письме , которое я написал пару месяцев назад. К тому же вам, возможно, не нужно, отправлять трафик с внешних клиентов на решение обратного прокси в своей демилитаризованной зоне и обратно. Наконец, если вы осуществляете компенсацию нагрузки для трафика HTTP/HTTPS, используя одно из вышеупомянутых решений в качестве внутреннего решения HLB, также важно упомянуть, что вам нельзя настраивать их обращение к VIP/FQDN устройства HLB, а вместо этого обратный прокси-сервер будет самостоятельно распределять трафик между CAS серверами массива CAS.

Какой тип родства (affinity) мне следует использовать?

Персистентность (также известная, как родство) представляет собой возможность компенсатора нагрузки сохранять подключение между клиентом и сервером. Она позволяет быть уверенным в том, что все запросы с клиента направляются на один и тот же сервер в NLB массиве или серверной ферме (в случае с Exchange CAS массивом).

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

Клиенты Exchange:

Outlook Web App (OWA) - для OWA рекомендуемым способом родства является клиентский IP (IP адрес источника) или Cookie (существующие cookie или созданные аппаратным компенсатором нагрузки, также известные как LB-cookie). Оба способа работают в большинстве конфигураций, но если вы работаете со средами, где клиенты представляются, как исходящие с одного IP адреса источника, следует избегать использования Client IP и вместо этого использовать cookie. Не рекомендуется использовать персистентность на базе SSL ID в OWA, поскольку этом может привести к тому, что пользователям нужно будет повторно проходить проверку подлинности, потому что такие обозреватели, как Internet Explorer 8, создают новые отдельные рабочие процессы, например, при создании нового сообщения в OWA. Проблема здесь в том, что с каждым новым рабочим процессом используется новый SSL ID.
Exchange Control Panel (ECP) - те же рекомендации, что и для предыдущего клиента.

Exchange ActiveSync (EAS) - для Exchange ActiveSync рекомендуемым способом родства являются Client IP (исходный IP адрес) или заголовок авторизации (Authorization header). Если ваша организация использует одного поставщика мобильных/сотовых сетей для всех пользователей, подключающихся к Exchange с помощью EAS, то велики шансы того, что они все будут представляться, как исходящие с одного IP адреса, поскольку NAT часто используется в сотовых сетях. Это означает, что вы не сможете получить оптимального распределения EAS трафика между CAS серверами за NLB массивом. Поэтому для EAS лучше использовать HTTP заголовок авторизации в качестве ключа родства. И опять же, не рекомендуется использовать персистентность на основе SSL ID для EAS, поскольку некоторые мобильные устройства пересматривают параметры SSL безопасности довольно часто.

Outlook Anywhere (OA) - для Outlook Anywhere (также известной как RPC через HTTP) рекомендуемым методом родства будет Client IP (исходный IP адрес), заголовок авторизации или персистентность на основе "OutlookSession" cookie. Если клиенты OA представляются, как исходящие с одного Client IP, то следует использовать заголовок авторизации или "OutlookSession" cookie. Следует помнить, что родство на основе "OutlookSession" поддерживается только в клиентах Outlook 2010.

IMAP и POP3 - IMAP и POP3 не требуют никаких параметров родства, поэтому здесь нет рекомендаций к настройке персистентности.

Сервисы Exchange:

Autodiscover- служба Autodiscover не требует никаких определенных параметров родства, поэтому здесь нет рекомендаций к настройке персистентности.

RPC Client Access Service (RPC CA)- для службы RPC CA, используемой в качестве конечной точки для внутренних клиентов Outlook, рекомендуемым способом родства является Client IP.

Exchange Address Book Service- те же рекомендации, что и для службы RPC CA.

Exchange Web Services (EWS)- для EWS рекомендуемым способом родства является cookie или SSL ID.

Теперь, поскольку многие из вышеуказанных клиентов и служб используют один и тот же порт, зачастую можно указывать лишь один способ родства для всех клиентов и служб, использующих один порт/IP адрес. Если вы хотите использовать различные способы персистентности, допустим для OWA и OA, в зависимости от вашего HLB решения, это может быть возможным (с использованием раздельного родства и т.п.), но это не входит в рамки нашей статьи. Вместо этого я рекомендую вам связаться с поставщиком вашего HLB решения.

Параметры таймаута для каждого протокола и службы

Для каждой виртуальной службы вы можете задавать значения таймаута для сеансов, которые создаются с различных клиентов к HLB решению (память, ЦП и т.д.).

Чтобы оптимально использовать свое HLB решение, не следует задавать слишком высокие значения для этих таймаутов, но также следует опасаться установки слишком низких значений для этих параметров, поскольку это может привести к необходимости клиентов в повторном создании сеанса, а это в свою очередь может заставлять конечных пользователей снова проходить проверку подлинности.

Нет нужды говорить о том, что вам нужно задавать значения таймаутов для протоколов и служб, таких как OWA, ECP, EAS, Outlook Anywhere и RPC CA на довольно высоком уровне (несколько часов, например, рабочие часы), а для таких служб как IMAP, POP, AutoD, EWS, OAB эти значения должны быть относительно низкими (как правило, всего несколько минут). Чтобы не попасть в трудности, свяжитесь с поставщиком вашего HLB решения для получения информации о том, какие настройки рекомендованы для него.

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

Создание необходимых виртуальных служб в решении компенсатора нагрузки

Рисунок 28: Проверка SSL цепи с помощью диагностического инструмента DigiCert SSL Diagnostics

Если в результатах этого инструмента у вас везде стоят зеленые галочки, то все работает нормально. Но также необходимо проверить доступ, используя настоящие клиенты Exchange.

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

Генрик Валзер (Henrik Walther) является Microsoft Exchange MVP и работает в качестве Старшего Технического Консультанта в Interprise, Золотом Партнере Microsoft, расположенном в Дании. Вы можете посетить его web-сайт по адресу: www.exchange-faq.dk (на датском).

Приветствую всех читателей нашего Блога! Сегодня я расскажу вам о том, как за несколько минут настроить публикацию почтового сервера 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.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

Настройка почтового сервиса на базе Exchange 2010.

Есть мнение, что в сети нет достаточно подробных инструкций по настройке сервера Exchange 2010 на работу с внешней почтой. В данной статье я постараюсь как можно более подробно и доступно описать процесс настройки Exchange Server 2010 для работы с внешней электронной почтой через Edge Transport Server.
Для того чтобы сделать действительно полный Step-by-Step Guide, давайте рассмотрим процесс настройки внешней почты с самого начала. Как правило, данный процесс состоит из трех основных этапов:

Регистрация доменного имени предприятия;
Настройка MX записи на DNS сервере, обслуживающем доменное имя;
Настройка Exchange сервера на работу с внешним доменом.

На первом пункте мы останавливаться не будем, т.к. у подавляющего большинства компаний уже есть свое доменное имя в сети Интернет, а те, у кого ещё нет, могут легко его купить у любого регистратора (например, RU-CENTER www.nic.ru). Зарегистрировав доменное имя, вам нужно будет найти и прописать в настройках домена, по крайней мере, два DNS сервера, которые будут его обслуживать, это также можно сделать у регистратора, либо воспользоваться бесплатными DNS-серверами (например, http://freedns.ws/ru/).
Первый этап пройден, теперь у провайдера нужно получить статический IP-адрес для своей организации и можно переходить ко второму этапу – настройке MX-записи на DNS сервере, обслуживающем внешний домен. Запись типа MX (Mail Exchange — почтовый сервер) определяет почтовый сервер, который будет обрабатывать почту для вашего домена.

Редактируем зону на DNS сервере следующим образом:

Регистрируем А-запись, например mail.firma.ru и указываем для неё внешний IP-адрес, на котором опубликован сервер Exchange;
Регистрируем MX-запись и указываем для неё имя хоста — mail.firma.ru.

Примечание : Если вы только что создали зону для вашего домена, то не думайте, что ping firma.ru будет сразу указывать на нужный IP, может потребовать довольно продолжительное время для того, чтобы все DNS сервера Интернета «узнали» о внесенных изменениях.

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

Проверяем MX-запись домена (к примеру, mail.ru):

nslookup -type=mx mail.ru

В результате, мы узнали, что почта на mail.ru ходит через хост mxs.mail.ru .

Проверяем IP-адрес хоста mxs.mail.ru :

nslookup mxs.mail.ru 8.8.8.8

Примечание : В данном примере мы проверяем, что «знает» о хосте mxs.mail.ru не наш локальный DNS-сервер, а DNS сервере Google`a (8.8.8.8).

Рис.1: Проверка MX-записи.

Если все настроено правильно и MX-запись вашего домена резолвится во внешний IP-адрес вашего сервера, то можно приступать непосредственно к настройке Exchange`a.
Публикация сервера Exchange.

Есть два варианта публикации сервера Exchange в сети Интернет:

Сервер с ролью Hub Transport находится в локальной сети предприятия и публикуется в Интернет через корпоративный Интернет шлюз;
На шлюзе публикуется сервер с ролью Edge Transport , который располагается в DMZ-зоне и пересылает почту на локальный Hub Transport .

В данной статье будет рассмотрен второй и наиболее правильный (на мой взгляд) вариант публикации сервера Exchange. Возможным минусом данной схемы является то, что вам необходимо будет приобрести дополнительную лицензию на Exchange Server 2010 и установить дополнительный Windows Server 2008.
Примечание : Чтобы сэкономить на лицензии Windows Server и на аппаратном обеспечении, малые и средние организации могут поставить роль Edge Transport прямо на шлюз под управлением Threat Management Gateway (TMG) , такая конфигурация официально поддерживается компанией Microsoft, поэтому так мы и сделаем (на ISA-сервер поставить Edge не получится). Подробнее про установку Exchange 2010 Edge Transport на TMG можно прочитать тут — http://www.alexxhost.ru/2010/04/exchange-server-2010-edge-server.html .

В результате, схема нашей организации Exchange будет выглядеть следующим образом:

Рис.2: Схема организации Exchange.

Процесс инсталляции серверов и ролей Exchange 2010 я рассматривать в этой статье не буду, т.к. ни чего сложного в этом нет и данная тема, уже не однократно описывалась в других источниках. Давайте основное внимание уделим конфигурированию.
Коммутация почты через Edge Transport

Перед тем как начать настройку, давайте разберемся, как будет происходить взаимодействие пограничного почтового сервера (Edge) с локальным сервером концентратором (Hub). Для обмена сообщениями между серверами, в Exchange`e используются коннекторы (соединители), именно их и нужно настраивать для правильной коммутации почты. Рис.3 иллюстрирует процесс получения и отправки сообщений через пограничный сервер Edge Transport:

Рис.3: Коммутация сообщений через Edge Transport.

В результате используются 6 коннекторов:

Получение внешней почты Edge сервером;
Оправка почты с Edge-сервера на Hub-сервер;
Получения Hud-сервером почты с Edge-сервера;
Отправка локальной почты в Интернет через Edge-сервер;
Прием Edge-сервером почты с Hub-сервера;
Отправка Edge-сервером почты в Интернет.

Схема, на первый взгляд, не простая, но разработчики сервера Exchange позаботились об администраторах и создали процедуру подписки Edge Transport сервера (Edge Subscription ), в результате которой, помимо, всех прочих настроек, можно создать необходимые коннекторы отправки автоматически.
Настройка сетевых параметров Edge Transport сервера

Перед тем, как оформлять подписку нужно правильно настроить сетевые параметры на сервере с ролью Edge Transport. Напомню, что в данном сценарии он не включён в доменную структуру предприятия, находится в DMZ-зоне и расположен на одном сервере с TMG (не забудьте правильно настроить правила на TMG для отправки/получения почты). Исходя из данного сценария, рекомендуется сделать следующие настройки:

Получить у провайдера и установить на внешнем интерфейсе сервера IP-адрес (на который указывает ранее настроенная MX-запись), маску, шлюз и адреса DNS серверов провайдера;
Если у вас в DMZ-зоне нет своего DNS-сервера, то нужно прописать в файл hosts в папке \%Systemroot%\System32\Drivers\Etc сопоставление имени Hub Transport сервера с его IP-адресом, т.е. добавить в конец файла строчку вида 192.168.0.10 hub.domain.local ;
На интерфейсе, смотрящем в локальную сеть предприятия установить IP-адрес и маску. Шлюз вписывать НЕ нужно;
Настроить имя и DNS-суффикс компьютера, как показано на рис.4. (потом изменить эти настройки не получится);

Рис.4: Настройка DNS-суффикса сервера.

На локальном DNS сервере создать А-запись, указывающую на IP-адрес Edge-сервера.

В результате Edge сервер должен уметь резолвить адреса Интернета и адрес сервера с ролью Hub Transport, а Hub Transport сервер, в свою очередь, должен знать, как найти Edge-сервер по его FQDN-имени (для проверки можно использовать команды ping и nslookup ).
Оформление Edge Subscription

Как уже говорилось выше, компьютер, на котором установлена роль пограничного транспортного сервера, не имеет доступа к Active Directory . Все сведения о конфигурации и получателях хранятся в экземпляре служб облегченного доступа к каталогам (AD LDS ) Active Directory. Данную службу заранее придется установить, как показано на рис.5.

Рис.5: Установка службы облегченного доступа к каталогам (AD LDS).

Для выполнения задач, связанных с поиском получателей, пограничному транспортному серверу требуются данные, которые находятся в Active Directory. Эти данные синхронизируются с пограничным транспортным сервером с помощью EdgeSync. EdgeSync представляет собой коллекцию процессов, выполняемых на компьютере с ролью транспортного сервера-концентратора (Hub Transport) для организации односторонней репликации сведений о получателе и конфигурации из Active Directory в AD LDS на пограничном транспортном сервере (Edge Transport).
После установки AD LDS и правильной настройки сетевых параметров можно приступать к конфигурированию совместной работы Edge и Hub Transport серверов. Для этого оформим Edge Subscription следующим образом:

На сервере c ролью Edge Transport выполним команду:

New-EdgeSubscription –FileName c:\edge_subscr.xml

Рис.6: Создание Edge Subscriprion.

Полученный файл edge_subscr.xml скопируем на локальный Hub Transport сервер;
Зайдем в консоль управления Exchange -> раздел Конфигурация организации -> действие New Edge Subscription …

Рис.7: Создание Edge Subscription на сервере Hub Transport.

Выберем необходимый сайт AD и XML файл подписки. Не забудем оставить включенной галочку для автоматического создания отправляющих коннекторов.
После завершения работы мастера, будут созданы коннекторы отправки, и через некоторое время будет выполнена синхронизация с сервером Edge Transport. Чтобы не дожидаться сеанса синхронизации, его можно выполнить вручную командой:

Start-EdgeSynchronization

Настройка дополнительных параметров Exchange 2010

Процесс Edge Subscription хоть и значительно облегчает жизнь администраторам, но не делает всю работу за них. Некоторые настройки придется доделать вручную:
Создание коннекторов

Как уже говорилось выше, для успешной коммутации почты через Edge сервер необходимо иметь, по крайней мере, 6 коннекторов. Давайте проверим, какие из них у нас есть по умолчанию:

Рис.8: Коннектор получения на сервере Edge Transport

По умолчанию на сервере Edge Transport создан коннектор, принимающий почту с любых сетевых интерфейсов и с любых внешних и внутренних IP-адресов, соответственно позиции 1 и 5 со схемы на рис.3 у нас уже есть.
Идем дальше и посмотрим на отправляющие коннекторы:

Рис.9: Отправляющие коннекторы

Во время создания Edge Subscription была оставлена включенной опция создания отправляющих коннекторов (см. рис.7). Теперь мы можем видеть в свойствах Hub Transport`a, на уровне организации, эти два автоматически созданных коннектора. Раз эти коннекторы на уровне организации, то соответственно они будут и у всех остальных серверов Exchange в домене, Edge Transport в этом случае не исключение, разница будет лишь только в том, что на Edge`e эти они доступны только для чтения (read only). В результате коннектор Default-First-Site-Name to Internet будет выполнять задачи 4-го и 6-го коннекторов из нашей схемы, а Inbound to Default-First-Site-Name – 2-го .
Таким образом, мы имеем пять коннекторов из шести. Не хватает принимающего коннектора на сервере Hub Transport (№3 на схеме), точнее он есть — Default HubName , но, ИМХО, правильнее будет сделать отдельный. Чтобы создать получающий коннектор, перейдем на уровень конфигурации серверов , выберем роль Hub Transport и в меню действие нажмем кнопку New Receive Connector .

Рис.10: Создание получающего коннектора на Hub Transport сервере.

Впишем имя коннектора и укажем, что он будет Internal , т.е. будет работать с Exchange серверами нашей организации. На следующем шаге мастера укажем, что почту необходимо получать с IP адреса сервера Edge Transport . Завершим создание нажатием кнопки New .
Завершив работу с коннекторами, давайте перейдем к созданию политик для приема почты.
Создание Accepted Domain и E-mail Address Policy

Обслуживаемый домен (Accepted Domain) — это любое пространство имен SMTP, для которого организация Microsoft Exchange отправляет и принимает электронную почту. В связи с тем, что имя внешнего домена у нас отличается от локального (firma.ru и domain.local), необходимо на уровне организации добавить обслуживаемый домен firma.ru , с той целью, чтобы сервер Exchange смог с ним работать.
Для этого перейдем на уровень конфигурирования организации -> Hub Transport -> Accepted Domain .

Рис.11: Создание нового обслуживаемого домена.

В мастере заполним отображаемое имя обслуживаемого домена, впишем сам домен и укажем, что домен будет Authoritative , т.к. почтовые ящики получателей будут находится в этом SMTP домене.
Для того, чтобы пользователь мог получать и отправлять почту через обслуживаемые домены, ему необходимо создать дополнительные адреса электронной почты, делается это с помощью политик адресов электронной почты.
E-mail Address Policy создаются на уровне организации в свойствах роли Hub Transport, выбором действия New E-mail Address Policy…

Рис.12: Добавление E-mail Address Policy.

Политику нужно применить ко всем типам получателей, без каких либо фильтров, привязать к нужному FQDN имени (как показано на рис.12) и указать в расписании немедленное выполнение (Immediately). В результате, политика адресов электронной почты (E-mail Address Policy), будучи привязанной к доверенному домену (Accepted Domain), автоматически создаст соответствующие адреса электронной почты всем получателям, к которым она применена.
Примечание : Создание дополнительных адресов у получателей происходит не сразу, поэтому, чтобы не ждать, вы сами можете добавить e-mail адрес в свойствах почтового ящика, либо выполнить командлет Update-EmailAddressPolicy.

Вы должны создать две политики – одну для домена firma.ru , другую для domain.local . В результате, каждый получатель в организации будет иметь по 2 e-mail адреса, причем в качестве обратного адреса , будет использоваться тот, который принадлежит политике с меньшим номером приоритета.
На этом работа с сервером Hub Transport завершена и можно переместиться на Edge Transport.
Переопределение адресов (Address Rewriting)

В связи с тем, что у нас имена внешнего домена и домена AD отличаются, нам переписывать адреса во входящих и исходящих сообщениях (*.ru <-> *.local ). В Microsoft Exchange Server 2010 для этих целей есть функция переопределения адресов (Address Rewriting) , которая позволяет изменять адреса отправителей и получателей во входящих и исходящих сообщения. Подробнее про данную функцию можно почитать тут — http://technet.microsoft.com/ru-ru/library/aa996806.aspx .
Для добавления политики переопределения адресов воспользуемся командлетом New-AddressRewriteEntry на сервере Edge Transprot :
New-AddressRewriteEntry –Name «Lan — Internet» –InternalAddress «domain.local» – ExternalAddress «firma.ru»

Рис.13: Добавление политики переопределения адресов.

Примечание : Данная политика применяется не сразу, для немедленной её активации можно в ручную перезапустить службу Microsoft Exchange Transport.

Возможные проблемы

На этом базовая настройка Exchange Server 2010 на работу с внешней почтой через сервер Edge Transport, расположенный в DMZ-зоне предприятия, закончена. Следующим шагом будет проверка отправки и получения этой почты. Если по каким либо причинам почта не отправляется, либо не принимается, то я посоветовал бы для начала выполнить следующие шаги:

Воспользоваться мастером Remote Connectivity Analyzer , расположенном в меню Toollbox . Данный мастер отправит вас на страничку http://testexchangeconnectivity.com/ , с которой можно произвести тестирование многих сервисов Exchange`a.
Посмотреть очередь сообщений Toolbox -> Queue Viewer с той целью, чтобы определить, на какой стадии зависло письмо. Данная утилита может показать не только очередь сообщений, но также текст последних ошибок, которые произошли с конкретной очередью и заголовки писем, находящихся в ней.
Команда telnet YourServer 25 поможет вам проверить, доступны ли ваши сервера для приема почты.
Если в Queue Viewer вы обнаружили проблемы связанные с DNS, то скорее всего вы не правильно настроили сетевые параметры интерфейсов, либо неверно отредактировали файл hosts.
Также, для Edge Transport сервера можно указать адреса DNS-серверов, отличные, от тех, которые установлены на сетевых интерфейсах, делается это в меню Properties выбранного сервера – вкладки Internal DNS Lookups и External DNS Lookups .
На коннекторах необходимо проверить вкладки Network , Authentication и Permission Group .
После внесенных изменений на Hub Transport`e не забывайте выполнять синхронизацию (Start-EdgeSynchronization).
Если ничего из выше озвученного не помогает, то можно посмотреть в сторону анализа логов системы, и включить Protocol Logging на вкладке General в свойствах коннекторов. Подробнее про анализ журналов транспорта можно почитать тут — http://technet.microsoft.com/ru-ru/library/aa998617.aspx .

Forefront Threat Management Gateway (TMG) 2010 включает поддержку публикации Microsoft Exchange Outlook Web App (OWA) для Exchange 2010, а также Outlook Web Access для Exchange 2007, 2003 и 2000. В первой части этого цикла из двух частей мы рассмотрели, как подготавливать CAS сервер к публикации. Во второй части мы поговорим о шагах, необходимых для публикации Exchange OWA 2010 с помощью TMG. Если вы хотите прочитать первую часть этого цикла статей, перейдите по ссылке Публикация Exchange Outlook Web App (OWA) в Microsoft Forefront Threat Management Gateway (TMG) 2010: часть 1 – Подготовка сервера клиентского доступа (CAS) .

Введение

Импорт сертификата

Прежде чем мы сможем опубликовать OWA, нам сначала нужно импортировать SSL сертификат сайта на брандмауэр TMG. Для выполнения этой задачи переходим в меню Пуск / Выполнить и вводим mmc.exe . Из раскрывающегося списка выбираем Файл / Добавить или удалить оснастку . Выбираем Сертификаты , затем нажимаем Добавить .

Выбираем опцию Учетная запись компьютера (Computer Account) .

Выбираем опцию управления локальным компьютером (Local computer) .

В дереве консоли разворачиваем узел Сертификаты (Certificates) . Разворачиваем папку Личные (Personal) , нажимаем правой клавишей на папке Сертификаты (Certificates) и выбираем Импортировать (Import)

Указываем место файла сертификата, экспортированного ранее.

Вводим пароль и (необязательно) отмечаем закрытый ключ как экспортируемый.

Принимаем опцию по умолчанию Разместить все сертификаты в следующем хранилище (Place all certificates in the following store) .

Создание правила публикации OWA

В консоли управления TMG нажимаем правой клавишей на узле политики брандмауэра (Firewall Policy) в дереве консоли и выбираем Новая (New) , а затем Правило публикации клиента (Exchange Web Client Access Publishing Rule)

Задаем правилу публикации значимое название.

Выбираем Exchange Server 2010 из раскрывающегося списка и выбираем опцию публикации Outlook Web Access .

В целях демонстрации мы будем публиковать один CAS сервер, поэтому выбираем опцию Опубликовать один веб сайт или компенсатор нагрузки (Publish a single web site or load balancer) .

Выбираем опцию Использовать SSL для подключения к публичному веб серверу или ферме серверов (Use SSL to connect to the published web server or server farm) .

Вводим имя внутреннего веб сайта.

Выбираем опцию приема запросов для определенного домена, и затем вводим публичное имя (public name) веб сайта.

Выбираем опцию Выбрать сертификат (Select Certificate) и указываем ранее импортированный сертификат.

Выбираем опцию Использовать HTML аутентификацию на основе форм (HTML Form Authentication) и Windows (Active Directory) для проверки учетных данных.

При необходимости включаем SSO.

Способ проверки подлинности, используемый брандмауэром TMG должен совпадать со способом аутентификации настроенным на веб сайте. Поскольку мы включили простую аутентификацию на веб сайте, мы выберем опцию Простая проверка подлинности (Basic Authentication) здесь.

Если вы хотите предоставить доступ к OWA только для определенных пользователей и/или групп, добавьте их здесь. В противном случае примите группу Все аутентифицированные пользователи (All Authenticated Users) по умолчанию.

Для подтверждения операции, нажмите кнопку Проверить правило (Test Rule) .

TMG будет тестировать правило и предоставит отчет о его работоспособности или неработоспособности.

Заключение

После подготовки Exchange Client Access Server (CAS) в первой части этого цикла во второй части мы настроили Forefront Threat Management Gateway (TMG) на безопасную публикацию Exchange Outlook Web App 2010. Мы импортировали SSL сертификат и рассмотрели работу мастера создания правила публикации Exchange Web Client Access Publishing Rule, а также воспользовались функцией диагностики в TMG для проверки корректности настройки правила публикации.

Копи фром http://spravka.zhavoronki.biz

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