Протокол RPC поверх HTTPS – одна из самых полезных функций Exchange 2003/Outlook 2003. Однако, это одна и из самых разочаровывающих возможностей, поскольку с ней связано большое количество проблем, ведущих к ошибкам соединения.
Если вы хотите прочесть вторую часть статьи, воспользуйтесь ссылкой:
Раньше удаленных пользователей принуждали использовать VPN для связи Outlook с корпоративными серверами Exchange, или же им приходилось использовать ограниченные функции Outlook Web Access. С выходом Exchange 2003 и Outlook 2003 была представлена новая возможность для связи: RPC поверх HTTPS. RPC поверх HTTPS туннелирует удаленные вызовы процедур через HTTPS-соединение, позволяя вам, в случае нахождения вне корпоративной локальной сети, соединяться с Exchange-сервером без установления VPN-соединения. Для того чтобы понять, как устранять неисправности, вам нужно знать, что происходит при создании RPC-соединения. На Рисунке 1 показан типичный вариант использования RPC поверх HTTPS. К данному рисунку можно обращаться при рассмотрении каждого шага создания соединения.
Рисунок 1: Использование RPC поверх HTTPS
Для устранения неисправностей протокола RPC поверх HTTPS следует предпринять несколько шагов для решения самых распространенных проблем:
Мой опыт говорит, что самые распространенные проблемы связаны с настройками клиента. Часто проблема в том, что Outlook не использует базовую аутентификацию или же неправильно настроены имена серверов и параметры соединения. Одна из обычных проблем: у пользователя не установлена правильная версия Outlook или же он работает не в нужной операционной системе. Для установления соединений RPC поверх HTTPS компьютер клиента должен удовлетворять следующим минимальным требованиям:
Часто администраторы вынуждены разрешать пользователям самим настраивать сой профиль, и причиной ошибки может быть обычная описка или неотмеченная опция. Для проверки установок выполните следующее:
В этом окне (Рисунок 2) мы должны удостовериться, что следующие параметры установлены верно:
Рисунок 2: Настройки соединения в Outlook
Если вы используете групповой SSL-сертификат, то главное имя прокси-сервера следует вводить так:
msstd:*.ваш_домен.tld
Две другие распространенные проблемы, случающиеся на стороне клиента, связаны с вводом UPN (имя_пользователя@ваш_домен.tld) и постоянным запросом учетных данных, или же с проблемами производительности и зависания Outlook 2003. Обе эти проблемы легко устраняются установкой Windows XP SP2.
Outlook 2003 разрешает протестировать RPC-соединение путем запуска Outlook из командной строки со следующим параметром:
Outlook.exe /rpcdiag
Перед вами появится окно с информацией о соединении (Рисунок 3), в котором, если вы соединялись с помощью RPC поверх HTTPS, тип соединения будет указан как HTTPS.
Рисунок 3: Команда Outlook.exe /rpcdiag
И, наконец, известно, что Outlook 2003 SP1 отключает параметр Exchange поверх Интернет на вкладке Connection (Соединение) установок Microsoft Exchange в почтовом профиле. Это защищает от настройки и изменения профиля RPC. Если у клиента данный параметр отключен, откройте реестр с помощью программы regedit и найдите ключ:
HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\RPC
Создайте параметр EnableRPDtunnelingUI типа REG_DWORD и установите его значение равным 1.
Вам повезло, если вашим брандмауэром является сервер ISA 2004, поскольку на нем настройка RPC поверх HTTPS очень проста. В ISA 2004 встроена поддержка соединений по протоколу RPC поверх HTTPS, что позволяет легко создавать правила доступа для разрешения трафика такого вида. При публикации Exchange-сервера на ISA 2004 включение доступа RPC поверх HTTPS — это просто отметка на странице выбора служб (Рисунок 4).
Рисунок 4: Правило доступа ISA RPC
Как вы видите, правило для RPC в ISA 2004 очень простое, но проблемы происходят в ISA 2000 и брандмауэрах не от компании Microsoft. Есть возможность настройки RPC поверх HTTPS и в ISA 2000, и рекомендации по решению этой задачи вы можете найти по ссылкам, приведенным в конце статьи.
Часто проблемы в настройках брандмауэра связаны с использованием брандмауэра отличного от ISA 2004. В этом случае проблемы могут возникать при создании профиля RPC. В таких случаях профиль должен быть настроен на использование RPC поверх HTTP, чтобы клиент соединялся с внутренней сетью и получал доступ к Exchange-серверу по TCP-порту 135. Если вы используете ISA 2004, то все это выполняет созданное вами правило публикации, разрешающее RPC поверх HTTPS, однако, если вы используете другой брандмауэр, учтите этот факт.
Мы рассмотрели наиболее распространенные проблемы на стороне клиента и проверили настройки брандмауэра. Во второй части мы рассмотрим проблемы, связанные с SSL-сертификатами, а также с неправильными настройками прокси-сервера RPC и установками Exchange-сервера.
Настройка ISA Server 2000 для поддержки RPC поверх HTTP в Outlook 2003:
http://www.msexchange.org/articles/rpchttppart1.html
http://www.isaserver.org/articles/rpchttppart2.html
http://www.isaserver.org/tutorials/rpchttppart3.html
Настройка Exchange 2003 и Outlook 2003:
http://www.msexchange.org/tutorials/outlookrpchttp.html
http://www.msexchange.org/tutorials/Outlook_2003_Connect_Exchange_2003.html
Средства Windows Server 2003:
http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en
Источник http://www.msexchange.org