Ошибка «сервер RPC недоступен»: ключевые способы решения проблемы. Ошибка 'Сервер RPC недоступен': способы устранения

RPC — это удаленный вызов процедур, а точнее служба, которая за это отвечает. Речь пойдёт о пользовательских компьютерах. На отдельных серверах и крупных сетях причин этой ошибки может быть великое множество, а я рассмотрю проблему для обычных пользователей ПК.

Эта ошибка (1722 ) возникает в разных ситуациях на системах семейства Windows:

  1. Установка программ (например, для работы с принтером ).
  2. Обновление драйверов и системы.
  3. При шифровании утилитой Bitlocker.
  4. При запуске компьютера.

Ещё недоступность сервера rpc связанна с проблемой отсутствия звука в Windows 7. В Windows XP проблема может возникнуть при обновлении пакета SP2 на SP3. Очень часто возникает при печати, особенно при использовании принтера canon. Несмотря на разнообразность данных ситуаций, решение у всех почти одинаково.

Перед выполнением дальнейших действий убедитесь, что в компьютере не содержаться вирусы. Они так же могут быть причиной этой ошибки.

Что делать если сервер rpc недоступен

Проверьте и при необходимости включите ряд служб из-за отключения которых возникает данная ошибка, а именно:

  1. Диспетчер печати.
  2. Удаленный вызов процедур (RPC ).
  3. Модуль запуска процессов DCOM-сервера.
  4. Питание.

Все действия необходимо выполнить под учётной записью администратора.

Включите эти службы и поставьте автоматический тип запуска. Перейдите в меню Пуск >> Выполнить и введите команду services.msc как изображено ниже. Вы попадёте в панель управления службами компьютера.

Здесь перейдите в свойства перечисленных выше служб, где вы сможете провести изменение их параметров.



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

Эта документация перемещена в архив и не поддерживается.

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

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

Если вы работали с серверными платформами 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 Error - The Directory Service failed to replicate the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 DsRolepInstallDs returned 1722 08/14 10:35:04 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


Роль сервера Служба RPC Служба локатора RPC
Windows Server 2003 - контроллер домена Запущена, автоматически Остановлена, вручную
Windows Server 2003 - рядовой сервер Запущена, автоматически Остановлена, вручную
Windows Server 2003 - изолированный сервер Запущена, автоматически Остановлена, вручную
Windows 2000 Server - контроллер домена Запущена, автоматически Остановлена, автоматически
Windows 2000 Server - рядовой сервер Запущена, автоматически Запущена, вручную
Windows 2000 Server - изолированный сервер Запущена, автоматически Остановлена, вручную

Убедитесь, что клиент может успешно проверить связь с сервером с проблемами подключения. Например, при наличии проблем связи с сервером 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 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 о состоянии и примеры команды для разрешения проблем. Имейте в виду, что также можно использовать версию с графическим интерфейсом, которая намного проще и которую можно загрузить с веб-узла

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

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


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

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

Первым способом является изменение параметра MaxUserPort, чтобы в нем указывалось наибольший номер порта, который может назначить TCP при запросе приложением доступного порта пользователя. По умолчанию Windows Server 2003 устанавливает для параметра MaxUserPort значение 5000, что означает, что наибольший номер порта – 5000, даже если такого параметра не существует. В зависимости от настройки эта запись может отсутствовать в реестре; в этом случае можно добавить эту запись в местоположение, показанное на рис. 5 MaxUserPort Value is Too Low 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 могут являться исходной причиной различных ошибок связи в сети. К счастью, существует несколько изобретательных способов устранения этих трудных проблем. Некоторые предложенные средства являются встроенными, другие имнются в комплекте Windows Server Resource Kit. Многие из них приведены на рис. 6 . Эти средства можно использовать для определения причины и месторасположения ошибок RPC и последующего использования одного из описанных в данной статье метода для устранения ошибок.

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


Средство Описание
DCDiag Анализ состояния контроллеров домена.
Просмотр событий Отображение зарегистрированных событий.
Gpotool Определение верности и согласованности политик.
NetDiag Проверка работоспособности сети.
Сетевой монитор Отслеживание и запись сетевого трафика.
Ntdsutil Предоставляет средства управления для Active Directory.
PortQry, PortQueryUI Используется для проверки подключения TCP/IP.
Repadmin Диагностика проблем репликации контроллеров домена Windows.
RPCDump Обычно используется вместе с сетевым монитором.
RPCPing Используется для подтверждения подключения RPC.

Зубаир Александр , обладатель званий MCSE, MCT и Microsoft MVP, является владельцем компании SeattlePro Enterprises, занимающейся обучением и консультациями в области информационных технологий. Его опыт работы охватывает различные сферы обучения информационным технологиям: автор, преподаватель в колледже, консультант, сетевой инженер, докладчик, архитектор безопасности, системный администратор, технический редактор и преподаватель. С ним можно связаться по адресу [email protected] .
© 2008 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено .

Показ:

Добрый день уважаемые читатели и подписчики, в прошлый раз мы с вами устраняли проблему в Active Directory, а именно ошибку 14550 DfsSvc и netlogon 5781 на контроллере домена, сегодня же продолжается эпопея с продолжением этих ошибок, а именно от них мы избавились, но прилетели новые: Ошибка 1722. Сервер RPC и за последние 24 часа после предоставления SYSVOL в общий доступ зафиксированы предупреждения или сообщения об ошибках. Сбои при репликации SYSVOL могут стать причиной проблем групповой политики. Давайте разбираться в чем дело.

Устраняем ошибку 1722 сервер rpc недоступен

Сетевые проблемы с репликацией и их решение, читайте по ссылке выше, про 14550. И так напомню, у меня есть два домена, родительский и дочерний. В дочернем 3 контроллера домена Active Directory. После переноса одного контроллера домена из одного сайта, ко всем остальным стали появляться ошибки 1722. Сервер RPC не доступен и сервер RPC и за последние 24 часа после предоставления SYSVOL.

Выявил я их при диагностики репликации между контроллерами домена, с помощью команды:

Данная команда показывает все ошибки репликации на предприятии. Вот как выглядит ошибка:

Сервер RPC и за последние 24 часа после предоставления SYSVOL в общий доступ зафиксированы предупреждения или сообщения об ошибках. Сбои при репликации SYSVOL могут стать причиной проблем групповой политики.


Первым делом, чтобы проверить, что с репликацией все хорошо, нужно удостовериться, что по UNC пути \\ваш домен доступна на чтение папка SYSVOL и NETLOGON.


Если они не доступны, то нужно проверить права на папки и проверьте доступность портов службы RPC TCP/UDP 135, возможно у вас они закрыты на брандмауэре. Если все нормально, то двигаемся дальше. Давайте теперь проверим, когда в последний раз реплицировались контроллеры домена, делается это командой:

repadmin /replsummary

В итоге я обнаружил, что у меня dc7 и dc13 имеют ошибку 1722 Сервер RPC недоступен. Порты 135 я проверил, они слушались. Кто не знает как проверить, то вот вам команда telnet в помощь.


Следующим шагом, идет проверка DNS серверов, в настройках стека TCP/IP. Если у вас более одного контроллера домена, то у вас первым dns сервером в настройках сетевого интерфейса должен идти dns другого контроллера домена, затем либо адрес текущего или петлевой Ip, а уже затем любые, что вам нужны.


Так, что правильный порядок DNS серверов, это 90 процентов случаев

Теперь снова выполнив команду repadmin /replsummary, я увидел, что все репликации прошли успешно. Так же советую запустить вручную репликацию AD . и проверить нет ли ошибок, убедитесь, так же, что команда dcdiag /a /q не дает ошибок.

Вот так вот просто решается ошибка 1722 сервер RPC не доступен на контроллере домена по Windows Server 2012 R2. Если у вас есть чем дополнить статью, то просьба написать это в комментариях.

Причина многих сбоев служб Windows - RPC сервис. Расшифровка аббревиатуры - удаленный вызов процедур, а в оригинале - Remote Procedure Call. В статье речь пойдет о версии этой встроенной в операционную систему Windows технологии, которая позволяет приложениям на разных компьютерах NT based ОС (к которым относятся 2000/XP/2003/2008/Vista/Seven) обмениваться потоками данных посредством всевозможных протоколов. На высоком уровне для взаимодействия используются стандарт взаимодействия приложений между собой - DCOM (так называемый MSRPC). Транспортный уровень обычно реализуется с помощью TCP/IP и UDP. Сообщение "Сервер RPC недоступен", связанное с неполадкой сервиса RPC, может возникнуть в результате разных действий. Чаще всего это установка драйверов принтера, попытка доступа к удаленному серверу домена, манипуляции с драйвером видеокарты и так далее.

Для начала смотрим лог событий (меню "Пуск", выбираем второй ряд и а затем и "Администрирование", ну а тут и "Просмотр событий"). Именно это часто помогает определить источник проблемы. Иногда указанная неисправность имеет плавающий характер, то есть вечером все работать оказывается, а утром полный порядок. Тогда обязательно проверьте все компьютеры сети антивирусным пакетом с самыми свежими обновлениями. Симптомы могут быть проявлениями известного "зловреда" Conficker, эксплуатирующего уязвимость архитектуры RPC. Попробуйте также проверить конфигурацию фаерволла в отношении прохождения пакетов через порты с 135 по 445 (можно временно его отключить командой sc sharedacess stop) и обновить систему с помощью патчей с сервера майкрософт (служба "Автоматическое обновление системы").

Есть также очень простой способ в максимально короткое время устранить сообщение "Сервер RPC недоступен" - заменить куст реестра SYSTEM на заведомо не имеющий этой проблемы. Ведь именно там хранятся параметры работы всех сервисов и драйверов. А неработающий сервис - частая причина данной проблемы. Это может помочь, если вирус внедрился в качестве сервиса, а не подменил существующий, как это часто бывает. Лучше всего проделывать эту операцию посредством консоли восстановления. Но можно и воспользоваться службой (зайти в можно с помощью дистрибутива), указав дату до той, когда возникла проблема, или через консоль восстановления Windows скопировать из папки REPAIR файл SYSTEM взамен текущего. Следует отметить, что последнее действие обнулит информацию об оборудовании, что чревато потерей времени на перенахождение всех устройств системы. Часто это самый быстрый и эффективный способ бороться с трудностями, связанными с RPC, без того, чтобы вникать в проблему и возиться с неработающими сервисами.

Если у вас по каким-то причинам нет желания избавиться от сообщения "Сервер RPC недоступен" вышеобозначенным способом, то проверьте с помощью команды sc query, набранной в консоли (чтобы вызвать консоль, выбираем меню "Пуск" > "Выполнить" в открывшимся окне набираем cmd), запущены ли службы DcomLaunch. RpcSS, Spooler. Если они отсутствуют в списке, попробуйте запустить их с помощью команд sc start DcomLaunch; sc start RpcSS; sc start Spooler. Если все прошло удачно и по команде sc query эти службы отображаются, теперь можно записать их в соотвествующий раздел реестра с помощью команд sc config DcomLaunch start= auto; sc config RpcSs start= auto, sc config Spooler start= auto.

По-прежнему выдает ошибку "Сервер RPC недоступен"? Проверьте наличие файлов Spoolss.exe и Spoolss.dll в директории C:\Windows\SYSTEM32. Воспользуйтесь командой sfc/scannow для проверки системных файлов и замены поврежденных на оригинальные. Ведь могло произойти повреждение файловой системы. Кроме проблем с подсоединением в терминальном режиме по протоколу RDP и печатью, больше характерных для операционных систем предыдущего поколения - Windows 2000/XP/2003/2008, нередко возникают неполадки, выражающиеся в сообщении "Сервер RPC недоступен", связанные с отсутствием звука в Windows 7. Отличие этой операционной системы в том, что служба Windows Audio напрямую сопряжена с сервисом "Питание". Именно поэтому выскакивает ошибка "Сервер RPC недоступен". Windows 7, заметим, обладает значительными отличиями в администрировании системы, более существенными, чем различия, скажем, Windows XP и Winodws 2000. В дополнение рекомендуется проверить наличие файлов Spoolss.exe и Spoolss.dll в директории C:\Windows\SYSTEM32.