Принцип работыУстранение ошибок удаленного вызова процедур

Зубаир Александр

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

рассмотрю некоторые общие ошибки, различные методы для определения возникших ошибок RPC, а также покажу некоторые решения для разрешения определенных проблем. До начала рассмотрения определенных ошибок RPC и решений давайте разберемся с терминологией RPC.

Что такое RPC?

RPC – это метод межпроцессного взаимодействия (IPC), используемый клиентами и серверами для связи. Проще говоря, RPC используется программами, обычно на клиентском компьютере, для выполнения программы на серверном компьютере. Например, клиенты Microsoft® Outlook® связываются с Microsoft Exchange Server с помощью RPC. Клиентский компьютер отправляет сообщение серверу с определенными аргументами. Сервер отвечает клиенту сообщением с результатами выполненной программы.

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

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

Другим важным компонентом RPC является служба локатора. Она поддерживает список серверов и служб RPC в сети. Клиент Windows® подключается к контроллеру домена через порты протокола SMB (TCP 139 и 445) и выполняет поиск серверов или служб RPC с помощью службы локатора.

Большинство встроенных служб Windows связываются друг с другом с помощью RPC. Например, службы сертификации, DCOM, FRS, MSMQ, MAPI и служба репликации Active Directory® используют RPC для связи между собой. Поэтому при неправильной работе службы RPC в сети может возникнуть неопределенное количество проблем связи.

Ошибки RPC

Теперь рассмотрим некоторые из ошибок, которые могут произойти при сбое службы RPC. (Это ни в коем случае не исчерпывающий список.)

При сбое службы репликации файлов может возникнуть ужасная ошибка «RPC Unavailable». При подключении диска может появиться ошибка «Отказано в доступе». При использовании оснастки «Active Directory – пользователи и компьютеры» может появиться ошибка «Указанный домен не существует или с ним невозможно связаться». При входе в домен может появиться ошибка «The system cannot log you on to this domain because the system’s computer account in its primary domain is missing or the password on that account is incorrect».

При попытке клиента Microsoft Outlook связаться с Exchange Server сбой RPC может привести к появлению вводящих в заблуждение ошибок, таких как «Your logon information is incorrect» или «Outlook could not log on».

Кроме этих ошибок, при недоступности службы RPC могут возникнуть другие проблемы. Например, просмотр домена в сетевом окружении может быть невозможен или может быть невозможно открыть оснастку «Групповая политика».

Это только несколько примеров, в которых не ожидается возникновение проблем от вызовов RPC. Примеров гораздо больше, и при каждом использовании удаленных процессов проблемы с RPC могут быть исходной причиной ваших трудностей. Итак, как точно узнать и, что более важно, как обнаружить конкретную ошибку? Давайте выясним.

Устранение неполадок

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

Можно использовать средство Repadmin. Эта программа обычно используется для наблюдения и устранения проблем репликации Active Directory, но она также может использоваться для устранения проблем системы отображения конечных точек RPC. Для запуска средства в командной строке введите repadmin /bind. При возникновении проблем RPC может появиться, например, следующее сообщение: «В системе отображения конечных точек не осталось доступных конечных точек». Это первое указание на то, что проблема связана с RPC.

Другой возможностью является использование средства диагностики контроллера домена (DCDiag), программы командной строки для диагностики проблем контроллеров домена. При появлении ошибки «Status is 1722: The RPC server is unavailable» (Состояние 1722: сервер RPC недоступен) вы знаете о наличии проблемы с RPC, которую только что обнаружило средство диагностики контроллера домена.

Иногда при использовании средства Ntdsutil (средство командной строки для управления Active Directory и выполнения различных задач обслуживания) могут появляться ошибки RPC при попытке подключения к серверу. Вероятнее всего вы увидите одну из наиболее часто встречающихся ошибок, например «В системе отображения конечных точек не осталось доступных конечных точек». И вновь это свидетельствует о возможных проблемах службы RPC. Средство Gpotool, проверяющее согласованность объектов групповой политики на контроллерах доменов, также выдаст похожие ошибки, если их причиной является RPC.

В журнале Dcpromo.log, созданный при повышении роли сервера Windows 2000 Server или Windows Server® 2003 до контроллера домена с помощью средства Dcpromo, также могут регистрироваться проблемы RPC. Например, при сбое повышения роли просмотрите журнал. Он находится в папке %windir%\debug. Перечисленные ошибки укажут на причину сборя службы каталогов при репликации раздела или создании объекта. В конце сообщения будет указан код ошибки. Ниже приведен пример типа сообщений об ошибках, которые регистрируются в журнале Dcpromo.log:

 
08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)

Обратите внимание на код ошибки 1722, который четыре раза встречается в этом сообщении и обозначает недоступность сервера RPC. На рис. 1 приведены некоторые коды ошибок и их описания, но множество других кодов ошибок приведено на веб-узле msdn2.microsoft.com/ms681386.

Figure 1 Коды ошибок и их описания

Разрешение ошибок RPC

Теперь, после того как вы узнали об определении некоторых ошибок RPC, давайте рассмотрим некоторые решения.

Клиенты Microsoft подключаются к системе отображения конечных точек RPC через порт 135. Затем система отображения конечных точек сообщает клиенту порт, прослушиваемый запрошенной службой. Номера портов назначаются динамически и могут находиться в диапазоне от 1024 до 65 535. Появление ошибок, таких как 1753, означает, что для системы отображения конечных точек отсутствуют доступные конечные точки, что свидетельствует о том, что система отображения конечных точек RPC не смогла использовать для служб порт с номером более 1024. Я более подробнее рассмотрю это позже.

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

Figure 2 Состояние службы RPC

Убедитесь, что клиент может успешно проверить связь с сервером с проблемами подключения. Например, при наличии проблем связи с сервером DC1 с IP-адресом 192.168.1.200 используйте следующую команду командной строки, чтобы убедиться, что DNS верно разрешает узел DC1:

Ping –a 192.168.1.200

С ключом –a необходимо использовать IP-адрес, а не имя узла.

Если все работает, вы должны получить ответ от DC1, который выглядит как ответ проверки связи, показанный на рис. 3. Обратите внимание, что вместо простого разрешения IP-адреса 192.168.1.200 проверка связи также разрешает имя узла dc1.contoso.com. Это подтверждает, что разрешение имен с помощью DNS работает правильно, и разрешение узла dc1.contoso.com выполняется так, как ожидалось.

Figure 3 Ответ команды ping

C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms

Кроме того, необходимо убедиться, что реестр клиента Windows XP или Windows 2000 содержит как минимум четыре протокола ClientProtocols, указанных на правой панели на рис. 4.

Рис. 4** Перечисленные в реестре протоколы ClientProtocols RPC **

Если какие-либо записи отсутствуют, добавьте новый строковый параметр с именем и типом, показанными на рис. 4. По умолчанию существует пятая запись с именем ncacn_nb_tcp, которая используется для определения NetBIOS по TCP как семейства протоколов для конечной точки. В зависимости от настройки эта запись среди протоколов ClientProtocol может отсутствовать, в этом случае ее можно добавить вручную и посмотреть, поможет ли это разрешению проблем с RPC.

Обратите внимание на параметры в папке Rpc в левой панели рисунка, а именно ClientProtocols, NameService, NetBios и SecurityService. Если присутствует параметр Internet без значения, удалите его и перезагрузите компьютер. Это может разрешить проблему. Как обычно, необходимо быть осторожным при изменении реестра Windows.

Как упоминалось ранее, RPC может использовать порты от 1024 до 65 535, поэтому необходимо убедиться, что эти порты не заблокированы брандмауэром. Самым простым способом определения того, что порт открыт, является использование средства Port Query. Существует две версии этого средства: версия для командной строки (PortQry) и версия с графическим интерфейсом (PortQueryUI).

Средство PortQry доступно для загрузки в центре загрузки Microsoft. Для получения дополнительных сведений ознакомьтесь со статьей «Description of the Portqry.exe Command-Line Utility» (Описание программы командной строки Portqry.exe). В статье приведены краткие описания отчетов PortQry о состоянии и примеры команды для разрешения проблем. Имейте в виду, что также можно использовать версию с графическим интерфейсом, которая намного проще и которую можно загрузить с веб-узла go.microsoft.com/fwlink/?LinkId=73740.

Средство Port Query должно быть запущено на компьютере без ошибок RPC, а затем запущено на компьютере с проблемами с RPC. Например, что проверить, что порт 135, который используется системой отображения конечных точек RPC, открыт, используйте средство PortQry в командной строке следующим образом:

portqry -n [servername] -e 135

Как при использовании PortQuery, так и при использовании PortQueryUI вы получите результаты наподобие следующих:

Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING

Последняя строка показывает, что порт 135 открыт. В противном случае в последней строке содержалось бы NOT LISTENING.

Для проверки диапазона портов введите номера портов диапазона, разделенные запятыми, например «135,1024-5000»".

Дополнительные решения

Если вы использовали все указанные приемы, но проблему разрешить не удается, существует несколько дополнительных решений. В зависимости от определенных проблем в вашей среде вы можете выполнить одно из следующих изменений реестра. (Подождите. Перед изменением реестра необходимо сделать резервную копию системы, в особенности реестра, чтобы в случае сбоя можно было восстановить предыдущее состояние компьютера.)

Первым способом является изменение параметра MaxUserPort, чтобы в нем указывалось наибольший номер порта, который может назначить TCP при запросе приложением доступного порта пользователя. По умолчанию Windows Server 2003 устанавливает для параметра MaxUserPort значение 5000, что означает, что наибольший номер порта – 5000, даже если такого параметра не существует. В зависимости от настройки эта запись может отсутствовать в реестре; в этом случае можно добавить эту запись в местоположение, показанное на рис. 5.

Рис. 5** Параметр MaxUserPort в реестре **

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000

При изменении реестра необходимо помнить о возможных побочных эффектах, что не всегда просто. Изменение этой записи может повлиять на Microsoft Exchange Server, если установлено значение ниже 50 000. Если анализатор соответствия рекомендациям для Exchange Server обнаруживает, что значение раздела реестра MaxUserPort менее 50 000, отображается предупреждение. Корпорация Майкрософт рекомендует установить значение 60 000; в противном случае могут появиться предупреждения прокси NSPI, например событие 9040. Для получения дополнительных сведений см документе «MaxUserPort Value is Too Low» (Значение параметра MaxUserPort слишком низкое) корпорации Майкрософт.

Кроме того, можно изменить значение TcpMaxDataRetransmissions. Для пакетов TCP необходимо подтверждение принимающей стороны. При отсутствии подтверждения до истечения времени передача пакетов повторяется количество раз, определенное параметром TcpMaxDataRetransmissions. Значение этого параметра по умолчанию – 5, но вы можете изменить значение на 4 или даже 3. Но нельзя использовать значение меньше 3.

Если параметр реестра TcpMaxDataRetransmissions не существует, его можно добавить в следующее место реестра:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5

Для получения дополнительных сведений о разделе TcpMaxDataRetransmissions ознакомьтесь со статьей 170359 «How to Modify the TCP/IP Maximum Retransmission Timeout» (Изменение тайм-аута максимального количества повторных передач TCP/IP) базы знаний Майкрософт.

Другое значение, которое можно попробовать изменить, – TcpTimedWaitDelay. Если клиент использует большое количество портов, порты могут закончиться до того, как TCP/IP освободит закрытые подключения. Это происходит из-за того, что TCP/IP не освобождает подключение до истечения двух максимальных сроков жизни сегментов (MSL) (это называется состоянием времени ожидания). Более того, поскольку каждый MSL определен как 120 секунд, TCP/IP не освобождает подключение до истечения двух MSL; освобождение TCP/IP закрытого подключения занимает 240 секунд (4 минуты). Это было известной проблемой Windows NT®, которая были исправлена в пакете обновления; в результате появление этой проблемы сегодня маловероятно. Однако корпорация Майкрософт рекомендует изменить этот параметр как одно из возможных решений для разрешения ошибок системы отображения конечных точек RPC, как было объяснено в статье базы знаний Майкрософт «How to Troubleshoot RPC Endpoint Mapper Errors» (Устранение ошибок системы отображения конечных точек RPC).

Параметр TcpTimedWaitDelay добавляется в следующее местоположение в реестре:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD 
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)

Для получения дополнительных сведений о параметре TcpTimedWaitDelay ознакомьтесь со статьей базы знаний «Windows NT Clients Run Out of Ports» (Порты клиентов Windows NT заканчиваются). Хотя в статье отсутствуют какие-либо рекомендованные конкретные значения, можно попробовать уменьшить значение TcpTimedWaitDelay до 60 (секунд) в десятичном выражение, что составляет 3c в шестнадцатеричном выражении.

Заключение

Ошибки RPC могут являться исходной причиной различных ошибок связи в сети. К счастью, существует несколько изобретательных способов устранения этих трудных проблем. Некоторые предложенные средства являются встроенными, другие имнются в комплекте Windows Server Resource Kit. Многие из них приведены на рис. 6. Эти средства можно использовать для определения причины и месторасположения ошибок RPC и последующего использования одного из описанных в данной статье метода для устранения ошибок.

Figure 6 Средства устранения неполадок RPC

Зубаир Александр, обладатель званий MCSE, MCT и Microsoft MVP, является владельцем компании SeattlePro Enterprises, занимающейся обучением и консультациями в области информационных технологий. Его опыт работы охватывает различные сферы обучения информационным технологиям: автор, преподаватель в колледже, консультант, сетевой инженер, докладчик, архитектор безопасности, системный администратор, технический редактор и преподаватель. С ним можно связаться по адресу alexander@techgalaxy.net.

© 2008 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.