Доступ к сведениям о доступности между организациями с помощью федеративного доверия и организационных отношений

Article
10/17/2011

Организациям часто необходимо обмениваться информацией о доступности (Free/Busy) с другими организациями. В зависимости от версии вашего сервера Exchange существуют различные способы сделать это. Давайте рассмотрим три распространенных сценария и пройдем все шаги по настройке, которые необходимы для обмена информацией о доступности между двумя локальными организациями Exchange.

Сценарии:

В этой сводной таблице кратко изложены требования, чтобы облегчить понимание процесса поиска сведений о доступности между двумя организациями:

	Версия Exchange в организации-источнике
Требуемые компоненты	Exchange 2003/2010	Exchange 2003/2007/2010	Exchange 2007/2010	Exchange 2010
Федеративное доверие / организационные отношения	X	X	X	X
Адресное пространство доступности	-	X	X	-
База данныз общих папок на 2010 SP1 с репликами некоторых/всех папок Free/Busy*	X	X	--

*смотрите “Вариант A” и Вариант B”, которые обсуждаются ниже в этой статье

Сценарий 1: Обе организации используют Exchange 2010 SP1

Вот первый сценарий. Пользователи в обеих организациях на Exchange 2010, обе организации могут использовать федеративное делегирование (Federated Delegation) и не требуют никаких дополнительных шагов.

Обе организации должны установить федеративное доверие (Federation Trust). Шаги по созданию федеративного доверия описаны в статье Создание доверия федерации (Create a Federation Trust). Федеративное доверие должно быть установлено и работать до того, как будут установлены организационные отношения (organization relationship).
Зарегистрируйте в DNS записи TXT для доменного пространства имен, образующего федерацию, и всех других доменов, которые вы хотите добавить в федеративное доверие. Пространство имен учетной записи (это идентификатор организации или OrgID) идентифицирует вашу организацию в Microsoft Federation Gateway. Вы должны использовать домен другой, чем ваш основной (primary) SMTP домен (используемый для получения входящей почты) для этого the account namespace, как описано в Настройка федеративного делегирования (Configure Federated Delegation). Рекомендуется использовать exchangedelegation.domain.com в качестве пространства имен учетной записи.
Убедитесь, что служба обнаружения (autodiscover web service) настроена и работает для вашего пространства имен. Хотя возможно вручную настроить организационные отношения, мы рекомендуем вам использовать autodiscover.
Шаги по настройке организационных отношений описаны в Создание организационного отношения (Create an Organization Relationship).

Замечание: Синхронизация каталогов (directory synchronization) для обмена информацией о доступности между организациями в Exchange 2010 SP1 не требуется кроме случая, когда у вас есть пользователи, использующие Outlook 2007/2003. Однако, если вы выполните настройку синхронизации каталогов, это не окажет влияния на возможность выполнять поиск информации о доступности.

Сценарий 2: Одна или обе организации используют и Exchange 2010 SP1, и Exchange 2007

Шаги 1-4 в этом сценарии те же самые как в Сценарии 1. Однако в случае комбинации с Exchange 2007 синхронизация каталогов является необходимой между двумя организациями. Вы должны также создать адресное пространство доступности для удаленной организации. Это позволит пользователям Exchange 2007 в обеих организациях пользоваться поддержкой Exchange 2010 для федерации.

В случае Exchange 2007 для того, чтобы получать сведения о доступности между организациями, должна быть выполнена синхронизация каталогов для всех пользователей с доступом к информации Free/Busy. Это может быть выполнено вручную (создайте контакты Exchange или Mail-enabled пользователей по одному) или с помощью автоматизированного процесса (MIIS, ILM, FIM или стороннего инструмента синхронизации каталогов).

В этом случае синхронизация необходима потому , что Exchange 2007 требует (и ожидает) локальный объект, когда выполняется запрос доступности. Если локальный объект не существует, то запрос доступности закончится неудачей.

Создайте новое адресное пространство доступности для удаленной организации, которая направляет запросы доступности от пользователей на 2007-м к серверу 2010 SP1. Синтаксис для создания адресного пространства доступности показан ниже.

Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl https://Exchange2010SP1CAS.InternalDomain.com/ews/exchange.asmx -ForestName Fabrikam.com -UseServiceAccount $True

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

Рисунок 1: Пользователь Exchange 2007 запрашивает информацию о доступности пользователя в удаленной организации

Шаг 1. Пользователь Exchange 2007 запрашивает информацию о доступности пользователя в Org B. Exchange 2007 проксирует запрос к серверу Exchange 2010 SP1.
Шаги 2 и 3. Exchange 2010 определяет, что запрос предназначен удаленной организации, и определяет наличие организационных отношений. Затем Exchange проверяет федеративное доверие.
Шаг 4. Затем Exchange 2010 отправляет запрос сервису доступности (availability service) в организацию Org B.
Шаг 5. Сервис доступности в Org B генерирует ответ и посылает обратно на сервер клиентского доступа Exchange 2010 SP1 в организацию Org A.
Шаг 6. Ответ о доступности передается в Exchange 2007, который затем передает его клиенту.

Сценарий 3: Одна или обе организации используют и Exchange 2003, и Exchange 2007 и Exchange 2010 SP1

Шаги 1-4 в этом сценарии те же самые, что и в Сценарии 1. Шаги 5-6 в этом сценарии те же самые, что и в Сценарии 2. Кроме того, т.к. вы имеете Exchange 2003 в топологии, вы должны выбрать один из двух вариантов описанных ниже Вариант A или Вариант B.

При выборе любого варианта необходимо выполнить дополнительные действия. Посмотрите раздел решения известных проблем в конце этой статьи, чтобы лучше понять эти действия. Оба варианта подразумевают, что вы выполнили шаги, кратко изложенные выше в Сценарии 1 и в Сценарии 2.

Вариант A:

Убедитесь, что существует сервер почтовых ящиков версии Exchange 2010 SP1, на котором размещена база общих папок.
Переместите ВСЕ реплики общих папок, содержащих информацию Free/Busy, на этот сервер Exchange 2010 SP1, и удалите ВСЕ реплики и с 2003 и с 2007. Это позволит серверу Exchange 2010 SP1 отвечать на все запросы о доступности из общих папок.

Как только приходит запрос о доступности к общим папкам, сервис Microsoft Exchange RPC Client Access Service на сервере почтовых ящиков (используемом для подключений к общим папкам) будет перехватывать запрос к общим папкам и маршрутизировать запрос в сервис доступности (availability service), который затем будет обрабатывать запрос, как описано в предыдущем сценарии.

Если удаленная организация, из которой вам нужно получить информацию о доступности, содержит пользователей Exchange 2003, вы должны вручную заполнить свойство targetSharingEPR в организационных отношениях Organization Relationship (смотрите Проблема #4 в конце этого документа). Это делается через Exchange Management Shell с помощью команды:

Set-organizationrelationship –identity “Org Relationship name” –TargetSharingEPR https://outlook.contoso.com/ews/exchange.asmx/wssecurity

Замечание: реальный URL будет отличаться от приведенного в примере. Вы можете определить URL, проверив свойство ExternalURL вашей виртуальном каталоге Web Services. Это можно сделать, выполнив команду Get-WebServicesVirtualDirectory –server 2010cas.contoso.com | fl name, *url*.

Рисунок 2: Exchange 2003 пользователь запрашивает информацию о доступности в удаленной организации (Вариант A)

Шаг 1. Пользователь Exchange 2003 запрашивает доступность пользователя в Org B. Т.к. почтовый ящик находится на сервере Exchange 2003, то запрашивающий клиент будет обращаться за информацией о доступности к общим папкам. Это делается просмотром атрибута LegacyExchangeDN объекта почтового контакта удаленного пользователя. Из атрибута LegacyExchangeDN клиент определяет административную группу, в которой создан этот объект, и тем самым узнает в какой общей папке искать информацию о доступности. Outlook первым делом выполняет запрос к общей папке по умолчанию для этого хранилища почтовых ящиков (которой обычно является хранилище общих папок Exchange 2003). Например, пусть LegacyExchangeDN пользователя Joe – это LegacyExchangeDN=/o=First Organization/ou=Exchange 2003 Admin Group/cn=Recipients/cn=Joe User. Первая часть LegacyExchangeDN атрибута /o=First Organization/ou=Exchange 2003 Admin Group используется для определения того, в какой общей папке искать информацию о доступности. Вторая часть LegacyExchangeDN атрибута cn=Joe User используется для поиска конкретной записи о доступности в этой общей папке.
Шаг 2. Эта база общих папок Exchange 2003 выдаст клиенту ссылку на базу данных общих папок Exchange 2010 SP1, в которой расположена единственная реплика общей папки с информацией о доступности.
Шаг 3. Outlook запрашивает общую папку Exchange 2010 SP1 об информации о доступности. Microsoft Exchange RPC Client Access Service, работающий на сервере почтовых ящиков, перехватывает запрос о доступности и маршрутизирует его в службу доступности.
Шаги 4 и 5. Exchange 2010 определяет, что это запрос для удаленной организации, и определяет существуют ли организационные отношения (organization relationship). Exchange затем проверяет федеративное доверие (federation trust).
Шаг 6. Затем Exchange 2010 отправляет запрос в службу доступности организации Org B.
Шаг 7. Служба доступности в Org B генерирует ответ и отправляет его назад серверу клиентского доступа Exchange 2010 SP1 в Org A.
Шаг 8. Microsoft Exchange RPC Client Access Service транслирует ответ о доступности в форму ответа free/busy общей папки, и возвращает информацию клиенту Outlook. Кроме того, этот ответ размещается в общей папке Free/Busy и кэшируется в течение 15 минут. Если выполняются повторные запросы о доступности удаленного пользователя в пределах этих 15 минут, то ответ возвращается из этого кэша.

Вариант B

Убедитесь, что существует сервер почтовых ящиков Exchange 2010 SP1, на котором расположена база общих папок.
Если еще нет системной папки с информацией о доступности под именем External (FYDIBOHF25SPDLT), то создайте ее, и убедитесь, что единственная реплика этой папки находится на сервере Exchange 2010 SP1.

Замечание: э та папка (External free busy folder) создается только при установке нового Exchange 2010 SP1, когда выбрана опция установки общих папок в программе установки. Эта опция присутствует только в том случае, если ставится первый сервер в организации. Если база общих папок не создана во время инсталляции, то вам нужно будет создать эту папку вручную. Процесс создания этой "внешней папки" прост.

Подключитесь к локальному серверу Exchange 2010 SP1 с общими папками (операция должна выполняться именно на сервере общих папок)
Запустите Windows PowerShell
Наберите " Add-PsSnapin Microsoft.Exchange.Management.Powershell.Setup"
Затем наберите " Install-FreeBusyFolder"

Это создаст новую папку Schedule Plus free busy с именем "External (FYDIBOHF25SPDLT)".

Измените LegacyExchangeDN на всех почтовых объектах, которые относятся к удаленной организации, и измените значение OU на External (FYDIBOHF25SPDLT). Как только приходит запрос информации о доступности, сервис Microsoft Exchange RPC Client Access Service на сервере почтовых ящиков (используемом для обработки подключений к общим папкам) будет перехватывать этот запрос и маршрутизировать его в службу доступности, которая в свою очередь обрабатывает запрос, как описано в предыдущем сценарии.
Если удаленная организация, к которой вам необходимо найти информацию о доступности, содержит пользователей на Exchange 2003, вы должны вручную прописать в свойство TargetSharingEPR организационных отношений (смотрите Проблему #4 в конце этого документа). Следующая команда прописывает свойство TargetSharingEPRproperty:

Set-OrganizationRelationship –Identity “Org Relationship name” –TargetSharingEPR https://outlook.contoso.com/ews/exchange.asmx/wssecurity

Замечание: реальный URL, который вы будете использовать, будет отличаться от использованного в примере. Вы можете определить этот URL, проверив свойство ExternalURL виртуального каталога Web Services. Вы можете сделать это, выполнив команду Get-WebServicesVirtualDirectory –Server 2010cas.contoso.com | fl Name, *url*.

Рисунок 3: Exchange 2003 пользователь запрашивает информацию о доступности в удаленной организации (Вариант B)

Шаг 1. Пользователь Exchange 2003 запрашивает информацию о доступности пользователя в организации Org B. Т.к. запрашивающий клиент находится на сервере Exchange 2003, он будет выполнять запрос информации о доступности посредством папок общего пользования. Это делается просмотром атрибута LegacyExchangeDNattribute объекта почтового контакта удаленного пользователя. Клиент определяет административную группу, в которой создан этот объект, и тем самым узнает в какой общей папке искать информацию о доступности. Outlook первым делом выполняет запрос к общей папке по умолчанию для этого хранилища почтовых ящиков (которой обычно является хранилище общих папок Exchange 2003). Например, пусть LegacyExchangeDN пользователя Joe это LegacyExchangeDN=/o=First Organization/ou=Exchange 2003 Admin Group/cn=Recipients/cn=Joe User. Первая часть LegacyExchangeDN атрибута /o=First Organization/ou=Exchange 2003 Admin Group используется для определения того, в какой общей папке искать информацию о доступности. Вторая часть LegacyExchangeDN атрибута cn=Joe User используется для поиска конкретной записи о доступности в этой общей папке.
Шаг 2. Т.к. mail-enabled пользователь имеет модифицированный атрибут legacyExchangeDN, и единственная реплика папки External free/busy находится на Exchange 2010, то эта база общих папок Exchange 2003 выдаст клиенту ссылку на базу данных общих папок Exchange 2010 SP1, в которой расположена единственная реплика общей папки с информацией о доступности.
Шаг 3. Outlook запрашивает общую папку Exchange 2010 SP1 об информации о доступности. Microsoft Exchange RPC Client Access Service, работающий на сервере почтовых ящиков, перехватывает запрос о доступности и маршрутизирует его службе доступности.
Шаги 4 и 5. Exchange 2010 определяет, что это запрос для удаленной организации, и определяет существуют ли организационные отношения (Organization Relationship). Затем Exchange проверяет федеративное доверие (Federation Trust).
Шаг 6. Затем Exchange 2010 отправляет запрос службе доступности организации Org B.
Шаг 7. Служба доступности в Org B генерирует ответ и отправляет его назад серверу клиентского доступа Exchange 2010 SP1 в Org A.
Шаг 8. Microsoft Exchange RPC Client Access Service транслирует ответ о доступности в форму ответа общих папок free/busy, и возвращает информацию клиенту Outlook. Кроме того, этот ответ размещается в папке общего доступа Free/Busy и кэшируется в течение 15 минут. Если выполняются повторные запросы о доступности удаленного пользователя в пределах этих 15 минут, то ответ возвращается из этого кэша.

Известные проблемы

Проблема #1 - OWA 2003

Когда пользователи Exchange 2003 используют OWA для назначения встречи, они будут видеть закладку “Доступность” (“Availability”) в форме запроса, которая будет запрашивать информацию о доступности из общих папок с помощью DAV. Запрос о доступности DAV выглядит так:

https://ExchangeServer/public/?Cmd=freebusy&
start=2009-10-28T00:00:00-07:00&
end=2009-10-29T00:00:00-07:00&
interval=30&
mbxguid=ea14502f-44cc-41ae-9f1d-df519a16ad20&
u=SMTP:mary@Contoso&
u=SMTP:joe@Contoso.com

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

DAV может извлекать информацию о доступности только из локальной базы почтовых ящиков. Когда OWA загружает страницы и скрипты в браузер, он передает URL на общую папку соответствующую почтовому ящику пользователя. Если не существует локальной реплики для этой папки, соответствующей первому пользователю, заданному параметром u= в URL, DAV будет выполнять HTTP redirect (status 302) для всего запроса на сервер, который имеет эту реплику. Обратите внимание, что эта реализация предполагает, что информация о доступности для других пользователей указанных в этом же запросе, может быть найдена на том же самом сервере. Подразумевается, что папки free/busy для различных административных групп должны иметь реплики во всех базах данных общих папок. В нашем случае некоторые или все папки free/busy будут иметь только реплики на Exchange 2010, однако Exchange 2010 не поддерживает протокол DAV, поэтому перенаправления, которые выполняет OWA на 2010, будут просто завершаться ошибкой.

В Варианте A это будет вызывать ошибку для ВСЕХ запросов OWA информации о доступности и внутренних, и внешних), т.к. сервер Exchange 2003 не будет иметь реплик общих папок с информацией о доступности.

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

Проблема #2 – Внутренние запросы Free / Busy для Exchange 2003

Вариант A для Exchange 2003 требует, чтобы единственная реплика папок с информацией о доступности располагалась на серверах Exchange 2010 SP1. В ситуациях, когда базы общих папок Exchange 2003 расположены в нескольких физических сайтах, и когда базы общих папок Exchange 2010 Sp1 не расположены в тех же физических сайтах, это может привести к серьезным задержкам и, возможно, проблемам производительности, т.к. внутренние запросы информации о доступности должны проходить через WAN-каналы.

Проблема #3 – Запросы между организациями относительно пользователей на Exchange 2007 завершаются ошибкой

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

Для решения этой проблемы вы можете изменить параметр maximumQueryIntervalDays в файле EWS web.config (расположенном в папке \Program Files\Microsoft\Exchange Server\ClientAccess\ExchWeb\ews\ ) на серверах Exchange 2007. Добавьте этот параметр в секции AppSettings.

Вот пример настройки сервиса доступности Exchange 2007, который будет предоставлять информацию о доступности за 62 дня.

Замечание: параметр maximumQueryIntervalDays не присутствует по умолчанию. Если параметр отсутствует, то Exchange использует значение по умолчанию, равное 42 дням.

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

Проблема #4 - Запросы между организациями относительно пользователей на Exchange 2003 завершаются ошибкой

По умолчанию сервер клиентского доступа Exchange 2010, выполняющий запрос информации о доступности между организациями, будет запрашивать сервис обнаружения относительно того пользователя, для которого вы пытаетесь посмотреть информацию о доступности. Если этот пользователь на Exchange 2003, то сервис обнаружения вернет ошибку, т.к. пользователи на Exchange 2003 не обслуживаются сервисом обнаружения. Эта проблема должна быть решена в Exchange 2010 SP1 Update Rollup 4. Обходной путь: вручную установить targetSharingEPR в организационных отношениях (Organization Relationship) для удаленной организации с Exchange 2003.

Например:

Set-OrganizationRelationship –identity -targetSharingEPR https://mail.contoso.com/ews/exchange.asmx/WSSecurity

Дополнение: эта проблема уже решена в Exchange 2010 SP1 Update Rollup 4. Смотрите KB 2506820. The free/busy information does not display of a user whose mailbox is located on an Exchange Server 2003 server.

Дополнительная проблема с запросами относительно пользователей Exchange 2003 заключается в том, что удаленная организация возвращает ответ с информацией о доступности в формате строки MergedOnly. Exchange 2010 не может конвертировать эту строку, чтобы запомнить результат в общих папках, и таким образом клиенту Outlook не возвращается никакой информации. Для этой проблемы доступно исправление. Смотрите KB 2567863 Free/Busy information may not be returned when a Cross-Org query is performed from a legacy Exchange user.

Проблема #5 – Федеративные отношения с организацией, которая имеет как локальных, так и облачных пользователей

Если вы имеете федеративные отношения с другой организацией, которая имеет подписку на облачный сервис вроде Office 365 или BPOS, запросы о доступности относительно удаленных пользователей, которые перемещены в облако, будут завершаться ошибкой. Причина в том, что ваша организация имеет организационные отношения с удаленной необлачной организацией, которая в свою очередь имеет совершенно отдельные организационные отношения с O365/BPOS. Когда выполняется запрос информации о доступности из одной организации в другую через организационные отношения, этот запрос выполняется относительно необлачной организации (локального типа), где существует почтовый контакт или пользователь (mail-enabled user или contact). Не существует функциональности для проксирования запроса информации о доступности через организационные отношения из организации локального типа в облачную организацию, так что такой запрос завершится ошибкой.

Бен Винценц

Перевод: Илья Сазонов, MVP