Главная » Мегафон » Подключение почтовых клиентов к Microsoft Exchange Server. Общие сведения о разработке клиента EWS для Exchange Создание календаря пользователя

Подключение почтовых клиентов к Microsoft Exchange Server. Общие сведения о разработке клиента EWS для Exchange Создание календаря пользователя

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.

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 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 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

В 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 ‘ для выхода со страницы свойств.