Общие сведения по передаче данных через прокси-соединения и перенаправление

 

Применимо к: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Последнее изменение раздела: 2016-11-28

В организации Microsoft Exchange Server 2010 сервер клиентского доступа может выступать в роли прокси-сервера для других серверов клиентского доступа организации. Это бывает полезно, когда на различных сайтах Служба каталогов Active Directory в организации находится несколько серверов клиентского доступа и по меньшей мере один из них недоступен из Интернета.

Сервер клиентского доступа также может осуществлять перенаправление для URL-адресов Microsoft Office Outlook Web App и для устройств Exchange ActiveSync. Перенаправление полезно в случаях, когда пользователь подключается к серверу клиентского доступа, находящемуся за пределами локального сайта Служба каталогов Active Directory, а также когда почтовые ящики перемещаются между сайтами Служба каталогов Active Directory. Оно также полезно, когда пользователю необходимо использовать более эффективный URL-адрес. Например, пользователям нужно использовать URL-адрес, более близкий к сайту Служба каталогов Active Directory, на котором размещен почтовый ящик.

Время отклика сервера клиентского доступа зависит от протокола. Обычно, когда сервер клиентского доступа получает запрос для пользователя, чей почтовый ящик находится не на том сайте Служба каталогов Active Directory, к которому относится сам сервер, он выполняет следующее действие: В этом случае сервер проверяет наличие свойства ExternalURL в соответствующем виртуальном каталоге на сервере клиентского доступа, располагающемся на том же сайте Служба каталогов Active Directory, что и почтовый ящик. Если свойство ExternalURL существует, а тип клиента поддерживает перенаправление (например, Outlook Web App или Exchange ActiveSync), то сервер клиентского доступа выполняет перенаправление на этот клиент. Если свойство ExternalURL не задано или данный тип клиента не поддерживает перенаправление (например, POP3 или IMAP4), то сервер клиентского доступа попытается установить прокси-соединение с целевым сайтом Служба каталогов Active Directory.

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

Примечание.
Если в организации только один сайт Служба каталогов Active Directory, настройка сервера Exchange 2010 для использования прокси-соединений и перенаправления не требуется. Тем не менее, может потребоваться настройка балансировки нагрузки URL-адресов, описанная далее в этом разделе.

Примечание.

Серверы клиентского доступа, к которым отсутствует доступ из Интернета, не имеют отдельных SSL-сертификатов, которые позволяют передавать трафик через прокси-соединение с другого сервера клиентского доступа. По умолчанию они могут использовать самозаверяющий сертификат, который устанавливается вместе с сервером Exchange 2010. Тем не менее, этим сертификатам обычно не доверяют внутренние клиенты, такие как приложения Outlook Web App или Outlook, и их использование обычно приводит к выдаче предупреждений о сертификатах. Если имеются внутренние клиенты на тех же сайтах Служба каталогов Active Directory, что и серверы клиентского доступа с самозаверяющими сертификатами, то необходимо заменить такие сертификаты на сертификаты, выданные центром сертификации, которому доверяют клиенты.

Содержание

Общие сведения о передаче данных через прокси-соединения

Общие сведения о перенаправлении

Прокси-соединение с балансировкой нагрузки на сеть

Сводные данные по методам клиентского доступа

Производительность и масштабируемость использования прокси-соединений

Общие сведения о передаче данных через прокси-соединения

В Microsoft Exchange Server 2003 сервер переднего плана взаимодействует с фоновым сервером по протоколу HTTP. В версиях Exchange Server 2007 и Exchange 2010 сервер клиентского доступа взаимодействует с сервером почтовых ящиков Exchange по протоколу RPC. На каждом сайте Служба каталогов Active Directory с сервером почтовых ящиков Exchange 2010 необходимо развернуть сервер клиентского доступа Exchange 2010. Прокси-сервер используется, когда один сервер клиентского доступа отправляет трафик другому серверу клиентского доступа. Сервер клиентского доступа Exchange 2010 может передавать запросы через прокси-соединения в следующих ситуациях:

• Между серверами клиентского доступа Exchange Server 2010   Передача запросов через прокси-соединения между двумя серверами клиентского доступа Exchange 2010 позволяет организациям с несколькими сайтами Служба каталогов Active Directory назначать один сервер клиентского доступа в качестве сервера, доступного из Интернета, чтобы он передавал через прокси-соединения запросы серверам клиентского доступа на сайтах без Интернета. Доступный из Интернета сервер клиентского доступа передает запрос через прокси-соединение ближайшему к почтовому ящику пользователя серверу клиентского доступа.

• Между сервером клиентского доступа Exchange 2010 и серверами клиентского доступа Exchange 2007   Передача запросов через прокси-соединение между сервером клиентского доступа Exchange 2010 и сервером клиентского доступа Exchange 2007 на одном сайте Служба каталогов Active Directory или между сайтами Служба каталогов Active Directory позволяет системам Exchange 2010 и Exchange 2007 совместно работать в одной организации. Дополнительные сведения об обновлении и совместной работе см. в разделах Обновление с клиентского доступа Exchange 2003 и Обновление с клиентского доступа Exchange 2007.

Передача через прокси-соединение поддерживается для тех клиентов, которые используют приложение Outlook Web App, службу Exchange ActiveSync, панель управления Exchange (ECP), протоколы POP3, IMAP4 и веб-службы Exchange. Передача через прокси-соединение поддерживается между двумя серверами клиентского доступа, если целевой сервер использует версию Microsoft Exchange, которая предшествует версии Microsoft Exchange на исходном сервере или совпадает с ней. Это не касается случаев, когда требуется использовать URL-адрес, который зависит от версии. Для получения дополнительных сведений о зависящих от версии URL-адресах и устаревших именах узлов в среде Exchange 2007 и Exchange 2010 см. статью Обновление с клиентского доступа Exchange 2007. Для получения дополнительных сведений о зависящих от версии URL-адресах и устаревших именах узлов в среде Exchange 2010 и Exchange 2013 см. статью Создание имени узла в устаревших версиях Exchange.

Предупреждение.
Если клиент IMAP4, использующий проверку подлинности NTLM, пытается подключиться к серверу клиентского доступа, который размещен на сайте Служба каталогов Active Directory, не содержащем целевой почтовый ящик, соединение не будет выполнено. Чтобы обеспечить прокси-соединение клиента IMAP4 с разными сайтами Служба каталогов Active Directory, нужно выбрать другой метод проверки подлинности.

Примечание.

В каждой организации Exchange, в которой требуется разрешить доступ к ней из веб-клиентов, по меньшей мере один сайт Служба каталогов Active Directory должен иметь выход в Интернет. Все остальные сайты Служба каталогов Active Directory, к которым отсутствует доступ из Интернета, используют сервер или серверы клиентского доступа, доступные из Интернета, для передачи всех соответствующих запросов от внешних клиентов.

Передача данных клиентского доступа через прокси-соединения

На рисунке выше почтовый ящик каждого из пользователей находится на отдельном сервере почтовых ящиков с соответствующим условным номером. Каждый сервер почтовых ящиков располагается на отдельном сайте Active Directory. Пользователь 1 может получать доступ к своему почтовому ящику через сервер клиентского доступа 1 без использования прокси-соединения, а пользователь 2 может получать доступ к своему почтовому ящику через сервер клиентского доступа 2. Если пользователь 3 пытается получить доступ к своему почтовому ящику через сервер клиентского доступа 1 или 2, то один из серверов передает через прокси-соединение этот запрос на сервер клиентского доступа 3. Сервер клиентского доступа 3 не имеет выхода в Интернет, но может принимать запросы от других серверов в пределах брандмауэра. Пользователь не видит процесса передачи данных через прокси-соединения.

Примечание.
Взаимодействие между серверами клиентского доступа на разных сайтах происходит по протоколу Secure HTTP (HTTPS), но серверы клиентского доступа не проверяют состояние сертификата, используемого по умолчанию. Сертификат используется только для шифрования, а не проверки подлинности, и поэтому несоответствия имен, даты окончания срока действия и состояние доверия игнорируются.

Общие сведения о передаче данных через прокси-соединения

Общие сведения о перенаправлении

Пользователи Outlook Web App, получающие доступ к серверу клиентского доступа с выходом в Интернет и находящемуся не на том сайте Служба каталогов Active Directory, на котором размещаются их почтовые ящики, могут перенаправляться на сервер клиентского доступа, находящийся на одном сайте с их сервером почтовых ящиков, если этот сервер клиентского доступа имеет выход в Интернет. Когда пользователь Outlook Web App попытается подключиться к серверу клиентского доступа за пределами сайта Служба каталогов Active Directory с его сервером почтовых ящиков, он увидит веб-страницу со ссылкой на нужный сервер клиентского доступа для своего почтового ящика. Такой метод называется перенаправлением вручную. В Exchange 2010 с пакетом управления 2 (SP2) администратор может настроить автоматическое перенаправление между сайтами, прозрачное для пользователя. Дополнительные сведения см. в разделе "Автоматическое перенаправление между сайтами" далее.

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

Пользователи Exchange ActiveSync, получающие доступ к серверу клиентского доступа с выходом в Интернет и находящемуся не на том сайте Служба каталогов Active Directory, на котором размещаются их почтовые ящики, могут перенаправляться на сервер клиентского доступа, находящийся на одном сайте с их сервером почтовых ящиков, если этот сервер клиентского доступа имеет выход в Интернет, а в мобильном телефоне или устройстве клиента правильно реализована логическая схема перенаправления, встроенная в протокол, используемый при взаимодействии с серверами Exchange 2007 и Exchange 2010. Перенаправление для пользователей Exchange ActiveSync достигается путем отправки на устройство кода ошибки HTTP 451 с URL-адресом, который должен использоваться устройством. Устройство затем автоматически перенастраивается на использование нового URL-адреса.

На рисунке ниже показано, как перенаправление работает в организациях, в которых имеется несколько серверов клиентского доступа на нескольких сайтах Служба каталогов Active Directory.

Перенаправление для Exchange ActiveSync и Outlook Web App в Exchange 2010

На предыдущем рисунке пользователь 1 обычно получает доступ к своему почтовому ящику на сайте Служба каталогов Active Directory 1 с помощью мобильного телефона. Администратор затем перемещает почтовый ящик пользователя на сервер почтовых ящиков 2 на сайте Служба каталогов Active Directory 2. При следующей попытке устройства выполнить синхронизацию сервер вернет ошибку состояния HTTP 451. В сообщении об ошибке указывается URL-адрес, который устройство теперь должно использовать для этого пользователя. На шаге 3 устройство автоматически перенастраивается и подключается к указанному URL-адресу. Пользователь 2, чей почтовый ящик находится на сайте Служба каталогов Active Directory 2, пытается открыть свой почтовый ящик с помощью приложения Outlook Web App путем подключения к серверу клиентского доступа 1 через Интернет. При использовании перенаправления вручную после проверки подлинности пользователя сервер клиентского доступа 1 выводит страницу для пользователя со ссылкой на URL-адрес Outlook Web App для сервера клиентского доступа на сайте Служба каталогов Active Directory 2. Пользователь щелкает ссылку, переходит на сайт Служба каталогов Active Directory 2 и снова выполняет вход для получения доступа к почтовому ящику. При использовании автоматического перенаправления после проверки подлинности пользователь автоматически перенаправляется на URL-адрес Outlook Web App для сервера клиентского доступа на сайте Служба каталогов Active Directory 2.

Автоматическое перенаправление между сайтами

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

Exchange 2010 с пакетом обновления 2 (SP2) позволяет администраторам настраивать автоматическое перенаправление между сайтами. Автоматическое перенаправление между сайтами выполняется для клиентских запросов, которые предназначены для сервера клиентского доступа на другом сайте Active Directory в той же организации Exchange. Например, пользователь с почтовым ящиком на сайте Служба каталогов Active Directory A, который открывает URL-адрес Outlook Web App на сайте Служба каталогов Active Directory B, автоматически перенаправляется на URL-адрес Outlook Web App для сайта Служба каталогов Active Directory A.

Чтобы настроить автоматическое перенаправление между сайтами, администратору потребуется использовать новый параметр CrossSiteRedirectType командлета Set-OWAVirtualDirectory. Параметр имеет два возможных значения. Значение по умолчанию — Manual.

• Silent (автоматически): при выборе этого значения веб-браузер пользователя автоматически перенаправляется, когда серверу клиентского доступа необходимо перенаправить запрос Outlook Web App на сервер клиентского доступа или массив серверов, расположенный на другом сайте Служба каталогов Active Directory. Если для исходного и целевого виртуальных каталогов OWA настроена проверка подлинности на основе форм (требуется SSL), то автоматическое перенаправление также является событием единого входа. Чтобы перенаправление осуществлялось, виртуальному каталогу Outlook Web App целевого сервера клиентского доступа должно быть присвоено значение ExternalURL.

• Manual (вручную): если установлено это значение, пользователи получают уведомление о том, что они пытаются получить доступ к неправильному URL-адресу, и что нужно перейти по ссылке, чтобы открыть правильный URL-адрес Outlook Web App для их почтового ящика. Это уведомление выводится только в том случае, если сервер клиентского доступа обнаруживает необходимость в перенаправлении запроса Outlook Web App на сервер клиентского доступа или массив серверов, расположенный на другом сайте Служба каталогов Active Directory. Чтобы перенаправление осуществлялось, виртуальному каталогу Outlook Web App целевого сервера клиентского доступа должно быть присвоено значение ExternalURL.

Например:

Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent

Дополнительные сведения о командлете Set-OwaVirtualDirectory см. в следующей статье: Set-OwaVirtualDirectory

Передача через прокси-соединение и перенаправление для службы Exchange ActiveSync

Описанный ниже сценарий показывает, как обрабатываются входящие запросы для пользователя, который с помощью мобильного телефона подключается к серверу клиентского доступа Exchange 2010 с именем CAS-01.

1. Сервер клиентского доступа выполняет запрос к службе Служба каталогов Active Directory для определения расположения почтового ящика пользователя и версии Microsoft Exchange, установленной на сервере почтовых ящиков.

2. Если почтовый ящик пользователя находится на сервере Exchange 2003, то входящий запрос передается через прокси-соединение этому серверу Exchange 2003, на котором также размещается виртуальный каталог Exchange ActiveSync. По умолчанию в Exchange 2003 виртуальный каталог Exchange ActiveSync был установлен на все серверы почтовых ящиков. Сайт Служба каталогов Active Directory почтового ящика пользователя неприменим в этом случае, так как на сервере Exchange 2003 сайты Служба каталогов Active Directory для определения расположения не используются. Подключение всегда устанавливается непосредственно с сервера клиентского доступа Exchange 2010 к серверу почтовых ящиков Exchange 2003. 

   Примечание.

   Пользователи, почтовые ящики которых находятся на сервере Exchange 2003, при попытке использования службы Exchange ActiveSync через сервер клиентского доступа Exchange 2010 получат сообщение об ошибке и не смогут выполнить синхронизацию, если для виртуального каталога Microsoft-Server-ActiveSync на сервере Exchange 2003 не включена встроенная проверка подлинности Windows. Встроенная проверка подлинности Windows позволяет серверу клиентского доступа Exchange 2010 и фоновому серверу Exchange 2003 осуществлять взаимодействие.

3. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2007, то сервер CAS-01 определяет, что сервер клиентского доступа Exchange 2007 находится на одном сайте Служба каталогов Active Directory с сервером почтовых ящиков пользователя. Этим сайтом Служба каталогов Active Directory может быть CAS-01. Сервер CAS-01 передает запрос Exchange ActiveSync по адресу InternalURL сервера клиентского доступа Exchange 2007 независимо от значения ExternalURL. Запрос попадает в виртуальный каталог /Proxy, расположенный в виртуальном каталоге Microsoft Server Exchange ActiveSync службы IIS. По умолчанию в нем включена встроенная проверка подлинности Windows.

4. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2010 на одном сайте Служба каталогов Active Directory с сервером CAS-01, то сервер CAS-01 предоставляет доступ к этому ящику. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2010 на другом сайте Служба каталогов Active Directory, то сервер CAS-01 определяет сервер клиентского доступа на одном сайте Служба каталогов Active Directory с сервером почтовых ящиков пользователя. Сервер CAS-01 определяет, настроено ли для какого-либо сервера клиентского доступа Exchange 2010 на сайте Служба каталогов Active Directory свойство ExternalURL в виртуальном каталоге Exchange ActiveSync. Если да, то сервер CAS-01 выдает клиенту код ошибки HTTP 451 вместе со значением ExternalURL и дает клиенту инструкцию на перенаправление в это расположение. Если значение ExternalURL не определено, то подключение к серверу клиентского доступа устанавливается через прокси-сервер с помощью имени FQDN, заданного в свойстве InternalURL, а именно для виртуального каталога /Proxy. Этот виртуальный каталог расположен под виртуальным каталогом Exchange ActiveSync в службах IIS, и для него по умолчанию включена встроенная проверка подлинности Windows.

   Важно!
   Передача данных через прокси-соединение невозможна между виртуальными каталогами, использующими обычную проверку подлинности. Для взаимодействия клиентов, которое должно осуществляться между виртуальными каталогами Exchange ActiveSync на различных серверах через прокси-соединение, в виртуальном каталоге /Proxy должна использоваться встроенная проверка подлинности Windows.

Общие сведения о передаче данных через прокси-соединения

Передача через прокси-соединение и перенаправление для приложения Outlook Web App

Описанный ниже сценарий показывает, как обрабатываются входящие запросы для пользователя, который с помощью приложения Outlook Web App подключается к серверу клиентского доступа Exchange 2010 с именем CAS-01.

1. Сервер клиентского доступа выполняет запрос к службе Служба каталогов Active Directory для определения расположения почтового ящика пользователя и версии Microsoft Exchange, установленной на сервере почтовых ящиков.

2. Если почтовый ящик пользователя находится на сервере Exchange 2003, а пользователь пытается получить доступ к приложению Outlook Web App, используя адрес https://имя_домена/owa, то ему выдается сообщение об ошибке, так как сервер клиентского доступа Exchange 2010 не может непосредственно предоставить доступ через Outlook Web App к почтовому ящику Exchange 2003. Тем не менее, если администратор настроил перенаправление с сервера Exchange 2010 на сервер Exchange 2003, что характерно для периода перехода с версии Exchange 2003 на Exchange 2010, то для свойства Exchange2003URL виртуального каталога Outlook Web App было установлено значение сервера Exchange 2003, доступного из Интернета.

3. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2007, сервер CAS-01 определяет, что сервер клиентского доступа находится на одном сайте Служба каталогов Active Directory с сервером почтовых ящиков пользователя. Если сервер почтовых ящиков Exchange 2007 находится на одном сайте Служба каталогов Active Directory CAS-01, то это приведет к одному из четырех возможных результатов.

   • Сервер CAS-01 выполнит поиск свойства Exchange 2007 ExternalURL, параметр которого ExternalAuthenticationMethods идентичен параметру InternalAuthenticationMethods на сервере клиентского доступа Exchange 2010. Если параметры идентичный, то сервер CAS-01 выполнит перенаправление на этот внешний URL-адрес. Если для исходного и целевого серверов клиентского доступа включена проверка подлинности на основе форм (FBA), исходный сервер клиентского доступа отправит браузеру скрытую форму с учетными данными пользователя и параметрами FBA, а также URL-адрес перенаправления. Все эти операции прозрачны для пользователя.

   • Если соответствующий параметр ExternalURL не найден, сервер CAS-01 выполнит поиск сервера клиентского доступа Exchange 2007, для которого настроено свойство ExternalURL, независимо от совпадения. Если он найден, то сервер CAS-01 выполнит перенаправление на этот внешний URL-адрес. Это приведет к тому, что у пользователя будет запрашиваться проверка подлинности.

   • Если соответствующий параметр ExternalURL не найден, сервер CAS-01 выполнит поиск сервера клиентского доступа Exchange 2007 со свойством InternalURL, параметр InternalAuthenticationMethods которого идентичен параметру InternalAuthenticationMethods на сервере клиентского доступа Exchange 2010. При его обнаружении сервер CAS-01 выполнит перенаправление на этот адрес InternalURL. Если проверка подлинности на основе форм включена, то это приведет к перенаправлению на единый вход.

   • Если соответствующий адрес InternalURL не найден, сервер CAS-01 выполнит поиск сервера клиентского доступа Exchange 2007 с настроенным адресом InternalURL, независимо от совпадения. При его обнаружении сервер CAS-01 выполнит перенаправление на этот адрес InternalURL. Это приведет к тому, что у пользователя будет запрашиваться проверка подлинности.

   Если сервер почтовых ящиков Exchange 2007 находится на другом сайте Служба каталогов Active Directory, то сервер CAS-01 определяет, задано ли свойство ExternalURL на этом сайте Служба каталогов Active Directory. Если оно задано, а автоматическое перенаправление между сайтами не включено, то для параметра CrossSiteRedirectType задается значение Manual, затем выполняется перенаправление вручную. В этом сценарии пользователю предоставляется активизируемая щелчком ссылка, по которой выполняется перенаправление на указанный URL-адрес.

   Если автоматическое перенаправление между сайтами включено, то для параметра CrossSiteRedirectType задается значение Silent, а пользователь автоматически перенаправляется на указанный URL-адрес. Если свойство ExternalURL отсутствует, а в качестве метода проверки в виртуальном каталоге /OWA выбрана встроенная проверка подлинности Windows, то сервер CAS-01 передаст через прокси-соединение запрос пользователя на сервер клиентского доступа, который задан в свойстве InternalURL.

   Важно!

   Чтобы разрешить серверу клиентского доступа Exchange 2010 передавать через прокси-соединение запросы Outlook Web App на сервер клиентского доступа Exchange 2007 на другом сайте Служба каталогов Active Directory, необходимо скопировать папку самой последней версии с сервера клиентского доступа Exchange 2007 на сайте назначения Служба каталогов Active Directory из папки %installpath%\ClientAccess\OWA\ в аналогичный каталог на сервере клиентского доступа Exchange 2010, который создает запрос прокси-сервера.

   Важно!

   Сервер клиентского доступа Exchange 2010 никогда не передает через прокси-соединение запросы Outlook Web App на сервер клиентского доступа Exchange 2007 на том же сайте Служба каталогов Active Directory. Все запросы в пределах одного сайта Служба каталогов Active Directory перенаправляются на сервер клиентского доступа Exchange 2007 с помощью свойств InternalURL или ExternalURL для этого сервера, в зависимости от того, какие свойства настроены.

4. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2010 на одном сайте Служба каталогов Active Directory с сервером CAS-01, то сервер CAS-01 предоставляет доступ к этому ящику. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2010 на другом сайте Служба каталогов Active Directory, то сервер CAS-01 определяет сервер клиентского доступа на одном сайте Служба каталогов Active Directory с сервером почтовых ящиков пользователя. После его нахождения система Exchange 2010 определяет, установлено ли для сервера клиентского доступа свойство ExternalURL на сайте Служба каталогов Active Directory. Если свойство задано, а автоматическое перенаправление между сайтами не включено, то пользователю предоставляется активизируемая щелчком ссылка, по которой выполняется перенаправление на указанный URL-адрес. Если автоматическое перенаправление между сайтами включено, то пользователь автоматически перенаправляется на указанный URL-адрес. Если адрес ExternalURL не установлен, а в качестве метода проверки в виртуальном каталоге выбрана встроенная проверка подлинности Windows, то сервер CAS-01 передаст через прокси-соединение запрос пользователя на сервер клиентского доступа, который задан в свойстве InternalURL.

Передача через прокси-соединение для панели управления Exchange

В системе Exchange 2010 имеется веб-интерфейс для пользователей и администраторов организации, который позволяет настраивать параметры почтовых ящиков или самой организации. К панели управления Exchange (ECP) можно получить доступ через меню «Параметры» в приложении Outlook Web App или в приложении Outlook 2010 путем выбора параметров голосовой почты, отправки запроса на сведения об отслеживании сообщений или настройки мобильных уведомлений. Выбор любого из этих параметров в приложении Outlook запускает сеанс веб-браузера.

Назначение сеанса зависит от текущего состояния подключения клиента Outlook. Если клиент Outlook подключается с помощью протокола RPC через TCP, то он переходит по адресу InternalURL виртуального каталога панели управления Exchange. Если клиент подключается с помощью функции Outlook Anywhere, то клиент Outlook запускает сеанс браузера. В сеансе браузера выполняется попытка подключиться по адресу ExternalURL виртуального каталога панели управления Exchange. URL-адреса предоставляются клиенту Outlook через службу автообнаружения.

Когда внутренний клиент подключается по протоколу TCP, то в сеансе панели управления Exchange всегда устанавливается подключение к серверу клиентского доступа на том же сайте Служба каталогов Active Directory, на котором находится почтовый ящик пользователя. Передача через прокси-соединение в данной ситуации не используется. Когда клиент за пределами корпоративной сети использует для подключения функцию Outlook Anywhere, то он открывает сеанс браузера по внешнему URL-адресу виртуального каталога панели управления Exchange или по внешнему URL-адресу сайта Служба каталогов Active Directory, доступного из Интернета, если почтовый ящик пользователя располагается на сайте, недоступном из Интернета.

Логическая схема передачи через прокси-соединение для панели управления Exchange такая же, как для приложения Outlook Web App. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2010 на одном сайте Служба каталогов Active Directory с сервером клиентского доступа, получающим запрос, то сервер клиентского доступа предоставляет доступ к почтовому ящику. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2010 на другом сайте Служба каталогов Active Directory, то сервер клиентского доступа определяет другой сервер клиентского доступа на одном сайте Служба каталогов Active Directory с сервером почтовых ящиков пользователя. Исходный сервер клиентского доступа передает запрос пользователя на этот сервер клиентского доступа.

Панель управления Exchange выполняет перенаправление, но если пользователь не введет явным образом URL-адрес для доступа к этой панели, то это происходит редко. Если пользователь получает доступ к панели управления Exchange из Outlook Web App, то приложение Outlook Web App отвечает за проверку правильности используемого пользователем URL-адреса. Если пользователь применяет Outlook 2010, то за проверку правильности используемого им для панели управления Exchange URL-адреса отвечают приложение Outlook и служба автообнаружения. 

Общие сведения о передаче данных через прокси-соединения

Передача через прокси-соединение для веб-служб Exchange

Веб-службы Exchange обеспечивают интерфейс передачи сообщений XML, который позволяет управлять элементами хранилища Exchange и получать доступ к функциям сервера Exchange из клиентских приложений. С точки зрения передачи через прокси-соединение, перенаправления и клиента эта функциональная возможность обычно используется в контексте одного из следующих аспектов.

• Запросы в службу доступности

• Запросы на автообнаружение

• Настройка и проверка состояния автоматических ответов «Отсутствие на работе»

Приложение, написанное с использованием веб-служб Exchange, может применять сценарий передачи через прокси-соединение для таких задач, как настройка сообщения с автоматическим ответом «Отсутствие на работе», которое будет передаваться через прокси-соединение между сайтами Служба каталогов Active Directory, если это необходимо. 

В следующей процедуре показано, как обрабатываются входящие запросы для пользователя, который создает запрос в службу доступности на сервер клиентского доступа Exchange 2010 с именем CAS-01. Пользователь использует приложение Outlook Web App для проверки доступности другого пользователя в той же организации Exchange.

1. Сервер CAS-01 выполняет запрос в службу Служба каталогов Active Directory для определения расположения почтового ящика пользователя и версии Microsoft Exchange, установленной на сервере почтовых ящиков.

2. Если почтовый ящик пользователя находится на сервере Exchange 2003, то приложение Outlook Web App создает подключение HTTP к виртуальному каталогу /Public на сервере Exchange 2003 и получает запрашиваемые сведения из системной папки сведений о доступности.

3. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2007, возвращается сообщение об ошибке. В организации Exchange, размещающей почтовые ящики на сервере почтовых ящиков Exchange 2007, должен существовать сервер клиентского доступа Exchange 2007, доступный из-за пределов этой организации. Служба автообнаружения обеспечивает возврат правильного URL-адреса веб-служб Exchange клиенту. Этот URL-адрес должен соответствовать версии сервера почтовых ящиков, на котором размещен почтовый ящик пользователя.

4. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2010 на одном сайте Служба каталогов Active Directory с сервером CAS-01, то сервер CAS-01 сам предоставляет доступ к этому ящику для получения запрашиваемых сведений. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2010 на другом сайте Служба каталогов Active Directory, то сервер CAS-01 выполняет передачу через прокси-соединение на сервер клиентского доступа на этом сайте Служба каталогов Active Directory, используя имя FQDN, заданное в свойстве InternalURL виртуального каталога /EWS.

   Важно!
   Сервер клиентского доступа Exchange передает через прокси-соединение запросы в службу доступности с одного сервера на другой независимо от того, установлено ли свойство ExternalURL.

   Важно!

   Некоторые приложения веб-служб Exchange используют такие веб-методы, как GetEvents и Unsubscribe, которые имеют очень сильное сходство с сервером клиентского доступа. Когда один сервер клиентского доступа должен передать через прокси-соединение один из этих запросов на другой сайт Служба каталогов Active Directory, он может использовать свойство InternalNLBBypassURL сервера клиентского доступа, в качестве значения которого должно быть всегда установлено имя FQDN самого несущего сервера. Это гарантирует, что сервер клиентского доступа, создающий запрос, может поддерживать сходство с определенным сервером клиентского доступа на целевом сайте Служба каталогов Active Directory.

Веб-службы Exchange сами по себе не предоставляют функцию перенаправления, так как служба автообнаружения, которая используется для предоставления URL-адресов приложению, обеспечивает URL-адреса, необходимые для доступа к определенному почтовому ящику. Например, если почтовый ящик перемещается между сайтами Служба каталогов Active Directory, то приложение Outlook получает обновленные URL-адреса для определенного сайта Служба каталогов Active Directory от службы автообнаружения, когда она далее выдает запрос. Это иногда может приводить к созданию клиентом запросов в службу доступности на сервер клиентского доступа не на том сайте Служба каталогов Active Directory, на котором находится его почтовый ящик. Но так как служба доступности по-прежнему будет обрабатывать запросы и передавать их через прокси-соединение по мере необходимости, то это не окажет на пользователя никакого влияния.

Важно!

В организации Exchange, размещающей почтовые ящики на сервере почтовых ящиков Exchange 2007, должен существовать сервер клиентского доступа Exchange 2007, доступный из-за пределов этой организации. Когда служба автообнаружения возвращает правильный URL-адрес веб-служб Exchange запрашивающему клиенту, этот URL-адрес соответствует версии сервера, на котором размещен почтовый ящик пользователя. В организациях Exchange, в которых почтовые ящики размещаются на серверах почтовых ящиков Exchange 2007 и Exchange 2010, для веб-служб Exchange необходимо настроить два внешних URL-адреса — по одному для каждой установленной версии Exchange.

Передача через прокси-соединение для протоколов POP3 и IMAP4

Сервер Exchange 2010 может передавать через прокси-соединение сеансы POP3 и IMAP4 между серверами клиентского доступа и сайтами Служба каталогов Active Directory.

Описанный ниже сценарий показывает, как обрабатываются входящие запросы для пользователя, который с помощью POP3-клиента делает запрос на сервер клиентского доступа Exchange 2010 с именем CAS-01.

1. Сервер CAS-01 выполняет запрос в службу Служба каталогов Active Directory для определения расположения почтового ящика пользователя и версии Microsoft Exchange, установленной на сервере почтовых ящиков.

2. Если почтовый ящик пользователя находится на сервере Exchange 2003, то сервер CAS-01 передает подключение через прокси-соединение службе POP3, используемой на сервере Exchange 2003, на котором размещается этот почтовый ящик.

3. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2007, сервер CAS-01 ищет сервер клиентского доступа Exchange 2007 на том же сайте Служба каталогов Active Directory, что и сервер почтовых ящиков пользователя, который может быть на одном сайте Служба каталогов Active Directory с сервером CAS-01. Сервер CAS-01 передает запрос через прокси-соединение на сервер клиентского доступа.

4. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2010 на одном сайте Служба каталогов Active Directory с сервером CAS-01, то сервер CAS-01 сам осуществляет доступ к этому ящику. Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2010 на другом сайте Служба каталогов Active Directory, то сервер CAS-01 выполняет передачу через прокси-соединение на сервер клиентского доступа, используя имя FQDN, заданное в свойстве InternalConnectionSettings конфигурации службы POP для этого сервера.

   Важно!
   Для служб POP3 и IMAP4 не существует параметров InternalURL и ExternalURL, и сервер клиентского доступа Exchange 2010 передает запросы к службам POP3 и IMAP4 с одного сервера на другой, когда это необходимо.

   Важно!

   Серверы клиентского доступа, которые пытаются выполнить передачу через прокси-соединение на другой сайт Служба каталогов Active Directory, не проверяют, запущена ли фактически служба POP3 или IMAP4 на удаленном сервере клиентского доступа. Поэтому важно не только убедиться, что службы запущены на каждом сервере клиентского доступа на удаленном сайте Служба каталогов Active Directory, но и применить подсистему балансировки нагрузки для службы. Балансировка нагрузки будет обсуждаться далее в этом разделе.

Общие сведения о передаче данных через прокси-соединения

Настройка передачи данных через прокси-соединения

Если сервер клиентского доступа имеет выход в Интернет, задайте свойство ExternalURL в виртуальных каталогах /Microsoft-Server-ActiveSync, /OWA, /ECP и /EWS с помощью консоли управления Exchange (EMC) или командной консоли Exchange. Виртуальный каталог EWS можно настроить только с помощью командной консоли. Свойство InternalURL настраивается автоматически во время начальной установки Exchange 2010 и должно изменяться только в том случае, если требуется использовать решение балансировки нагрузки. Свойство ExternalURL должно содержать имя FQDN, зарегистрированное для организации Exchange в службе DNS.

В следующей таблице содержатся соответствующие значения для свойств ExternalURL и InternalURL для сервера клиентского доступа, доступного из Интернета, для организации Exchange, которая осуществляет доступ к приложению Outlook Web App, используя URL-адрес https://mail.contoso.com. Во второй таблице приводятся соответствующие значения свойств ExternalURL и InternalURL для недоступного из Интернета сервера клиентского доступа на втором сайте Служба каталогов Active Directory для той же организации. Все эти виртуальные каталоги необходимо настроить на использование встроенной проверки подлинности Windows. Передача через прокси-соединение не поддерживается для тех виртуальных каталогов, в которых используются другие методы проверки подлинности, за исключением служб POP3 и IMAP4, применяющих протоколы SSL/TLS и передающих через прокси-соединение учетные данные пользователя для обычной проверки подлинности.

Примечание.
Если новые виртуальные каталоги Outlook Web App создаются с помощью командной консоли, необходимо вручную настроить свойство InternalURL этих виртуальных каталогов.

Параметры InternalURL и ExternalURL для сервера клиентского доступа, доступного из Интернета

Служба Exchange 2010	Параметр InternalURL	Параметр ExternalURL
Outlook Web App	https://полное_имя_компьютера/OWA	https://mail.contoso.com/OWA
Exchange ActiveSync	https://полное_имя_компьютера/Microsoft-Server-ActiveSync	https://mail.contoso.com/Microsoft-Server-ActiveSync
Веб-службы Exchange	https://полное_имя_компьютера/EWS/Exchange.asmx	https://mail.contoso.com/EWS/Exchange.asmx
панель управления Exchange;	https://полное_имя_компьютера/ECP	https://mail.contoso.com/ECP

Параметры InternalURL и ExternalURL для сервера клиентского доступа, недоступного из Интернета

Служба Exchange 2010	Параметр InternalURL	Параметр ExternalURL
Outlook Web App	https://полное_имя_компьютера/OWA	$Null
Exchange ActiveSync	https://полное_имя_компьютера/Microsoft-Server-ActiveSync	$Null
Веб-службы Exchange	https://полное_имя_компьютера/EWS/Exchange.asmx	$Null
панель управления Exchange;	https://полное_имя_компьютера/ECP	$Null

Настройка перенаправления

Если несколько сайтов Служба каталогов Active Directory имеют выход в Интернет, задайте свойство ExternalURL в виртуальных каталогах /OWA и /Microsoft-Server-ActiveSync с помощью консоли управления Exchange или командной консоли, чтобы разрешить перенаправление между ними. Свойство InternalURL настраивается автоматически во время начальной установки Exchange 2010 и должно изменяться только в том случае, если требуется использовать решение балансировки нагрузки. В следующих двух таблицах приведен список параметров ExternalURL и InternalURL для серверов клиентского доступа на двух сайтах Служба каталогов Active Directory для компании с названием Contoso. Этими двумя сайтами являются usa.contoso.com и europe.contoso.com.

Примечание.
Если новые виртуальные каталоги Outlook Web App создаются с помощью командной консоли, необходимо вручную настроить свойство InternalURL этих виртуальных каталогов.

Параметры свойств InternalURL и ExternalURL для сервера клиентского доступа, доступного из Интернета, на сайте usa.contoso.com

Служба Exchange 2010	Параметр InternalURL	Параметр ExternalURL
Outlook Web App	https://полное_имя_компьютера/OWA	https://usa.contoso.com/OWA
панель управления Exchange;	https://полное_имя_компьютера/ECP	https://usa.contoso.com/ECP
Exchange ActiveSync	https://полное_имя_компьютера /Microsoft-Server-ActiveSync	https://usa.contoso.com/ Microsoft-Server-ActiveSync
Веб-службы Exchange	https://полное_имя_компьютера/EWS/Exchange.asmx	https://usa.contoso.com/EWS/Exchange.asmx

Параметры свойств InternalURL и ExternalURL для сервера клиентского доступа, доступного из Интернета, на сайте europe.contoso.com

Служба Exchange 2010	Параметр InternalURL	Параметр ExternalURL
Outlook Web App	https://полное_имя_компьютера/OWA	https://europe.contoso.com/OWA
панель управления Exchange;	https://полное_имя_компьютера/ECP	https://europe.contoso.com/ECP
Exchange ActiveSync	https://полное_имя_компьютера /Microsoft-Server-ActiveSync	https://europe.contoso.com/ Microsoft-Server-ActiveSync
Веб-службы Exchange	https://полное_имя_компьютера/EWS/Exchange.asmx	https://europe.contoso.com/EWS/Exchange.asmx

Примечание.
Если свойство ExternalURL не задано в виртуальном каталоге Exchange ActiveSync по меньшей мере на одном сайте Служба каталогов Active Directory, в службе автообнаружения произойдет сбой при настройке этих мобильных телефонов, так как значение, заданное для свойства ExternalURL, передается на мобильные телефоны во время процесса автообнаружения.

Общие сведения о передаче данных через прокси-соединения

Прокси-соединение с балансировкой нагрузки на сеть

В организации, в которой имеется несколько сайтов Служба каталогов Active Directory и несколько серверов клиентского доступа на каждом сайте, можно использовать балансировку сетевой нагрузки (NLB) для выравнивания нагрузки в трафике, передаваемом через прокси-соединение между серверами клиентского доступа на каждом сайте, и для пользователей, непосредственно получающих доступ к этим серверам. Простого развертывания подсистемы балансировки нагрузки недостаточно для обеспечения эффективной балансировки трафика. Кроме того, необходимо выполнить некоторые дополнительные настройки свойств ExternalURL и InternalURL. В массив с балансировкой нагрузки рекомендуется включать только серверы клиентского доступа, находящиеся на одном сайте Служба каталогов Active Directory. Балансировку сетевой нагрузки можно разворачивать как на сайтах Служба каталогов Active Directory, доступных из Интернета, так и на недоступных из Интернета сайтах Служба каталогов Active Directory.

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

Параметры виртуальных каталогов для серверов клиентского доступа в организациях, использующих балансировку сетевой нагрузки

Виртуальный каталог /service	InternalURL	ExternalURL (сайт Active Directory, доступный из Интернета)	ExternalURL (сайт Active Directory, недоступный из Интернета)
/OWA	Имя FQDN для NLB (см. следующие рекомендации)	Имя FQDN для NLB	$null
/ECP	Имя FQDN для NLB (см. следующие рекомендации)	Имя FQDN для NLB	$null
/Microsoft-Server-ActiveSync	Имя FQDN для NLB	Имя FQDN для NLB	$null
/OAB	Имя FQDN для NLB	Имя FQDN для NLB	$null
/EWS	Имя FQDN для NLB	Имя FQDN для NLB	$null
POP/IMAP	(InternalConnectionsSettings) Имя FQDN для NLB	Неприменимо	Неприменимо

При настройке свойства InternalURL используйте следующие рекомендации:

• В качестве параметра InternalURL для виртуальных каталогов /OWA и /ECP на всех серверах клиентского доступа на сайте Служба каталогов Active Directory можно указать имя FQDN для NLB серверов этого сайта, если имеются внутренние пользователи Outlook 2010.

• Если сервер клиентского доступа на сайте Служба каталогов Active Directory является целью запроса прокси-сервера Outlook Web App или ECP, полученных от сервера клиентского доступа на любом другом сайте Active Directory, убедитесь, что балансировка нагрузки настроена для обеспечения сходства. Это необходимо, так как сервер клиентского доступа на сайте с выходом в Интернет не может выбирать сервера для отдельных запросов и поддерживать свое сходство.

В следующей таблице приводится список различных параметров проверки подлинности, необходимых для виртуальных каталогов в организации, в которой используется балансировка сетевой нагрузки (NLB). В организации, применяющей такую балансировку, URL-адрес NLB используется вместо определенного URL-адреса сервера клиентского доступа для подключения к клиенту.

Параметры проверки подлинности в виртуальных каталогах для серверов клиентского доступа в организации, использующей URL-адреса NLB для обеспечения отказоустойчивости и балансировки нагрузки

Виртуальный каталог /service	Сайт Active Directory, доступный из Интернета	Сайт Active Directory, недоступный из Интернета
/OWA	Если используется шлюз Microsoft Threat Management Gateway 2010 (Forefront TMG) или шлюз Microsoft Forefront Unified Access Gateway 2010 (Forefront UAG) и включена проверка подлинности на основе форм, используйте обычную или встроенную проверку подлинности Windows в зависимости от параметров делегирования правил брандмауэра. Если трафик из Интернета передается на сервер клиентского доступа без предварительной проверки подлинности, то используйте проверку подлинности на основе форм. Аналогичный метод проверки подлинности должен быть включен в виртуальных каталогах /OWA и /ECP.	Встроенная проверка подлинности Windows
/ECP	Если используется шлюз Forefront TMG или Forefront UAFG и включена проверка подлинности на основе форм, используйте обычную или встроенную проверку подлинности Windows в зависимости от параметров делегирования правил брандмауэра. Если трафик из Интернета передается на сервер клиентского доступа без предварительной проверки подлинности, то используйте проверку подлинности на основе форм. Аналогичный метод проверки подлинности должен быть включен в виртуальных каталогах /OWA и /ECP.	Встроенная проверка подлинности Windows
/Microsoft-Server-ActiveSync	Обычная проверка подлинности.	Обычная проверка подлинности (Передача через прокси-сервер выполняется с помощью вложенного виртуального каталога /Proxy.)
/OAB	Обычная или встроенная проверка подлинности Windows, в зависимости от параметров делегирования правил брандмауэра.	Обычная или встроенная проверка подлинности Windows, в зависимости от параметров делегирования правил брандмауэра (запросы к автономной адресной книге никогда не передаются через прокси-соединение между сайтами Служба каталогов Active Directory. Этот виртуальный каталог используется только клиентами Outlook.)
/EWS	Обычная (необязательно — в зависимости от параметров делегирования правил брандмауэра). Требуется встроенная проверка подлинности Windows.	Встроенная проверка подлинности Windows
POP/IMAP	Как требуется в способе подключения к клиенту.	Как требуется в способе подключения к клиенту

Общие сведения о передаче данных через прокси-соединения

Логическая схема балансировки нагрузки, используемая серверами клиентского доступа при передаче через прокси-соединение между сайтами Active Directory

Когда на сайте существует несколько серверов клиентского доступа, которые будут целевыми при установлении прокси-соединения, а сервер, содержащий почтовый ящик пользователя, комбинирует роли серверов клиентского доступа и почтовых ящиков, то сервер клиентского доступа на исходном сайте Служба каталогов Active Directory будет всегда выбирать этот комбинированный сервер в качестве целевого в прокси-соединениях.

Приложение Outlook Web App, панель управления Exchange и веб-службы Exchange обрабатывают балансировку нагрузки другим способом по сравнению со службой доступности и службой Exchange ActiveSync. Приложение Outlook Web App, панель управления Exchange и веб-службы Exchange реализуют собственную балансировку нагрузки при их развертывании на нескольких серверах клиентского доступа на одном сайте Служба каталогов Active Directory. Если пользователь пытается получить доступ к приложению Outlook Web App по адресу https://www.contoso.com/owa и его данные передаются через прокси-соединение серверу CAS-01, то при следующей попытке получения доступа к Outlook Web App его данные снова будут переданы через прокси-соединение серверу CAS-01, даже если у сервера CAS-02 меньше одновременных подключений. Это обеспечивает возможность завершения длительных транзакций без повторной проверки подлинности или запроса данных. Это известно как сходство. Если сервер CAS-01 недоступен, то пользователь будет переключаться через прокси-соединение на сервер CAS-02, при этом от него может потребоваться повторная проверка подлинности.

Веб-службы Exchange могут поддерживать сходство при передаче через прокси-соединение между сайтами Служба каталогов Active Directory, несмотря на то что для свойства InternalURL целевого сервера настроен URL-адрес NLB. Это связано с тем, что сервер клиентского доступа делает запрос прокси-сервера для приложения, требующего сходства, при котором используется свойство InternalNLBBypassURL на целевом сервере. Для свойства InternalNLBBypassURL настраивается имя FQDN целевого сервера и используется проверка подлинности Windows по умолчанию.

Примечание.

Для приложения Outlook Web App, панели управления Exchange и веб-служб Exchange брандмауэр должен быть настроен на сходство по файлам Cookie или IP-адресам. Это обеспечивает подключение отдельного клиентского приложения каждый раз к одному серверу. Это необходимо, чтобы согласование SSL не выполнялось повторно для каждого запроса. Важно поддерживать сходство по всей цепочке от клиентского приложения до конечного сервера клиентского доступа, вовлеченного в транзакцию.

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

Для Exchange ActiveSync процедура выглядит иначе. Когда сервер клиентского доступа, доступный из Интернета, передает запрос через прокси-соединение на сервер клиентского доступа, недоступный из Интернета, то запрашивающий сервер клиентского доступа ищет другой сервер клиентского доступа на целевом сайте и пытается к нему подключиться, используя значение, заданное для свойства InternalURL. Если сервер не отвечает, то происходит сбой запроса и клиенту возвращается ошибка. Рекомендуется реализовать балансировку нагрузки методом циклического перебора в массиве NLB и установить для свойства InternalURL значение с балансировкой нагрузки.

Кроме того, рекомендуется выполнить балансировку нагрузки для службы доступности. Запросам в службу доступности не требуется поддерживать их состояние подключения. Другими словами, два последовательных запроса в службу доступности от одного клиента можно передать через прокси-соединение на различные серверы клиентского доступа на сайте назначения Служба каталогов Active Directory без оказания влияния на производительность, и проблем с проверкой подлинности не возникает, если для свойства InternalURL установлено значение с балансировкой нагрузки. Кроме того, настройка для свойства InternalURL значения с балансировкой нагрузки дает дополнительные внутренние преимущества для клиентов Outlook 2007 и Outlook 2010, так как служба автообнаружения предоставляет этим клиентским приложениям значение с балансировкой нагрузки, заданное в свойстве InternalURL, которое позволяет им выполнять запросы в службу доступности.

Дополнительные сведения о балансировке нагрузки см. в разделе Общие сведения о балансировке нагрузки в Exchange 2010.

Примечание.

Во многих развертываниях роль сервера клиентского доступа и роль транспортного сервера-концентратора устанавливаются на один компьютер. При такой топологии балансировку сетевой нагрузки для роли сервера клиентского доступа можно настраивать отдельно от роли транспортного сервера-концентратора. Балансировка сетевой нагрузки не поддерживается для роли транспортного сервера-концентратора. Однако она поддерживается для роли сервера клиентского доступа. Чтобы настроить балансировку сетевой нагрузки для роли сервера клиентского доступа, а не для роли транспортного сервера-концентратора, настройте для клиентского доступа порты 80 и 443. В роли транспортного сервера-концентратора высокий уровень доступности реализован непосредственно в программном обеспечении.

Общие сведения о передаче данных через прокси-соединения

Сводные данные по методам клиентского доступа

В таблице ниже содержатся сводные данные о протоколах, которые используются для получения доступа к серверу Exchange 2010, и их использовании для передачи данных через прокси-соединения и для перенаправления.

Протоколы клиентского доступа для перенаправления и передачи данных через прокси-соединения

Протокол/Приложение	Перенаправление поддерживается между серверами клиентского доступа	Передача данных через прокси-соединение поддерживается между серверами клиентского доступа	Комментарии
Outlook Web App	Да	Да	Для использования приложения Outlook Web App необходимо, чтобы на каждом сайте Служба каталогов Active Directory был сервер клиентского доступа.
Панель управления Exchange	Да	Да	Для использования панели управления Exchange необходимо, чтобы на каждом сайте Служба каталогов Active Directory был сервер клиентского доступа.
Exchange ActiveSync	Да	Да	Для использования Exchange ActiveSync необходимо, чтобы на каждом сайте Служба каталогов Active Directory был сервер клиентского доступа.
Веб-службы Exchange	Нет (служба автообнаружения предоставляет приложение с правильным значением ExternalURL)	Да	Для использования веб-служб Exchange необходимо, чтобы на каждом сайте Служба каталогов Active Directory был сервер клиентского доступа.
Служба доступности	Нет (служба автообнаружения предоставляет приложение с правильным значением ExternalURL)	Да	Для использования службы доступности необходимо, чтобы на каждом сайте Служба каталогов Active Directory был сервер клиентского доступа.
POP3 и IMAP4	Нет	Да	Для использования служб POP3 и IMAP4 необходимо, чтобы на каждом сайте Служба каталогов Active Directory был сервер клиентского доступа.

Производительность и масштабируемость использования прокси-соединений

В среде передачи данных через прокси-соединения Exchange 2010 одновременное получение серверами клиентского доступа большого количества запросов часто приводит к существенному падению производительности. Эта проблема часто вызывается тем, что из-за запросов веб-службы из ASP.NET исчерпываются потоки и доступные подключения. При этом серверы клиентского доступа могут отклонять запросы или обрабатывать их с большой задержкой.

Чтобы устранить эти проблемы, можно настроить несколько параметров ASP.NET путем редактирования файла Machine.config на серверах клиентского доступа. Дополнительные сведения о настройке этих параметров см. в статье 821268 базы данных Майкрософт Состязание, плохая производительность и зависания при совершении запросов веб-служб из приложений ASP.NET (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Два параметра, описанные в статье 821268 базы знаний, в среде Exchange 2010 с использованием передачи данных через прокси-соединения необходимо настраивать другим образом. Мы советуем разрешать до 36 потоков на процессор и устанавливать значение maxconnections равным 2000.

Дополнительные сведения о производительности сервера см. в разделе Управление инфраструктурой .NET на сервере Windows Server 2003.

 © Корпорация Майкрософт (Microsoft Corporation), 2010. Все права защищены.