При переносе электронной почты с предприятия в облачные среды, такие как Exchange Online, приходится принимать кое-какие решения.
Хенрик Уолтер
Между лесами
Вопрос Мы - крупная корпорация, использующая Exchange 2010. У нас имеется бизнес-партнер, у которого установлен Exchange 2007. Мы хотим использовать календари и информацию "свободен/занят" совместно с этим партнером. Поэтому мы настроили предоставление информации о доступности для других лесов по инструкциям для Exchange 2010, приведенным в TechNet Library.
Однако даже после того, как мы убедились, что можем разрешать и выполнять запросы автообнаружения, информацию "свободен/занят" по-прежнему не удается получить. Не подскажете, как это исправить?
Ответ После выпуска Exchange 2007 RTM (released to manufacturing) обнаружился один "баг": при получении информации "свободен/занят" для пользователей из других лесов механизм автообнаружения использовал внутренний (EWS) (см. рис. 1). По умолчанию внутренний URL виртуального каталога EWS имеет вид CAS_server.fqdn.com (т. е. ссылается на полностью определенное доменное имя CAS-сервера). Следовательно, он должен быть разрешимым. Кроме того, это значит, что полностью определенное доменное имя (Fully Qualified Domain Name, FQDN) также должно быть разрешимым.
Рис. 1. При автообнаружении по умолчанию используется внутренний URL виртуального каталога Exchange Web Services
Хотя эта ситуация далека от идеала, и для Exchange 2007, и для Exchange 2010 имеются исправления, которые меняют такое поведение. Для Exchange 2007 примените Update Rollup 6 for Exchange Server 2007 SP3. А для Exchange 2010 примените Update Rollup 1 for Exchange 2010 SP2. После установки этих исправлений вы сможете отправлять запросы "свободен/занят" через Интернет. Это будет отлично работать и в топологиях Exchange с прокси-сайтом. После установки исправлений Client Access Server (CAS) на стороне отправителя будет смотреть внешний URL виртуального каталога EWS и не будет по умолчанию использовать внутренний URL для EWS.
Имейте в виду, что после применения этих исправлений внешний URL для EWS должен быть разрешимым между лесами Exchange, совместно использующими информацию "свободен/занят". Вы не сможете настроить сервис проверки доступности таким образом, чтобы при запросах к нему, передаваемых между лесами, использовался внутренний URL для EWS.
Аутентификация в Exchange Online
Вопрос В настоящее время мы занимается планированием переноса своей инфраструктуры обмена сообщениями с Exchange 2007, работающего на предприятии, на Exchange Online - компонент Office 365. Мы планируем использовать гибридное развертывание Exchange и федерацию идентификаций.
Но мы немного не уверены в одной вещи - поддержке аутентификации для нескольких суффиксов имен участников-пользователей (user principal name, UPN). Мы слышали, что для того чтобы одни пользователи могли проходить аутентификацию в Active Directory Federation Services (ADFS) с именами типа alias@domain1.com, а другие - с именами типа alias@domain2.com, потребуется по ферме федерации ADFS на каждый UPN-суффикс, который мы будем использовать при аутентификации. Не могли бы вы пролить свет на этот вопрос?
Ответ Ситуация следующая. До появления Update Rollup 1 (заметьте: доступно обновлениеUpdate Rollup 2 и следует его установить) для ADFS 2.0 RTW (release to Web), предприятия, реализующие федерацию идентификаций для Office 365 на основе ADFS, были обязаны развертывать по ферме федерации ADFS для каждого UPN-суффикса, для которого требовалась поддержка аутентификации в сервисе Office 365. Это означало, что предприятиям требовалось развертывать два прокси-сервера ADFS и два сервера ADFS на каждый поддерживаемый UPN-суффикс. То есть, для поддержки двух UPN-суффиксов потребовалось бы восемь серверов. Можно было бы обойтись одним прокси-сервером ADFS и одним сервером ADFS на UPN-суффикс, но, на самом деле, это нежелательно, так как тогда в системе имелись бы компоненты, отказ которых приводил бы к отказу всей системы (single point of failure).
С выходом Update Rollup 1 и более поздних обновлений в ADFS 2.0 RTW появилась поддержка нескольких UPN-суффиксов каждой фермой федерации ADFS. В одной из недавних публикаций в моем блоге, "Office 365 - ADFS & Support for Multiple UPNs" рассказывается, как обеспечить поддержку еще одного UPN-суффикса существующей конфигурацией ADFS (см. рис. 2).
Рис. 2. Для поддержки аутентификации в ADFS нужно подготовить соответствующую инфраструктуру
Экономия на серверах
Вопрос Мы переходим с инфраструктуры обмена сообщениями Exchange 2003, развернутой на предприятии, на Exchange Online, входящий в Office 365. Мы создаем гибридную конфигурацию, чтобы получить эффективную смешанную структуру. Кроме того, мы хотим создать федерацию идентификаций, но наш бюджет не позволяет приобрести четыре сервера в дополнение к работающим на предприятии.
В настоящее время у нас четыре сервера Exchange 2003. Чтобы развернуть гибридную среду Exchange, мы уже установили два сервера Exchange 2010. Кроме того, мы развертываем сервер для синхронизации каталогов. Не подскажете, как свести число требуемых серверов к минимуму и при этом обеспечить высокую доступность?
Ответ Имеется два варианта настройки федерации идентификаций. Как вы уже знаете, потребуется два сервера ADFS во внутренней сети и два прокси-сервера ADFS в сети периметра. Если у вас менее 1000 пользователей, установка компонентов ADFS на два существующих контроллера домена будет жизнеспособным решением (см. рис. 3). Что касается прокси-серверов ADFS, можно задействовать два существующих веб-сервера или прокси-сервера в сети периметра. Подробности см. в разделе "Estimation table: Determine the number of ADFS 2.0 servers to deploy in your organization" статьи "Plan for and deploy ADFS 2.0 for use with single sign-on", опубликованной на сайте сообщества Microsoft Office 365.
Рис. 3. Конкретные рекомендации по развертыванию Office 365.
Если у вас более 1000 пользователей, следует использовать выделенные серверы и для внутренних серверов ADFS и для прокси-серверов ADFS. Это могут быть виртуальные серверы. Если у вас более 1000 пользователей и вы не желаете развертывать выделенные серверы ADFS на стороне предприятия, имеется другой вариант. Можно создать виртуальные серверы ADFS вWindows Azure и создать в среде предприятия виртуальную частную сеть. Тогда вы сократите число серверов, не пожертвовав высокой доступностью (HA). В случае ADFS такие жертвы недопустимы. Отказ ADFS приведет к тому, что пользователи потеряют доступ к Office 365.
Кроме того, можно использовать Windows Azure просто как сайт для восстановления ADFS после сбоя. Разверните один сервер ADFS и один прокси-сервер ADFS на стороне предприятия, а остальные серверы - в Windows Azure. Кроме того, для них потребуется контроллер домена (DC), размещенный в Windows Azure. Так что у вас имеется пара вариантов решения проблемы, препятствующей развертыванию инфраструктуры.
Проблемы с Preview
Вопрос Мы добавили нового клиента (tenant) в Office 365 Preview (wave 15). Нам удалось синхронизировать пользовательские объекты для этого клиента с помощью инструмента DirSync. Однако при попытке добавить клиента с помощью операции "Add Exchange Forest" в Exchange 2010 SP2 Management Console, мы получили следующее сообщение об ошибке:
"The following error occurred when getting management role assignment information for 'server.pord.outlook.com/Microsoft Exchange Hosted Organizations/tenant_name.onmicrosoft.com/globaladmin':
Microsoft.Exchange.Data.Directory.Management.ExchangeroleAssignmentPresentation is not supported by MockEngine!"
Есть какие-нибудь соображения?
Ответ Чтобы добавить клиента Office 365 Preview (wave 15) в Exchange 2010 Management Console, необходимо установить обновление Exchange 2010 SP3. Поскольку этот сервисный пакет выйдет не ранее первой половины 2013, то, что вы пытаетесь сделать, пока что не поддерживается, если только вы не участвуете в Technology Adoption Program (программе технологической адаптации) для Office 365 Preview или Exchange.