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

Появление ошибки «сервер RPC недоступен» показывает нарушение работоспособности системы .

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

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

Принцип действия RPC

Проблемы с сервисом RPC являются одной из наиболее распространённых проблем операционной системы любого поколения, начиная с 2000-й версии. Сама же служба, название которой расшифровывается как «вызов удалённых процедур», представляет собой технологию, позволяющую приложениям выполнять определённые действия в других адресных пространствах – например, на других компьютерах или устройствах.

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

Отличия разных версий сервиса заключаются в используемых для их работы технологиях. В некоторых используется сервис-ориентированная архитектура SOA, в других – расширение DCOM, в третьих – спецификация CORBA. При этом основными протоколами являются UDP и TCP.

Достаточно редко применяется технология HTTP, не всегда совместимая с архитектурой /OSI. Если же работа RPC нарушена, обмен данными нарушается, система теряет связь с удалёнными объектами, и некоторые её функции перестают выполняться.

Принцип действия RPC

Причины появления ошибки сервер RPC недоступен

Сообщение о недоступности сервера RPC может появляться при попытке установить или , МФУ, звуковых карт и . Иногда подобная ситуация возникает при неудачной попытке доступа к удалённым серверам, при сетевой печати и даже во время входа пользователя в систему.

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

Сообщение о проблемах с сервером RCP.

Поиск причины неполадки и её исправление

Первым способом, которым стоит воспользоваться для определения причин появления сообщения об ошибке, является проверка логов событий, которые хранятся в системных папках Windows. Для этого следует:

1. Перейти в меню «Пуск» ;
2. Выбрать «Панель управления» ;
3. Найти вкладку администрирования и перейти к просмотру событий;

Просмотр логов для определения причины неполадок.

1. Найти в журнале соответствующую ошибку (если выполнить эти действия сразу же после появления сообщения о проблемах с RPC, событие будет верхним в списке);
2. Найти в сети описание проблемы по коду ошибки.

Если таким способом найти неполадку не удалось, стоит попробовать избавиться от неё, проверив систему антивирусом. Например, Dr.Web Curelt или другими . Ведь иногда причинами появления сообщения являются результаты работы вредоносного кода Conficker – «червя», использующего уязвимости сервиса RPC.

Совет: если в процессе проверки вирусы всё-таки были обнаружены, антивирусную программу стоит заменить. Так как при использовании старого антивируса ошибка с RPC, причиной которой стал вредоносный код, может появиться снова.

Отключение работы брандмауэра и установка обновлений для системы.

Ещё один сравнительно несложный способ решения проблемы – восстановление работоспособности ветки реестра под названием SYSTEM. Для этого можно воспользоваться двумя способами:

1. Перейти по адресу Windows \System32 \Config и войти в директорию сохранённых ранее вариантов – RegBack. Отсюда следует скопировать файл System и поместить его в папку Config. Методика помогает только, если причиной ошибки был вирус, который заразил систему уже после того как было сделано последнее сохранение раздела;

Восстановление реестра Windows 7.

2. С помощью консоли восстановления, которая обычно есть в составе дистрибутива системы. Для есть возможность восстановить реестр с помощью меню дополнительных параметров. Хотя при этом теряется информация об устройствах, и всё оборудование придётся устанавливать заново.

Восстановление реестра системы с помощью точек восстановления.

Дополнительный способ – проверка работы некоторых служб. Для неё необходимо:

1. Перейти в меню «Пуск» ;
2. Запустить командную строку от имени администратора системы;
3. Проверить, запущены ли службы под названием DcomLaunch, RpcSS и Spooler (если они работают, значение состояния равно Running);
4. Записать эти службы в реестр с помощью команд sc config «название службы» start= auto.

Проверка работы служб с помощью командной строки.

Если ни одна из этих методик не помогла, можно проверить наличие в папке System32 (в директории Windows на системном диске) файлов Spoolss.dll и Spoolss.exe. С помощью запуска команды sfc/scannow их можно не только найти, но и восстановить предыдущие версии.

Исправление проблем со звуком

В Виндовс 7, 8 и 10 причиной появления сообщения (ошибка 1722 ) могут быть , вызванные непосредственной связью параметров службы Windows Audio с сервисом питания. Восстановить работоспособность сравнительно несложно. Для этого переходят в меню Служб системы («Пуск» \ «Панель управления» \ «Администрирование» \ «Службы» ) и запускают средство построения конечных точек сервиса.

О том как решить другие проблемы со звуком читайте в наших материалах:

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

РПроверка работы служб.

В открывшемся меню требуется проверить работу служб «Питание» , «Сервер» , «Удалённый реестр» и «Удалённый вызов процедур» . Те из них, которые не работают, требуется включить. После этого компьютер перезагружается, что, как правило, приводит к исчезновению ошибки. Хотя для гарантии работоспособности аудио и всей системы в целом можно дополнительно запустить .

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

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

Показ:

Добрый день уважаемые читатели и подписчики, в прошлый раз мы с вами устраняли проблему в 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. Если у вас есть чем дополнить статью, то просьба написать это в комментариях.