Применимо к: Exchange Server 2010 SP1
Последнее изменение раздела: 2011-02-14
В организации Microsoft Exchange Server 2010 сервер клиентского доступа может выступать в роли прокси-сервера для других серверов клиентского доступа организации. Это бывает полезно, когда на различных сайтах Служба каталогов Active Directory в организации находится несколько серверов клиентского доступа и по меньшей мере один из них недоступен из Интернета.
Сервер клиентского доступа также может осуществлять перенаправление для URL-адресов Microsoft Office Outlook Web App и для устройств Exchange ActiveSync. Перенаправление полезно в тех случаях, когда пользователь подключается к серверу клиентского доступа, который находится не на локальном сайте Служба каталогов Active Directory, или если почтовый ящик перемещался между сайтами Служба каталогов Active Directory. Это также применимо, если требуется использовать более удобный 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.
| Примечание. |
|---|
| В каждой организации 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 ActiveSync, получающие доступ к серверу клиентского доступа с выходом в Интернет и находящемуся не на том сайте Служба каталогов Active Directory, на котором размещаются их почтовые ящики, могут перенаправляться на сервер клиентского доступа, находящийся на одном сайте с их сервером почтовых ящиков, если этот сервер клиентского доступа имеет выход в Интернет, а в мобильном телефоне или устройстве клиента правильно реализована логическая схема перенаправления, встроенная в протокол, используемый при взаимодействии с серверами Exchange 2007 и Exchange 2010. Перенаправление для пользователей Exchange ActiveSync достигается путем отправки на устройство кода ошибки HTTP 451 с URL-адресом, который должен использоваться устройством. Устройство затем автоматически перенастраивается на использование нового URL-адреса.
На рисунке ниже показано, как перенаправление работает в организациях, в которых имеется несколько серверов клиентского доступа на нескольких сайтах Служба каталогов Active Directory.
На предыдущем рисунке пользователь 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 и снова выполняет вход для получения доступа к почтовому ящику.
Передача через прокси-соединение и перенаправление для службы Exchange ActiveSync
Описанный ниже сценарий показывает, как обрабатываются входящие запросы для пользователя, который с помощью мобильного телефона подключается к серверу клиентского доступа Exchange 2010 с именем CAS-01.
- Сервер клиентского доступа выполняет запрос к службе Служба
каталогов Active Directory для определения расположения почтового
ящика пользователя и версии Microsoft Exchange, установленной на
сервере почтовых ящиков.
- Если почтовый ящик пользователя находится на сервере 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 осуществлять взаимодействие. - Если почтовый ящик пользователя находится на сервере почтовых
ящиков Exchange 2007, то сервер CAS-01 определяет, что сервер
клиентского доступа Exchange 2007 находится на одном сайте Служба
каталогов Active Directory с сервером почтовых ящиков пользователя.
Это может быть тот же сайт Служба каталогов Active Directory, что и
для CAS-01. Сервер CAS-01 определяет, настроено ли для сервера
клиентского доступа Exchange 2007 свойство ExternalURL в
виртуальном каталоге Exchange ActiveSync. Если да, то сервер
CAS-01 выдает клиенту код ошибки HTTP 451 вместе со значением
ExternalURL и дает клиенту инструкцию на перенаправление в
расположение, заданное в свойстве ExternalURL. Если значение
ExternalURL не определено, то подключение к серверу клиентского
доступа устанавливается через прокси-сервер с помощью имени FQDN,
заданного в свойстве InternalURL, а именно для виртуального
каталога /Proxy. Этот виртуальный каталог расположен ниже
виртуального каталога Exchange ActiveSync в службах IIS, и по
умолчанию для него включена встроенная проверка подлинности
Windows.
- Если почтовый ящик пользователя находится на сервере почтовых
ящиков 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.
- Сервер клиентского доступа выполняет запрос к службе Служба
каталогов Active Directory для определения расположения почтового
ящика пользователя и версии Microsoft Exchange, установленной на
сервере почтовых ящиков.
- Если почтовый ящик пользователя находится на сервере 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, доступного из
Интернета.
- Если почтовый ящик пользователя находится на сервере почтовых
ящиков Exchange 2010, сервер CAS-01 определяет, что сервер
клиентского доступа находится на одном сайте Служба каталогов
Active Directory с сервером почтовых ящиков пользователя. Если
сервер почтовых ящиков Exchange 2007 находится на одном сайте
Служба каталогов Active Directory CAS-01, то это приведет к одному
из четырех возможных результатов.
- Сервер CAS-01 выполнит поиск свойства Exchange
2007 ExternalURL, параметр
которого ExternalAuthenticationMethods идентичен
параметру InternalAuthenticationMethods на сервере клиентского
доступа Exchange 2010. Если параметры совпадают, то сервер CAS-01
выполнит перенаправление на этот внешний 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 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 для этого сервера, в зависимости от того, какие свойства настроены. - Сервер CAS-01 выполнит поиск свойства Exchange
2007 ExternalURL, параметр
которого ExternalAuthenticationMethods идентичен
параметру InternalAuthenticationMethods на сервере клиентского
доступа Exchange 2010. Если параметры совпадают, то сервер CAS-01
выполнит перенаправление на этот внешний URL-адрес. Если
проверка подлинности на основе форм включена, то это приведет к
перенаправлению на единый вход.
- Если почтовый ящик пользователя находится на сервере почтовых
ящиков Exchange 2010 на одном сайте Служба каталогов Active
Directory с сервером CAS-01, то сервер CAS-01 предоставляет доступ
к этому ящику. Если почтовый ящик пользователя находится на сервере
почтовых ящиков Exchange 2010 на другом сайте Служба каталогов
Active Directory, то сервер CAS-01 определяет сервер клиентского
доступа на одном сайте Служба каталогов Active Directory с сервером
почтовых ящиков пользователя. После его нахождения система Exchange
2010 определяет, установлено ли для сервера клиентского доступа
свойство ExternalURL на сайте Служба каталогов Active
Directory. Если да, то пользователю предоставляется активизируемая
щелчком ссылка, по которой выполняется перенаправление на указанный
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.
- Сервер CAS-01 выполняет запрос в службу Служба каталогов Active
Directory для определения расположения почтового ящика пользователя
и версии Microsoft Exchange, установленной на сервере почтовых
ящиков.
- Если почтовый ящик пользователя находится на сервере Exchange
2003, то приложение Outlook Web App создает подключение HTTP к
виртуальному каталогу /Public на сервере Exchange 2003 и получает
запрашиваемые сведения из системной папки сведений о
доступности.
- Если почтовый ящик пользователя находится на сервере почтовых
ящиков Exchange 2007, возвращается сообщение об ошибке. В
организации Exchange, размещающей почтовые ящики на сервере
почтовых ящиков Exchange 2007, должен существовать сервер
клиентского доступа Exchange 2007, доступный из-за пределов этой
организации. Служба автообнаружения обеспечивает возврат
правильного URL-адреса веб-служб Exchange клиенту. Этот URL-адрес
должен соответствовать версии сервера почтовых ящиков, на котором
размещен почтовый ящик пользователя.
- Если почтовый ящик пользователя находится на сервере почтовых
ящиков 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.
- Сервер CAS-01 выполняет запрос в службу Служба каталогов Active
Directory для определения расположения почтового ящика пользователя
и версии Microsoft Exchange, установленной на сервере почтовых
ящиков.
- Если почтовый ящик пользователя находится на сервере Exchange
2003, то сервер CAS-01 передает подключение через прокси-соединение
службе POP3, используемой на сервере Exchange 2003, на котором
размещается этот почтовый ящик.
- Если почтовый ящик пользователя находится на сервере почтовых
ящиков Exchange 2007, сервер CAS-01 ищет сервер клиентского
доступа Exchange 2007 на том же сайте Служба каталогов Active
Directory, что и сервер почтовых ящиков пользователя, который может
быть на одном сайте Служба каталогов Active Directory с сервером
CAS-01. Сервер CAS-01 передает запрос через прокси-соединение на
сервер клиентского доступа.
- Если почтовый ящик пользователя находится на сервере почтовых
ящиков 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 |
|
|
Exchange ActiveSync |
https://полное_имя_компьютера/Microsoft-Server-ActiveSync |
|
|
Веб-службы Exchange |
https://полное_имя_компьютера/EWS/Exchange.asmx |
|
|
Панель управления Exchange |
https://полное_имя_компьютера/ECP |
|
Настройка перенаправления
Если несколько сайтов Служба каталогов 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 сервера или имя FQDN для NLB (см. следующие рекомендации) |
Имя FQDN для NLB |
$null |
|
/ECP |
Имя FQDN сервера или имя 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 для виртуальных каталогов /OWA и /ECP зависят от способа настройки внутреннего доступа в сети и от того, было ли развернуто приложение Outlook 2010. Для настройки свойства InternalURL используйте следующие рекомендации.
- Если сайт Служба каталогов Active Directory является
целевым для приложения Outlook Web App или запроса через
прокси-сервер к панели управления Exchange с сервера клиентского
доступа на любом другом сайте Служба каталогов Active
Directory, то в качестве свойства InternalURL виртуальных
каталогов /OWA и /ECP на всех серверах клиентского доступа на этом
сайте Служба каталогов Active Directory должно быть установлено имя
FQDN сервера. Это происходит потому, что в приложении Outlook Web
App и панели управления Exchange используется только проверка
подлинности Kerberos, при которой может произойти сбой, если для
свойства InternalURL установлено значение с
балансировкой нагрузки. Приложения на сервере клиентского доступа,
такие как Outlook Web App и панель управления Exchange, игнорируют
параметры сертификата при установлении прокси-соединений между
серверами клиентского доступа. Поэтому имена отдельных серверов в
сертификате не требуются для целей прокси-сервера.
- Если сайт Служба каталогов Active Directory имеет выход в
Интернет и на него серверами клиентского доступа никогда не
передается через прокси-соединение трафик из
приложения Outlook Web App или панели управления Exchange, то
значение внутреннего URL-адреса, как правило, не будет подходить
для пользователей Outlook Web App. Во избежание предупреждений и
ошибок, связанных с сертификатами, рекомендуется указать в
сертификате все имена, которые могут применять пользователи для
получения доступа к приложению Outlook Web App. Тем не менее,
если развертывание панели управления Exchange выполнено внутренним
образом, то значение InternalURL остается важным.
- Приложение Outlook 2010 будет получать URL-адрес панели
управления Exchange, который содержит имя FQDN сервера или имя,
определяемое по сбалансированной нагрузке, в зависимости от
значения свойства InternalURL на серверах клиентского
доступа на этом сайте Служба каталогов Active Directory. В отличие
от передачи через прокси-соединение с одного сервера клиентского
доступа на другой, приложение Outlook 2010 и браузер Internet
Explorer не игнорируют проблемы с сертификатами, а требуют
действительный доверенный сертификат, содержащий пространство имен,
соответствующее той службе, к которой осуществляется доступ. Если
для свойства InternalURL серверов клиентского доступа
на сайте Служба каталогов Active Directory было задано имя FQDN, то
при попытке использовать панель управления Exchange из приложения
Outlook 2010 запускается сеанс веб-браузера. Если имя FQDN
отсутствует в сертификате, используемом для защиты сеанса, то при
проверке сертификата произойдет ошибка. В этом случае имя FQDN
сервера должно быть включено в сертификат, установленный на сервере
клиентского доступа на том сайте, который также является целевым
для панели управления Exchange при передаче через прокси-соединение
во избежание проблем с проверкой сертификатов. Кроме того, для
свойства InternalURL должно быть задано имя FQDN
сервера.
- Если сайт Служба каталогов Active Directory не будет являться
целевым при передаче через прокси-соединение с другого сервера
клиентского доступа, но на сайте имеются внутренние клиенты Outlook
2010, то для свойства InternalURL необходимо установить
значение с балансировкой нагрузки, а само имя должно быть включено
в сертификат. Затем пользователи Outlook 2010 на этом сайте получат
дополнительные преимущества после того, как им вместо определенного
имени FQDN сервера будет предоставлен URL-адрес с балансировкой
нагрузки от службы автообнаружения для получения доступа к панели
управления Exchange.
В следующей таблице приводится список различных параметров проверки подлинности, необходимых для виртуальных каталогов в организации, в которой используется балансировка сетевой нагрузки (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 (эта ссылка может указывать на содержимое полностью или частично на английском языке).
Два параметра, описанные в предыдущей статье базы знаний, в среде Exchange 2010 с использованием передачи данных через прокси-соединения необходимо настраивать другим образом. Рекомендуется разрешать до 36 потоков на процессор и устанавливать значение maxconnections равным 2000.
Дополнительные сведения о производительности сервера см. в разделе Управление инфраструктурой .NET на сервере Windows Server 2003.