Знакомство с мастером HCW в Exchange Server 2010 SP2

Джордж Дайез (diaz@go-planet.com) — архитектор «облачных» решений в Planet Technologies, технический редактор Microsoft Press, имеет звание MVP Microsoft Exchange, участвовал в написании руководства MOS Study Guide for Office 365

У тех, кто работает в «облаке», наибольший интерес вызывает мастер гибридной конфигурации Hybrid Configuration Wizard (HCW). До выхода SP2 процесс настройки необходимых параметров, обеспечивающих взаимосвязь между локальной средой Exchange и Microsoft Office 365 был достаточно сложным. Даже при использовании Exchange Server Deployment Assistant (ExDeploy) требовалось изучить 65 страниц детальных инструкций и руководство, включающее порядка 60 (в зависимости от конфигурации) шагов, которые необходимо выполнить, чтобы подготовить локальную инфраструктуру к развертыванию гибридной конфигурации или, говоря простым языком, настроить локальные серверы для корректной связи с Exchange Online.

Разверните Exchange 2010 SP2 — он включает в себя грамотно спроектированный HCW, который сводит процесс настройки к нескольким щелчкам мыши. Точное количество шагов зависит от того, планируете ли вы задействовать централизованный или прямой способ маршрутизации почты, намерены ли использовать Exchange Online как для почтовых ящиков, так и для архивов (Full mode) или только для архивов, а также от степени совместного использования информации о доступности (free/busy). Многие с нетерпением ждали появления HCW и с выходом SP2 установили его на свои системы. В настоящее время HCW успешно справляется со своей задачей по упрощению и автоматизации развертывания гибридной конфигурации и требует минимальных усилий со стороны администратора.

Хоть я и приветствую достижения Microsoft, меня беспокоит будущее тех администраторов, у которых не было шанса пройти сложный путь ручной настройки гибридной конфигурации. Для администраторов, не живших в эпоху, предшествующую появлению SP2, вся сложность тех настроек, которые незаметно выполняет мастер, остается неизвестной. В конечном итоге это может обернуться сложностями для организаций в том случае, если перестанет работать федерация или связь между организациями (например, станет недоступным просмотр информации о занятости (free/busy)). Как администраторы будут искать, в чем проблема, если они не понимают, какое множество изменений вносится в конфигурацию, когда они просто щелкают «Далее»?

.

Архитектурные изменения

Первое, на что хотелось бы обратить внимание, это использование пространства имен DNS для маршрутизации почты и федерации. До выхода SP2 для организации взаимодействия между локальным сервером и Office365 было необходимо использовать два дополнительных пространства имен:

• exchangedelegation.domain.com
• service.domain.com

Пространство имен exchangedelegation использовалось для создания федерации между локальной организацией Exchange и Office 365. Термин «федерация» широко применяется и может сбивать администраторов с толку. В данном контексте мы говорим о федерации Exchange, которая используется для того, чтобы облегчить обмен информацией между Exchange и O365. Этот тип федерации использует шлюз Microsoft Federation Gateway и федерацию доверительных отношений, для того чтобы обмениваться такой информацией, как данные о занятости (free/busy) и советы по использованию MailTips. Пространство имен service служило дополнительным доменом доступа, необходимым для маршрутизации почты между локальной средой и Office 365.

Когда эта технология только появилась, у администраторов Exchange обычно возникал простой вопрос, зачем нужны два дополнительных пространства имен, если Office 365 использует только одно пространство имен domain.onmicrosoft.com для каждого домена. Ответа на этот вопрос не было. Специалисты Microsoft создали метод, который хоть и работал, но, как оказалось, был малоэффективным и ненадежным. Microsoft устранила этот недостаток в SP2 — больше не требовалось задействовать эти два дополнительных пространства имен. Вместо этого в SP2 используется пространство имен onmicrosoft.com, которое назначается Office 365 и применяется для маршрутизации почты. Кроме того, федерация Exchange устанавливается на уровне корневого домена domain.com. Оба упомянутых выше дополнительных пространства имен можно забыть. Хотя это объединение доменов и не является частью HCW, оно не играет роли, пока мастер не будет запущен.

Теперь, когда мы познакомились с улучшениями, которые были сделаны в DNS, перейдем непосредственно к HCW и подробно рассмотрим каждый шаг.

Запуск мастера

Перед запуском мастера необходимо добавить пространство имен Office 365 в консоли Exchange Management Console (EMC) локального сервера. HCW выполняет несколько команд Windows Powershell, требующих установленного модуля Powershell, который появляется, когда в EMC добавляется пространство имен Office 365. После этого мастер становится доступным в разделе управления организацией Organization Management, на закладке On-Premises в EMC.

Следующий шаг – создание объекта HCW, для этого нужно выбрать пункт «Новая гибридная конфигурация New Hybrid Сonfiguration» на панели действий Actions, как показано на экране 1. Этот первый шаг может показаться простым созданием объекта, без каких-либо настроек, однако на самом деле здесь выполняется несколько команд Powershell, которые создают новый самоподписанный сертификат и устанавливают федерацию доверительных отношений между локальной средой и шлюзом Microsoft Federation Gateway. Последнее, что происходит на данном шаге, это подготовка среды для дальнейшего запуска основной части HCW. С точки зрения Powershell выполняются следующие команды:

New-ExchangeCertificate -DomainName 'Federation'
-FriendlyName 'Exchange Delegation Federation' -KeySize
'2048' -Services 'Federation' -SubjectKeyIdentifier
'' -PrivateKeyExportable $true
New-FederationTrust -Name 'Microsoft Federation
Gateway' -Thumbprint '' -SuppressDnsWarning
New-HybridConfiguration

Экран 1. Добавление новой гибридной конфигурации

После успешного выполнения этих команд в разделе управления организацией Organization Management оснастки EMC появляется объект гибридной конфигурации Hybrid Configuration.

По мере выполнения мастер запрашивает у администратора определенную информацию, которая затем используется командами, выполняющими настройки в фоновом режиме. Так, на первой странице мастера необходимо указать учетные записи Exchange и Office 365. Эти учетные записи должны обладать соответствующими административными правами в каждой среде. Учетная запись локальной среды должна быть членом группы администраторов организации Organizational Admins, а учетная запись Office 365 должна быть членом группы Global Admins (экран 2).

Экран 2. Запрос учетных данных

На следующей странице список принимаемых доменов локальной среды сверяется со списком доменов в Office 365. Если имена доменов совпадают, то домен можно добавить, как пространство имен, участвующее в конфигурации. Организации с более чем одним принимаемым доменом могут добавить в гибридную конфигурацию все домены, которые посчитают нужным (экран 3). Необходимо обратить внимание, что домен должен быть подтвержден в Office 365, прежде чем он появится в списке.

Экран 3. Выбор доменов, добавляемых в конфигурацию

На следующей странице отображается текст, который следует использовать для подтверждения владения доменом (экран 4). Этот текст необходимо скопировать в буфер обмена и создать во внешнем DNS запись типа TXT. Убедитесь, что флажок, подтверждающий создание записи во внешнем DNS, проставлен. Microsoft использует эту текстовую запись для подтверждения, что пространство имен принадлежит именно вам. Только уполномоченные администраторы имеют право изменять записи во внешнем DNS, поэтому добавление такой записи подтверждает Microsoft, что данное пространство имен принадлежит вам.

Экран 4. Подтверждение права на домен

На странице управления серверами гибридной конфигурации Manage Hybrid Configuration Servers (экран 5), приводится список серверов клиентского доступа Client Access и транспортные серверы Hub Transport, которые будут использоваться для перемещения ящиков, обмена информацией и передачи почтовых сообщений. Выбор серверов может различаться в зависимости от существующей локальной среды. Если в организации уже развернут Exchange 2010, нужно выбрать серверы клиентского доступа Client Access и транспортные серверы Hub Transport, находящиеся в основном сайте и имеющие наибольшее количество доступных ресурсов. Серверы должны иметь соответствующее количество оперативной памяти, дискового пространства и обладать достаточной производительностью процессоров. По моему опыту, двухъядерного процессора с тактовой частотой 3 ГГц и оперативной памятью 8 Гбайт обычно более чем достаточно. Также в зависимости от времени, в течение которого вы планируете находиться в режиме сосуществования, вам может потребоваться несколько серверов клиентского доступа и транспортных серверов, объединенных в массив, для обеспечения отказоустойчивости. Это гарантирует непрерывность бизнеса, если один из серверов откажет.

Экран 5. Выбор серверов, участвующих в гибридной конфигурации

Серверы, участвующие в гибридной конфигурации, должны находиться в том же сайте Active Directory (AD), что и основная часть организации Exchange и не могут содержаться в демилитаризованной зоне (DMZ). Кроме того, если в среде существуют серверы Exchange 2003, то на один из серверов, входящих в гибридную конфигурацию, необходимо будет добавить роль сервера почтовых ящиков Mailbox. На этом сервере будет храниться реплика информации о доступности (free/busy), и он позволит обмениваться информацией о доступности пользователям Exchange 2003 и Office 365. Exchange 2003 использует устаревшую архитектуру общих папок для предоставления пользователям информации о занятости. Появившаяся в Exchange 2010 (и Exchange 2007) служба Availability service изменила метод обработки запросов о доступности и предоставила более надежный способ обмена запросами. Для того чтобы обмен информацией о доступности работал в гибридной среде, после установки роли Mailbox необходимо на этом сервере создать базу данных общих папок и переместить папку, содержащую информацию о доступности, на сервер Exchange 2010. Сервер из гибридной конфигурации будет служить посредником между Exchange 2003 и Office 365.

На странице Mail Flow Settings (экран 6) требуется указать IP-адрес из внешней сети и полное доменное имя (FQDN) из внешней сети локального сервера, входящего в гибридную конфигурацию. Предполагается, что FQDN соответствует IP-адресу, указанному на этой странице. Далее будет показано, как эти данные используются для настройки входящих и исходящих коннекторов Microsoft Forefront Online Protection for Exchange (FOPE).

Экран 6. Настройка параметров потока почты

На странице Mail Flow Security (экран 7) отображается список всех установленных сертификатов на серверах с ролью Hub Transport. Здесь можно выбрать, какой сервер будет использован в гибридной конфигурации. Сертификат на выбранном сервере должен быть выпущен публичным центром сертификации, таким как Verisign или Godaddy. Этот сертификат будет использоваться для проверки подлинности Transport Layer Security (TLS) между FOPE и локальным сервером. На этой странице задаются и параметры пересылки почты:

-маршрутизировать отправленную пользователями Office 365 в Интернет почту через локальный сервер (централизованная пересылка почты);

-маршрутизировать отправленную пользователями Office 365 в Интернет почту, используя DNS.

Экран 7. Настройки безопасности пересылки почты

По умолчанию выбран вариант «использовать DNS», а не централизованная пересылка почты; не забудьте изменить настройки согласно выбранной стратегии. Вариант «централизованная пересылка почты» позволяет администраторам без труда отслеживать сообщения, потому что все сообщения проходят через сервер, входящий в гибридную конфигурацию.

Один важный и часто упускаемый вопрос при выборе варианта маршрутизации почты – это запись Sender ID Framework (SPF). Sender ID Framework — расширение для протокола отправки электронной почты, которое помогает защитить почтовые серверы от спуфинга (spoofing) и фишинга (phishing) путем проверки имени домена отправителя. При использовании этой технологии происхождение почтового сообщения удостоверяется проверкой, что IP-адрес отправителя действительно принадлежит владельцу домена. Если ваша организация использует SPF записи, необходимо помнить о нескольких деталях. Первое — если выбран централизованный вариант маршрутизации почты, то вся почта выглядит так, как будто отправлена локальным сервером, необходимости вносить изменения в записи SPF нет. Однако если пользователи Office 365 будут отправлять сообщения напрямую в Интернет, то необходимо добавить записи SPF, указывающие на серверы Office 365. Чтобы помочь в создании записи, специалисты Microsoft разработали мастер создания записи SPF или Sender ID Framework SPF Record. Вот как может выглядеть запись SPF, если выбран вариант маршрутизации почты как через локальные серверы, так и через Office 365. Предполагается, что DNS-имя почтового сервера mail.domain.com:

v=spf1 a mx:mail.domain.com include:outlook.com ~all

На последней странице (экран 8) отображается сводная информация о выбранных настройках, собранная мастером. Щелкните Manage, чтобы запустить выполнение, и подождите, пока случится чудо!

Экран 8. Суммарная информация

Как это работает

Как мы видим, мастер заметно упрощает процесс создания гибридной конфигурации. Он требует минимального взаимодействия со стороны администратора, конвертируя предоставленные данные в набор команд Powershell, которые настраивают конфигурацию и не требуют от вас никаких усилий. Можно понять, почему администраторы принимают мастер как нечто само собой разумеющееся. Но что на самом деле происходит при нажатии на кнопку Manage? Давайте посмотрим. В данной статье я использовал собственное тестовое пространство имен office365support.com. Конкретные настройки могут отличаться, в зависимости от существующего домена и DNS записей. Те, кто работал с мастером до конца, могут следить за объяснением, открыв файл журнала в папке \%ExchangeInstallPath%\Logging\Update-HybridConfiguration.

Прежде всего, мастер устанавливает удаленную сессию Powershell, авторизовавшись в локальной и «облачной» среде. После того, как сессии установлены, набор команд Get- собирает информацию с локального сервера и Office 365. Обратите внимание, что большая часть этих команд выполняется дважды, один раз для локальной среды и один раз для Office 365. Команды опрашивают все серверы, выбранные в ходе работы мастера, собирая всю необходимую информацию для создания гибридной конфигурации.

Следующий набор команд пытается настроить поддержку устаревших версий Exchange, проверяя, хранится ли на каком-либо из северов реплика общей папки, содержащая информацию о доступности. В разделе файла журнала, относящемся к данному шагу, можно увидеть подобную ошибку: ERROR:System.Management.Automation.RemoteException (версия сервера 'Server2' неверна или требуемая для выполнения данной операции роль не уставлена). Беспокоиться об этой ошибке не стоит, просто мастер пытается определить сервер, подходящий для хранения реплики общей папки, содержащей информацию о доступности.

В средах, в которых установлен Exchange 2003, мастер поочередно проверяет каждый сервер, чтобы узнать, хранит ли он реплику папки с информацией о доступности. Этот шаг важен из-за разницы в том, как запросы информации о доступности обрабатываются в Exchange 2003 и Exchange 2010. Реплика папки с информацией о доступности должна храниться на сервере Exchange 2010, который является посредником между почтовыми ящиками, расположенными на сервере Exchange 2003 и «облачными» почтовыми ящиками. Без папки с информацией о доступности пользователи Exchange 2003 не смогут получить информацию о занятости «облачных» пользователей и наоборот.

После того, как мастер собирает информацию о политике формирования почтовых адресов, он обновляет эту политику и добавляет адреса, необходимые для корректной маршрутизации почты – а именно, добавляя @domain.mail.onmicrosoft.com как дополнительный домен для всех пользователей. Этот шаг чрезвычайно важен для маршрутизации почты. В процессе миграции, после того, как ящик пользователя перемещен в «облако», @domain.mail.onmicrosoft.com устанавливается как адрес маршрутизации. Начиная с этого момента при каждой попытке отправить сообщения пользователю локального сервера Exchange будет задействовать этот адрес для пересылки сообщения «облачному» пользователю, через коннектор с заданным диапазоном, который создается на следующем шаге.

Далее мастер проверяет, удовлетворяет ли локальная среда и среда Office 365 необходимым условиям для создания связей организации. При просмотре журнала можно видеть большое количество строк, отвечающих за данный шаг. На этом очень важном шаге создаются объекты взаимосвязи с обеих сторон федеративных отношений доверия, позволяющие работать этим важным функциям:

— запросы информации о занятости;

— советы по использованию почты mailtips;

— доступ к архивам;

— перенаправление Outlook Web App (OWA);

— отчеты о доставке;

— автообнаружение URL-адресов.

Заключительная фаза процесса включает настройку коннекторов отправки и получения в Exchange. Так, на этом шаге настраиваются параметры входящего и исходящего сервера для сервиса FOPE. Перед настройкой соединителей HCW определяет набор IP адресов центра данных и сертификаты, используемые в Office 365:

Get-HybridMailflowDatacenterIPs
Get-ExchangeCertificate -Thumbprint
'EC0E8A739282093930AF8930E93076428CA129' -Server 'Server1'

На следующем шаге (листинг 1) собирается информация о существующих и создаются новые соединители, необходимые для передачи сообщений в Office 365 и обратно. Как можно видеть на этом относительно простом примере, мастер выполняет 53 команды для настройки гибридной конфигурации, всю необходимую информацию для которых вы, как администратор, предоставили менее чем за 10 шагов. Хотя мастер — это значительный шаг вперед, он потенциально опасен для неопытных администраторов, которые не понимают, какие изменения производятся или какова их цель.

Наиболее известные проблемы и рекомендации по их решению

В большинстве случаев HCW выполняется без каких-либо затруднений. Хотя я сталкивался с проблемой, когда команда Get-FederationInformation не может быть выполнена. В качестве обходного решения можно открыть отдельную консоль Powershell и подключиться к своему домену Office 365, используя ту же учетную запись, входящую в группу Global Admin, что была указана в мастере. После того, как сессия установлена, мастер возобновляет свою работу.

Проблема также может быть связана с Windows Communication Foundation (WCF) или Windows Workflow Foundation (WF). Исправление компонентов WCF и WF путем выполнения в папке C:\Windows\Microsoft.NET\Framework\v3.0\ команды:

ServiceModelReg.exe –r

может исправить положение.

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

— ограничения, установленные на сетевом экране;

— ошибки WCF;

— некорректные настройки Exchange 2010;

— неправильно настроенные коннекторы отправки и получения;

— неверные сертификаты;

— неверные или некорректные записи DNS;

— отсутствие необходимых прав.

Ограничения на сетевом экране часто являются причинами многих проблем, возникающих в процессе отправки/получения почтовых сообщений. Как было сказано в самом начале статьи, подготовка и планирование — ключи к успеху. Нужно иметь четкий план, включающий список всех используемых в гибридной конфигурации IP-адресов. После того, как эти IP-адреса определены, на сетевом экране можно разрешить прохождение входящего и исходящего трафика к этим IP-адресам. Одна распространенная проблема, о которой мне часто приходится слышать, связана с тем, что этот список бывает трудно найти или его содержимое непонятно и сбивает с толку. Наиболее полный список необходимых IP-адресов можно найти в статье Microsoft «Office 365 URLs and IP address ranges» (http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh373144.aspx).

DNS записи также являются источником проблем для многих администраторов, которые пытаются развернуть гибридные конфигурации. Один из MVP, Лориан Странт, разработал отличный пакет для тестирования Office 365 (http://www.testmyoffice365.com/), который позволяет определить, все ли записи DNS настроены правильно. В этом пакете предполагается, что для отправки сообщений используется Office 365. Если вы используете этот пакет для тестирования собственных IP-адресов и планируете настроить отправку сообщений через локальную почтовую систему, то сообщения о DNS-записях для «облачной» службы автообнаружения можно игнорировать.

Другая часть распространенных проблем связанна с неверной настройкой существующей среды Exchange. Несколько утилит помогут обнаружить эти проблемы. Exchange Best Practices Analyzer (http://www.microsoft.com/en-us/download/details.aspx?id=22485) — самая подходящая из них для того, чтобы начать поиск. Эта утилита исследует важнейшие компоненты, проверяет, настроены ли они в соответствии с рекомендациями, и предоставляет ссылки с решениями для тех компонентов, которые не отвечают рекомендациям.

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

• Office 365 URLs and IP address ranges (http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh373144.aspx).
• Microsoft Remote Connectivity Analyzer (https://www.testexchangeconnectivity.com).
• Microsoft Office 365 Deployment Guide for Enterprises (http://community.office365.com/en-us/forums/183/p/1541/5095.aspx).
• Office 365 Community (http://community.office365.com/en-us/default.aspx).

Пожелание администраторам

Надеюсь, что эта статья прольет свет на то, как на самом деле работает HCW. Как уже отмечалось в начале статьи, меня радует, что Microsoft упростила процесс, но я надеюсь, что все администраторы пойдут чуть дальше графического интерфейса для более глубокого понимания того, что же на самом деле происходит.

Set-ReceiveConnector -Identity
'Server1\Inbound from Office 365' -Name
'Inbound from Office 365' -RequireTLS 'True'
-PermissionGroups 'AnonymousUsers' -Fqdn
'mail.montgomerycountymd.gov' -TLSDomainCapabilities
'outlook.com:AcceptOorgProtocol' -Bindings
'Microsoft.Exchange.Data.MultiValuedProperty`
1[Microsoft.Exchange.Data.IPBinding]'
-RemoteIPRanges 'System.Collections.Generic.List`
1[Microsoft.Exchange.Data.IPRange]' -AuthMechanism 'Tls'
Set-HybridMailflow -SecureMailEnabled 'True'
-CentralizedTransportEnabled 'True' -OnPremisesFQDN
'mail.o365support.com' -CertificateSubject
'mail.o365support.com' -InboundIPs
'Microsoft.Exchange.Data.IPRange[]' -OutboundDomains
'Microsoft.Exchange.Data.SmtpDomainWithSubdomains[]'