Традиционный механизм для доступа таких клиентов Messaging API (MAPI), как Outlook, к почтовым ящикам Exchange Server основан на использовании вызовов удаленных процедур (Remote Procedure Call, RPC) через соединения TCP/IP. Однако в Exchange Server 2003 появился новый механизм: соединения RPC по HTTP, которые обеспечивают большую гибкость для клиентов Microsoft Office Outlook 2003. Действуя от имени клиента, сервер-посредник (proxy server) RPC устанавливает соединения RPC с внутренним (back-end) сервером Exchange, на котором расположен почтовый ящик запрашивающего клиента. Соединения такого типа подробно описаны в статье «Удаленный доступ к Exchange 2003 по каналам HTTP», опубликованной в журнале Windows & .NET Magazine/RE № 7 за 2003 г.

Разобраться в базовой концепции RPC по HTTP несложно, но с внедрением новой формы доступа увеличивается вероятность отказов соединений. Чтобы облегчить диагностику соединений RPC по HTTP, я составил список типичных неисправностей. Приемы поиска неполадок относятся к пяти основным категориям.

  • Проверка предварительных условий.
  • Проверка типа соединения.
  • Проверка конфигурации клиента.
  • Проверка конфигурации сервера.
  • Проверка связи.

Проверка предварительных условий

Для организации соединений RPC по HTTP необходимо выполнить ряд предварительных условий и в процессе диагностики следует в первую очередь убедиться в соблюдении этих условий. Первое из них — на клиентском компьютере должны быть установлены Outlook 2003 и Windows XP Service Pack 2 (SP2) или XP SP1 с соответствующей программой коррекции, 331320, которая устраняет проблемы с клиентскими задержками. Более подробно эта программа описана в статье Microsoft «Outlook 2003 Performs Slowly or Stops Responding When Connected to Exchange Server 2003 Through HTTP» по адресу http://support.microsoft.com/?kbid=331320.

Чтобы убедиться в том, что на машине имеется нужная версия программы коррекции, можно проверить версию файла rpcrt4.dll в каталоге \%windir%system32 на клиентском компьютере. Следует отыскать файл rpcrt4.dll в Windows Explorer, щелкнуть на нем правой кнопкой мыши и выбрать пункт Properties. В диалоговом окне Properties нужно щелкнуть на вкладке Version и выбрать пункт File Version в списке Item name. Необходима версия 5.1.2600.1142 или более новая.

Второе предварительное условие: proxy-сервер RPC должен работать на Windows Server 2003, как и контроллеры домена (DC) или серверы Global Catalog (GC), которые proxy-сервер RPC использует для аутентификации клиентского соединения. Любые GC-серверы, на которые может быть перенаправлен пользователь, также должны работать с Windows 2003. Внутренний (back-end) сервер Exchange и любые другие серверы Exchange (например, общедоступные серверы папок) также должны работать на Windows 2003 и Exchange 2003. Поэтому самое простое правило — задействовать Windows 2003 и Exchange 2003 во всей инфраструктуре.

Проверка типа соединения

Цель метода RPC по HTTP — максимально упростить организацию соединений между Outlook 2003 и Exchange 2003 для конечного пользователя. Это значит, что пользователь не должен замечать различий между соединением RPC по MAPI и соединением RPC по HTTP. Поэтому если Outlook 2003 не может установить соединение RPC по HTTP, то программа автоматически переключается на протокол TCP/IP и пытается организовать соединение RPC по MAPI.

Такой метод удобен при эксплуатации Exchange в штатном режиме, но может стать досадной помехой при первой попытке организовать доступ RPC по HTTP. Процесс переключения протоколов совершенно незаметен, и непонятно, задействовано ли соединение RPC по HTTP или после его отказа активизировано соединение RPC по MAPI.

Существует простой прием, с помощью которого пользователь клиентского компьютера с Outlook 2003 может определить метод подключения к серверу Exchange. Удерживая нажатой клавишу Ctrl, следует щелкнуть правой кнопкой мыши на пиктограмме Outlook в системной панели и выбрать пункт Connection Status. На экране появится диалоговое окно Connection Status, в котором будет указан используемый в данный момент тип соединения.

Чтобы настроить соединение RPC по HTTP, можно отключить автоматическое переключение протоколов. Для этого нужно отредактировать реестр на клиентском компьютере с Outlook 2003. В разделе HKEY_CURRENT_ USERSoftwareMicrosoftOffice11.0RPC следует создать параметр DisableRpcTcpFallback и присвоить ему значение 1 типа DWORD, чтобы блокировать переключение RPC/TCP. Убедившись, что система работает корректно, нужно разрешить переключение, присвоив параметру DisableRpcTcpFallback значение 0.

Проверка конфигурации клиента

Компания Microsoft выпустила две версии RPC по HTTP — Version 1 и Version 2 — с различными возможностями. В Outlook 2003 используется RPC по HTTP Version 2, для которой необходимо, чтобы клиент работал с Secure Sockets Layer (SSL), а соединение было аутентифицировано proxy-сервером RPC. Поэтому требуется проверить конфигурацию профиля MAPI клиента, которая должна быть настроена на использование SSL, и правильно идентифицировать proxy-сервер RPC.

Для проверки конфигурации следует открыть Outlook 2003. В меню Tools нужно выбрать пункт E-mail Accounts. Убедившись, что выбран режим View or change existing e-mail accounts, следует щелкнуть на кнопке Next. Затем необходимо выбрать соответствующую учетную запись и щелкнуть на кнопках Change, More Settings. На экране появится диалоговое окно Microsoft Exchange Server, в котором нужно перейти к вкладке Connection и установить флажок Connect to my Exchange mailbox using HTTP.

Затем следует щелкнуть на Exchange Proxy Settings, чтобы открыть диалоговое окно, показанное на экране 1. При этом должен быть установлен флажок Mutually authenticate the session when connecting with SSL. Установив флажок, необходимо добавить префикс msstd: к имени proxy-сервера RPC в поле Principal name for proxy server.

Экран 1. Проверка конфигурации клиента

Обратите внимание, что первой точкой контакта для клиента Outlook может быть локальный proxy-сервер HTTP, например Microsoft Internet Security and Acceleration (ISA) Server 2000. В этом случае следует убедиться, что данный сервер (а не proxy-сервер RPC) указан в диалоговом окне Exchange Proxy Settings. Кроме того, необходимо убедиться, что локальный proxy-сервер HTTP правильно направляет соединения к proxy-серверу RPC. В случае ISA Server 2000 можно проверить соединения, изучив файлы журналов.

Ниже поля Principal name for proxy server расположен флажок On fast networks, connect using HTTP first, then connect using TCP/IP («В быстрых сетях сначала установить соединение с использованием HTTP, затем пробовать соединяться с использованием TCP/IP») и флажок On slow networks, connect using HTTP first, then connect using TCP/IP («В медленных сетях сначала установить соединение с использованием HTTP, затем соединяться с использованием TCP/IP»). По умолчанию эти флажки устанавливаются для описанных выше переключений. Медленными считаются соединения со скоростью передачи данных не более 115 Кбит/с.

Наряду с настройкой конфигурации в профиле MAPI клиента необходимо убедиться, что клиент Outlook 2003 может установить SSL-соединение с proxy-сервером RPC. Сделать это можно, открыв Microsoft Internet Explorer (IE) и установив соединение https://RpcProxyServer/RPC, где RpcProxyServer — имя proxy-сервера RPC. Сообщение об ошибке HTTP Error 403.2 Forbidden: read access is denied означает, что соединение с RPC Virtual Directory в Microsoft IIS на proxy-сервере RPC установлено. Сообщение об ошибке выводится на экран потому, что, хотя клиент имеет необходимые полномочия для подключения к RPC Virtual Directory, у него нет достаточных разрешений на чтение в этом каталоге.

Проверка конфигурации сервера

В статье «Удаленный доступ к Exchange 2003 по каналам HTTP» описаны основные настройки конфигурации сервера для доступа RPC по HTTP, поэтому я не буду повторяться. Вместо этого мы рассмотрим основные неполадки на сервере, которые мешают корректной работе соединений RPC по http.

  • Неверное значение параметра ValidPorts. Параметр ValidPorts в разделе HKEY_LOCAL_MACHINESOFTWAREMicrosoft RpcRpcProxy proxy-сервера RPC должен указывать все серверы Exchange, контроллеры домена и серверы GC, с которыми устанавливает связь proxy-сервер RPC. Если для организации соединений RPC по HTTP используется сценарий RPCHTTP_Setup.vbs, который можно получить из службы Microsoft Product Support Services (PSS), то все имена узлов и портов должны быть верными. Однако, если RPCHTTP_Setup.vbs не применялся, то необходимо проверить имена узлов и портов. Кроме того, следует убедиться, что proxy-сервер RPC обеспечивает преобразование всех имен, указанных в элементе ValidPorts, а представленный proxy-сервером RPC сертификат действителен.
  • Неправильно настроенный внутренний сервер Exchange. Необходимые параметры реестра внутреннего сервера Exchange автоматически настраиваются в процессе установки Exchange 2003, поэтому проблем с конгфигурацией возникать не должно. Но параметры портов внутреннего сервера Exchange должны быть согласованы с параметрами портов элемента ValidPorts proxy-сервера RPC. Кроме того, нужно помнить, что в Exchange 2003 SP1 появилось новое свойство, позволяющее настроить сервер Exchange в качестве proxy-сервера RPC. Этот многоцелевой сервер называется внешним сервером RPC-HTTP. Таким образом, если имеется отдельный proxy-сервер RPC, то должен быть выбран параметр RPC-HTTP back-end server (а не параметр RPC-HTTP front-end server). Доступ к новому свойству можно получить через Exchange System Manager (ESM). Достаточно щелкнуть правой кнопкой мыши на сервере Exchange, выбрать пункт Properties и щелкнуть на вкладке RPC-HTTP.
  • Неверная настройка контроллеров доменов или серверов GC. Если proxy-сервер RPC устанавливает соединения с любыми DC или серверами GC, то в раздел реестров HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNTDSParameters контроллеров домена или серверов GC должен быть вручную добавлен параметр NSPI Interface Protocol Sequences. Этот дополнительный параметр часто оказывается источником ошибок, поэтому следует проверить его корректность на каждом DC и GC-сервере. Кроме того, необходимо убедиться, что параметры портов GC-серверов корректны и согласованы с параметрами портов в ValidPorts proxy-сервера RPC.

Если соединение установлено не было, а ошибок в конфигурации сервера нет, то можно попробовать перезагрузить сервер. Перезагрузка — примитивный прием, но иногда он помогает.

Проверка связи

Необходимо убедиться, что связь между proxy-сервером RPC, внутренним сервером Exchange и GC-серверами возможна. Самый мощный инструмент диагностики соединений RPC по HTTP — утилита RPC Ping из пакета Microsoft Windows Server 2003 Resource Kit. Outlook 2003 также располагает функциями трассировки RPC, с помощью которых можно обнаружить неполадки в каналах связи.

RPC Ping. RPC Ping — сложный инструмент со множеством ключей и спецификаторов, с помощью которого можно выяснить, достигают ли запросы RPC определенной цели (например, сервера) по указанному соединению HTTP. Полезная информация об RPC Ping приведена в статье Microsoft «How to Use the RPC Ping Utility to Troubleshoot Connectivity Issues with the Exchange По the Internet Feature in Outlook 2003» (http://support.microsoft.com/?kbid=831051).

С помощью RPC Ping можно провести несколько тестов. В частности, подтвердить, что клиент Outlook может установить соединение RPC по HTTP с proxy-сервером RPC. Для этого следует использовать команду

rpcping -t ncacn_http
-s ExchangeServer
-o RpcProxy=ProxyServer
-P «username,domain,*»
-I «username,domain,*»
-H 1 -u 10 -a connect -F 3
-v 3 -E -R HttpProxy

Команда напечатана на нескольких строках, но в командном окне ее следует вводить в одной. То же самое относится к другим многострочным командам в данной статье. Команда сложна, поэтому рассмотрим каждый ее аргумент.

  • Аргумент -t указывает одну из трех последовательностей протоколов: ncacn_http, ncacn_ip_tcp или ncacn_np. Для соединений RPC по HTTP нужно указать ncacn_http.
  • Аргумент -s указывает внутренний сервер Exchange; ExchangeServer — имя сервера.
  • Аргумент -o RpcProxy= указывает proxy-сервер RPC; ProxyServer — имя сервера.
  • Аргумент -P указывает учетную запись, используемую для аутентификации proxy-сервера RPC. Предоставить необходимую информацию можно в одном из двух форматов: «username,domain,*» (если пароль не требуется) или «username,domain,password» (если пароль требуется), где username — имя пользователя, domain — имя домена, а password — пароль пользователя.
  • Аргумент -I указывает учетную запись, которая используется для аутентификации на сервере Exchange. Для передачи необходимой информации также применяется формат «username,domain,*» или «username,domain,password».
  • Аргумент -H указывает схему аутентификации proxy-сервера RPC. Можно указать 1 для типа аутентификации NT LAN Manager (NTLM) или 2 — для типа Basic. В данном примере я указал 1, так как тестировал сетевое соединение с NTLM.
  • Аргумент -u указывает Security Support Provider (SSP). Можно указать 9 (Negotiate), 10 (NTLM), 14 (Secure Channel) или 16 (Kerberos). Поскольку я использовал схему аутентификации NTLM, для данного аргумента выбрано значение 10.
  • Аргумент -a указывает уровень аутентификации, который используется для подключения к proxy-серверу RPC. Возможные значения — connect, call, pkt, integrity или privacy. В данном примере указано значение connect, так как я тестировал соединение со службой.
  • Аргумент -F указывает, следует ли использовать внешние флаги аутентификации RPC по HTTP. Можно указать 2 (нет флага SSL) или 3 (использовать флаг SSL). В данном примере я указал 3, так как применяется соединение SSL.
  • Аргумент -v указывает режим протоколирования. Можно выбрать минимальный режим (1), нормальный режим (2) или полное протоколирование (3). Я рекомендую полный режим, потому что в нем можно собрать больше всего информации.
  • Аргумент -E ограничивает тест связи только proxy-сервером RPC. Обратите внимание, что существует также аргумент -e, поэтому регистр символов имеет значение.
  • Аргумент -R указывает локальный proxy-сервер HTTP; HttpProxy — имя сервера. Если локальный proxy-сервер HTTP использоваться не будет, необходимо указать вместо имени сервера none.

На экране 2 показан образец выполнения этой команды. Обратите внимание на сообщение об ошибке

Error 12029 returned in the WinHttpSendRequest. Ping failed. Оно говорит о том, что неисправен канал связи между клиентом Outlook 2003 и proxy-сервером RPC. В статье «How to Use the RPC Ping Utility to Troubleshoot Connectivity Issues with the Exchange over the Internet Feature in Outlook 2003» приведена таблица, в которой перечислены сообщения об ошибках RPC Ping и возможные причины этих ошибок.

Если после запуска данной команды на экране появляется сообщение Pinging successfully completed, значит, proxy-сервер RPC ответил на запрос, и соединение между клиентом и proxy-сервером RPC в порядке. В этом случае необходимо сразу проверить соединение между proxy-сервером RPC и внутренним сервером Exchange. Для тестирования нужно использовать команду

rpcping -t ncacn_http
-s ExchangeServer
-o RpcProxy=ProxyServer
-P «username,domain,*»
-I «username,domain,*»
-H 1 -u 10 -a connect -F 3
-v 3 -R HttpProxy

Обратите внимание на отсутствие ключа -E. Ключ отсутствует, так как тест связи не следует ограничивать proxy-сервером RPC.

Экран 2. Пример работы команды RPC Ping

Чтобы направить RPC Ping на конечную точку Exchange Store, нужно применить команду

rpcping -t ncacn_http
-s ExchangeServer
-o RpcProxy=ProxyServer
-P «username,domain,*»
-I «username,domain,*»
-H 1 -u 10 -a connect -F 3
-v 3 -R HttpProxy
-f Uuid,Ver

В команде появился ключ -f. Он указывает интерфейс для эхо-тестирования, где Uuid — универсальный уникальный идентификатор (Universally Unique Identifier, UUID), а Ver — номер версии интерфейса. Идентификаторы UUID обеспечивают соединения из других источников. В данном случае UUID — a4f1db00-ca47-1067-b31f-00dd010662d. Если номер версии не указан, то RPC Ping использует версию 1.0.

RPC Ping — мощный инструмент диагностики с очень сложным синтаксисом команд. Если научиться правильно применять нужные ключи, работать с RPC Ping довольно просто, и с помощью утилиты можно получить массу полезной информации о причинах неполадок.

Трассировка RPC Outlook 2003. Чтобы активизировать базовые функции трассировки RPC Outlook 2003, следует открыть Outlook 2003 и выбрать пункт Options из меню Tools. На вкладке Other необходимо щелкнуть на кнопке Advanced Options и установить флажок Enable mail logging (troubleshooting). Затем нужно закрыть Outlook 2003, подождать примерно минуту и вновь открыть программу. С этого момента Outlook 2003 будет генерировать события и записывать их в журнал Application на клиентском компьютере.

Функции трассировки RPC можно расширить, если создать несколько параметров реестра и заменить некоторые DLL на клиентском компьютере. В реестре нужно создать элементы RpcTraceEnable, RpcStackTrace, RpcDumpToFile и RpcOutputDir в разделе HKEY_CURRENT_USERSoftwareMicrosoftOffice11.0OutlookRPC. В каталоге Program FilesCommon FilesSystemMSMAPI1033 следует заменить файлы emsmdb32.dll, emsabp32.dll, emsui32.dll и msmapi32.dll специальными версиями этих DLL. Более подробную информацию об этих изменениях можно получить в службе PSS.

Типичные виновники

Функционирование протокола RPC по HTTP в качестве транспортного протокола между Outlook 2003 и Exchange 2003 — процесс сложный. В основном сложности скрыты от пользователя, но процесс не всегда протекает гладко. На первых этапах реализации проблемы возникают из-за сравнительно простых ошибок в настройке. Некорректная информация о сервере, неверные параметры реестра и не поддающиеся преобразованию имена — обычные причины неисправностей. Проблемы, которые возникают в работающей системе, труднее поддаются диагностике. В подобных обстоятельствах неполадки чаще всего возникают из-за выхода из строя компонентов инфраструктуры. Анализ типичных причин неисправностей, рассмотренных в данной статье, поможет упростить и ускорить поиск и устранение проблем.

Киран Маккорри (kieran.mccorry@hp.com) — главный консультант подразделения Consulting and Integration Technology Group компании HP, работает в Ирландии. Является соавтором книги «Microsoft Exchange 2000 Infrastructure Design» (Digital Press).