Устранение неполадок в соединениях Outlook 2003

Существует много различных способов доступа к почтовым ящикам Exchange Server 2003. Для традиционного доступа к клиенту Messaging API (MAPI) с помощью Microsoft Office Outlook 2003 можно воспользоваться подключением в классическом оперативном режиме или использовать вызов удаленных процедур (remote procedure call, RPC) через соединение HTTP. Можно также установить связь через Outlook Web Access (OWA) или карманное устройство. И наконец, можно вообще не подключаться и работать с кэшем.

Как правило, для подключения к почтовому ящику Exchange достаточно запустить клиентскую программу. Однако иногда изменения в среде не позволяют клиенту установить связь с почтовым ящиком. Устранить неполадки клиентских соединений MAPI помогут специальные инструменты и методы диагностики. В данной статье рассматриваются способы поиска неисправностей, которые могут пригодиться при сбоях в соединениях Outlook в классическом оперативном режиме. Для этого требуются доступные инструменты диагностики проблем на уровне сети, протоколов и приложений. В следующей статье будут описаны инструменты диагностики и методы поиска неисправностей в соединениях RPC over HTTP.

Диагностика на сетевом уровне

При запуске Outlook в классическом режиме вскоре после аутентификации клиента на экране появляется содержимое почтового ящика. Аутентификация может быть неявной, если используется процедура Integrated Windows и учетные данные хранятся в кэше клиента. Если почтовый ящик не отображается, то в первую очередь нужно убедиться в наличии сетевого соединения между клиентом Outlook и сервером Exchange.

Первое, что необходимо сделать для проверки сетевого соединения, — выяснить, имеет ли клиент сетевой адрес. С помощью команды

ipconfig /all

из командного окна клиента можно определить его сетевую конфигурацию. Данная команда выдает информацию о присвоенном клиенту адресе TCP/IP и о выбираемых по умолчанию шлюзе, DNS-серверах и WINS-серверах. При ошибках с TCP/IP-адресом, возможно, придется перенастроить сетевые параметры или проверить корректность функционирования серверов DHCP.

Если сетевая конфигурация клиента в порядке, то необходимо проверить возможность сетевого соединения между клиентом и сервером Exchange. Самый простой способ ответить на этот вопрос — использовать команду Ping. Из командного окна на клиенте следует запустить команду

ping IPAddress

где IPAddress — TCP/IP-адрес сервера Exchange. Брандмауэр между клиентом и сервером блокирует запросы ICMP (Internet Control Message Protocol — протокол управления сообщениями Internet), используемые командой Ping. Поэтому, если запрос не достигает сервера, это еще не значит, что в сети возникли неполадки.

Углубленную диагностику сетевого соединения можно выполнить с помощью команды Tracert. Ее следует ввести в командное окно на клиенте, используя следующий синтаксис:

tracert IPAddress

Альтернативный вариант — указать вместо адреса TCP/IP имя сервера Exchange. На экране 1 показан типичный результат выполнения команды. Если сетевое соединение между клиентом и сервером разорвано, то результаты Tracert помогут определить место неисправности. Следует помнить, что Tracert, как и Ping, использует запросы ICMP.

Tracert может пригодиться даже при исправном соединении с сервером Exchange. Команда покажет участки маршрута с особенно длительными задержками. Задержки длительностью более 500 мс, безусловно, заслуживают внимания сетевого администратора.

По умолчанию клиент Outlook сначала пытается установить связь с сервером RPC Endpoint Mapper через порт 135 на сервере Exchange, чтобы согласовать набор транзитных портов MAPI в диапазоне 1024-65 535, через которые клиент и сервер Exchange будут обмениваться данными в сеансе связи. Неполадки с транзитными портами MAPI можно обнаружить с помощью команды Netstat. Запустив команду

netstat -a

на клиенте или сервере Exchange, можно выяснить, через какие сетевые порты идет текущий обмен данными. Эту же команду можно запустить на исправно работающих клиентах, чтобы получить картину соединений, которые могут быть установлены в конкретном диапазоне портов. Изменения параметров брандмауэров или беспроводных участков сети могут помешать соединениям в данном диапазоне портов MAPI, поэтому при неожиданном нарушении соединений следует получить у сетевого администратора информацию об изменениях, сделанных в последнее время. Клиенты могут обращаться на серверы Global Catalog (GC) за списком глобальных адресов (Global Address List, GAL), поэтому изменения в серверах GC также могут послужить причиной нарушения связи. Подробнее о том, как изменить диапазон портов MAPI, чтобы использовать конкретные статические значения, рассказано в статье Microsoft «Exchange 2000 and Exchange 2003 Static Port Mappings» (http://support.microsoft.com/?kbid=270836).

В целом причиной нарушений клиентских соединений Outlook чаще всего оказываются ошибки, связанные с преобразованием имен. Следует проверить, все ли короткие или полные (Fully Qualified Domain Name, FQDN) имена, используемые в профиле Exchange MAPI, соответствуют корректным адресам TCP/IP. Убедиться в правильности DNS-преобразования имени сервера Exchange (в коротком или FQDN-формате) можно с помощью команды Nslookup. Команда Nslookup, запускаемая из командного окна на клиенте, имеет следующий синтаксис:

nslookup MyHostName

где MyHostName — имя сервера, соединение с которым нужно подтвердить. Команда Nslookup также позволяет убедиться в корректности преобразования имени сервера Exchange в файле HOSTS или LMHOSTS в каталоге \%systemroot%system32driversetc.

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

Поиск неисправностей на уровне протокола

Клиент Outlook обменивается данными с сервером Exchange, передавая запросы RPC по протоколу MAPI через сетевое соединение. Даже если базовое сетевое соединение в порядке, это не гарантирует прохождения запросов RPC между клиентом и сервером Exchange.

Существует быстрый способ убедиться, что запросы RPC от клиента успешно поступают на сервер. Для этого нужно обратиться к своему профилю MAPI в приложении Mail панели управления. В данном приложении следует повторно ввести имя сервера, а затем щелкнуть на кнопке Check Name. Функция Check Name посылает запрос RPC от клиента на сервер Exchange для проверки параметров почтового ящика. Если запрос RPC выполнен успешно, то в полях имени сервера и имени пользователя появляется подчеркивание, а кнопка Check Name затеняется — это верный признак возможности установить соединение RPC с сервером Exchange.

Если тест Check Name выполнить не удается, значит, запрос RPC не поступил на сервер Exchange (возможно, из-за того, что сетевое устройство, такое как брандмауэр или маршрутизатор, блокирует прохождение пакетов RPC между клиентом и сервером) или службы Exchange не отвечают на запрос RPC (например, сервер Exchange не имеет доступа к GC и не может обработать запрос Check Name). Первая из названных причин будет исключена, если сетевой администратор подтвердит, что запросы RPC не блокируются (возможно, брандмаэуром или proxy-сервером, таким как Microsoft Internet Security and Acceleration, ISA, — Server 2000). Затем следует проверить, работают ли на сервере Exchange службы Exchange. В меню Start нужно перейти к пункту Settings, Control Panel и убедиться, что функционируют по крайней мере службы Exchange System Attendant и Information Store. Полезно также заглянуть в журнал событий на сервере Exchange в поисках явных ошибок, например сбоев при запуске серверов Exchange. Если службы работают и в журнале не зарегистрировано никаких событий, то необходимо проверить с помощью диагностических утилит, поступают ли запросы RPC на сервер Exchange.

Для проверки соединений RPC можно использовать утилиту Rping из наборов ресурсов Microsoft Windows Server 2003 Resource Kit или Microsoft Windows 2000 Server Resource Kit. Rping состоит из двух компонентов: rpings.exe, работающего на сервере Exchange, и rpingc.exe на клиенте. Оба компонента находятся в каталоге Program FilesWindows Resource KitsTools на сервере, на котором был установлен комплект ресурсов. Rpings.exe следует скопировать в любую папку на сервере Exchange. Этот компонент выполняет роль оконечной точки RPC и работает непрерывно после запуска следующей команды:

rpings.exe -p MyProtocol

где MyProtocol — IPX/SPX, NAMEDPIPES, NETBIOS, TCP/IP или VINES, в зависимости от протокола, используемого для подключения клиента Outlook к конкретному серверу Exchange. Команда занимает на бумаге несколько строк, но в командном окне ее следует вводить одной строкой. Наиболее часто используемый протокол — TCP/IP.

Запустив rpings.exe на сервере, следует запустить экземпляр rpingc.exe на клиенте. Графический интерфейс rpingc.exe показан на экране 2. В текстовом поле Exchange Server необходимо ввести корректное имя сервера Exchange. При желании можно выбрать протокол и указать, следует ли проверять соединения только для конечной точки Rping или определенных конечных точек Exchange, таких как функции Store или Admin (т. е. Exchange System Attendant).

С помощью утилиты Rpcdump из комплекта ресурсов можно убедиться, что службы Exchange корректно зарегистрированы в подсистеме RPC. Rpcdump опрашивает службу RPC Endpoint Mapper на сервере Exchange и отображает службы (конечные точки), доступные для соединений RPC. Если службы доступны, то, очевидно, неполадки связаны не со всеми, а только с одним клиентским соединением. Rpcdump можно запустить локально на сервере Exchange или дистанционно с клиента. Для локального запуска на сервере Exchange можно задействовать команду Rpcdump со следующим синтаксисом:

rpcdump /s MyServer /i /v

где ключ /s указывает, что запрос будет направлен на сервер MyServer. Имя MyServer может быть коротким или полным (FQDN). Ключ /i обеспечивает тестирование служб для проверки их реакции. Ключ /v задает режим расширенного вывода. Rpcdump может генерировать массу информации, которую лучше записать в текстовый файл для удобства анализа.

На экране 3 показаны примерные результаты работы Rpcdump на моем сервере Exchange. После запуска Rpcdump на сервере Exchange будет выдан список служб Exchange, в том числе:

  • Exchange Server STORE ADMIN Interface;
  • Microsoft Information Store;
  • Exchange 2003 Server STORE EMSMDB Interface;
  • MS Exchange MTA 'Mta' Interface;
  • MS Exchange MTA 'Qadmin' Interface;
  • MS Exchange System Attendant Cluster Interface;
  • MS Exchange System Attendant Public Interface;
  • MS Exchange System Attendant Private Interface;
  • MS Exchange Directory RFR Interface.

Если службы Exchange работают без ошибок при регистрации и сервер Exchange получает запросы RPC с клиента, но связь по-прежнему отсутствует, необходимо выполнить еще одну проверку сервера Exchange. Возможно, конфигурация сервера была каким-то образом изменена, что мешает регистрации MAPI определенных версий Outlook. Чтобы проверить такую возможность, нужно узнать значение элемента Disable MAPI Clients в разделе реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeISParametersSystem. Если параметр присутствует, то данное значение определит диапазон версий клиента MAPI, которым отказано в регистрации в Exchange Store. При попытке регистрации клиенты получают сообщение об ошибке MAPI_E_LOGON_FAILED. Версии блокированных клиентов представлены строкой с разделением запятыми в элементе Disable MAPI Clients. Например, строка 5.0.2653.24, 11.0.4704.1-11.0.4704.4, 11.0.5604.0 блокирует доступ для всех клиентов MAPI со следующими номерами версий:

  • до 5.0.2653.24 (включительно);
  • от 11.0.4701.1 до 11.0.4704.4 (включительно);
  • от 11.0.5604.0 и более поздние (включительно).

Номер версии клиента MAPI на данном компьютере можно узнать, щелкнув правой кнопкой мыши на файле emsmdb32.dll в каталоге Program FilesCommon FilesSystemMapi1033, выбрав пункт Properties, а затем щелкнув на вкладке Version. Следует обратить внимание, что местоположение файла на других компьютерах может быть несколько иным, в зависимости от используемой версии клиента, но его легко найти с помощью инструмента Search из меню Start.

Диагностика неисправностей на уровне приложений

Случается, что приложение Outlook запускается некорректно или пользователь вносит изменения, нарушающие его работу. Например, он может по ошибке удалить локальные папки, предназначенные для доставки почты. К счастью, с помощью многочисленных ключей командной строки можно настроить различные параметры при запуске Outlook. Чтобы запустить Outlook с ключами командной строки, необходимо ввести следующую команду:

program filesmicrosoft office
 office11outlook.exe
MySwitch

где MySwitch — один из командных ключей, показанных в таблице.

Существует несколько приемов, с помощью которых можно определить причины неполадок, если клиенту Outlook удается установить связь с сервером Exchange, но запуск клиента происходит очень медленно. Эти приемы описаны во врезке «О причинах медленного запуска Outlook».

Стандартные методы диагностики типичных проблем

Мы рассмотрели некоторые типичные проблемы, которые могут помешать подключению клиента Outlook к серверу Exchange. Как правило, нарушения соединений клиент/сервер вызваны неполадками в сети или ошибками в преобразовании имен. Другие причины неисправностей редки. К счастью, проблемы на уровне сети, протокола и приложений можно устранить с помощью доступных и простых инструментов и методов, таких как команды Ipconfig, Ping, Tracert, Netstat, Nslookup, Rpings и Rpcdump.

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

О причинах медленного запуска Outlook

Если клиент Outlook успешно устанавливает соединение с Exchange Server, но запуск клиента занимает слишком много времени (более 60 секунд), то выяснить причину задержки можно с помощью двух тестов. Во-первых, можно использовать инструмент Network Monitor для идентификации существенных задержек (более 500 мс) в передаче пакетов между клиентским компьютером и сервером Exchange. Network Monitor входит в состав Windows Server 2003 и Windows 2000 Server. Однако инструмент необходимо подготовить к работе. В панели управления нужно дважды щелкнуть на пиктограмме Add or Remove Programs и нажать Add/Remove Windows Component. Из раскрывающегося списка следует выбрать пункт Management and Monitoring Tools, а затем щелкнуть на кнопках Next и Finish.

Во-вторых, можно проверить подраздел Rpc_Binding_Order в разделе реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoft ExchangeExchange Provider. Rpc_Binding_Order определяет порядок проверки различных сетевых протоколов при установлении соединения между клиентом Outlook и сервером Exchange. Если первыми проверяются неподдерживаемые протоколы, то переход к следующему протоколу должен происходить после тайм-аута. На экране A показаны стандартные параметры для раздела реестра Rpc_Binding_Order в Windows XP Service Pack 1 (SP1) с Outlook 2003. Как видно на экране A, первым протестирован локальный RPC, за ним IP-соединение, далее SPX-соединение и т. д. Префикс nca представляет собой сокращение Network Connection Architecture. Сейчас большинство клиентов работает с TCP/IP, и данная проблема возникает редко, но тем не менее иногда она может послужить причиной задержек соединений.

Экран А. Содержимое раздела Rpc_Binding_Order