«Сервер RPC недоступен» – причины и способы устранения ошибки

RPC – это способ обмена информацией между процессами или между клиентом (устройством, инициирующем связь RPC) и сервером (устройством, которое с ним связывается) в сети или системе. Многие встроенные компоненты Windows используют RPC, который в качестве отправной точки для связи между системами применяет различные порты. При возникновении неполадок возникает сообщение «Сервер RPC недоступен».

Решение ошибки «Сервер RPC недоступен».

Причины появления ошибки

В типичном сеансе RPC клиент связывается с программой сопоставления конечных точек сервера по TCP-порту 135 и для указанной службы требует определённого номера динамического порта. Сервер отвечает, отправив IP-адрес и номер порта, для которого служба зарегистрирована в RPC после её запуска, а затем связывается с клиентом с указанным IP-адресом и номером порта. Возможные причины ошибки «Сервер RPC недоступен» следующие:

1. Остановка службы RPC – когда служба RPC на сервере не запущена.
2. Проблемы с разрешением имён – имя сервера RPC может быть связано с неправильным IP-адресом. Это значит, что клиент связывается с неправильным сервером или пытается связаться с IP-адресом, который в настоящее время не используется. Возможно, имя сервера не распознаётся вообще.
3. Трафик заблокирован брандмауэром – брандмауэр или другое приложение безопасности на сервере или брандмауэр устройства между клиентом и сервером могут препятствовать доступу трафика к TCP-порту сервера 135.
4. Проблемы с подключением – проблема с сетью может быть причиной отсутствия соединения между клиентом и сервером.

Способы решения

При запуске или установке некоторых программ вы можете получить сообщение «Сервер RPC недоступен». Это часто связано с синхронизацией времени, необходимой для запуска программы. Без этого некоторые приложения могут работать неправильно или не запускаться вообще. Что делать, чтобы сообщение больше не появлялось, рассмотрим далее.

Код ошибки 1722

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

Также ошибка может возникнуть из-за того, что в системе присутствует сам вирус – стоит проверить систему и диск с помощью другой антивирусной программы, чем в настоящее время. Для устранения нажмите Пуск/Настройки/Панель управления. Затем откройте Администрирование/Службы. Появится окно, в котором с правой стороны вы найдете «Сервер». На «Сервере» проверьте, включён ли автоматический тип запуска. Измените параметр при необходимости и перезагрузите компьютер.

Отключение брандмауэра Windows

Если при печати в Windows 7 появляется ошибка «Сервер RPC недоступен», проблема может крыться в брандмауэре. Он отвечает за блокировку доступа к компьютеру во внутренней или внешней сети посторонними лицами или приложениями, что исключает возможность контроля ПК. Ниже приведены некоторые советы, которые позволят вам отключить (в случае, если вы хотите использовать для этого другое приложение) и включить интегрированный брандмауэр Windows. Измените имя компьютера с помощью «Настроек»:

1. Это один из самых простых способов отключения сетевого брандмауэра. Для этого используйте вкладку «Параметры системы».
2. Из списка доступных опций выберите «Сеть и Интернет».
3. Перейдите на вкладку Ethernet и выберите «Брандмауэр Windows» с правой стороны окна.
4. Выберите включение и отключение брандмауэра.
5. В списке доступных операций выберите параметр «Отключить брандмауэр Windows» (не рекомендуется).
6. Нажмите «ОК». Брандмауэр выключен.

Следующий способ – редактор локальной групповой политики (GPO):

1. Нажмите клавиши Win + R и введите «gpedit.msc». Откроется редактор локальной групповой политики.
2. Параметр, ответственный за отключение брандмауэра, расположен по адресу

«Конфигурация компьютера» – «Административные шаблоны» – «Сеть» – «Сетевые подключения» – «Стандартный профиль» – «Брандмауэр Windows: защита всех сетевых подключений».

1. Измените состояние настройки на «ВЫКЛ».
2. После нажатия кнопки «ОК» или «Применить» брандмауэр Windows перестанет работать.

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

• нажмите пуск и введите «regedit», запустите приложение от имени администратора;
• в окне редактора найдите каталог

• найдите параметр EnableFirewall и измените его значение с 1 на 0;
• таким же образом отредактируйте ключ EnableFirewall в следующем каталоге

• и последний каталог с ключом EnableFirewall

Закройте редактор реестра и перезагрузите компьютер. С этого момента брандмауэр Windows отключается. Чтобы снова возобновить брандмауэр с помощью редактора реестра, просто измените указанные выше значения с названием EnableFirewall с 0 на 1, и перезапустите компьютер.

Ручной запуск задачи services.msc

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

• сначала нажмите меню «Пуск» и в строке поиска введите «Выполнить», нажмите «Enter»;
• в следующем окне введите services.msc и подтвердите кнопкой «OK»;
• найдите в списке элемент «Служба времени Windows»;
• дважды щёлкните эту службу. Откроется меню, в котором вы должны нажать кнопку «Выполнить».

С этого момента сообщение «RPC-сервер недоступен» появляться не должно.

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

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

Ошибка в FineReader

Проблема может возникать в Windows 8 и выше и при попытке запуска службы ABBYY FineReader Licensing Service. Для проверки состояния в списке служб (как его найти, описано выше) выберите ABBYY FineReader Licensing Service. В окне свойств убедитесь, что параметр «Тип запуска» установлен на «Автоматический». При необходимости измените его, закройте редактор кнопкой «ОК» и перезагрузите компьютер.

Проверка на вирусы

В Windows XP и выше сообщение о неисправности может быть вызвано наличием вируса. Просканируйте свой ПК с помощью антивирусной программы, следуя указаниям мастера. В Windows 10 можно воспользоваться стандартным «Защитником». Для этого нажмите правой кнопкой мыши на значок «Щит» возле часов и выберите «Открыть». Запустите проверку на вирусы нажатием соответствующей кнопки в окне.

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

Rpc and windows 2003

Общие обсуждения

Имеем контроллер домена Windows 2003 EE En SP2.

После перезагрузки сервера не запускаются следующие службы:

COM+ System Application
DHCP Server
File Replication Service
System Event Notification

При попытке запуска служб появляется сообщение:
Error 1068: The dependency service or group failed to start

При попытке просмотреть dependencies у служб появляется сообщение:
WIN32: The RPC Server is unanavilable

Сама служба RPC запущена и прекрасно себя чувствует.
В остальном сервер визуально работает нормально, только «жалко» службу FRS.

Последними телодвижениями на сервере было устранение давно висящей в воздухе проблемы с COM+
по рецепту в http://forums.microsoft.com/TechNet-RU/ShowPost.aspx?PostID=4223131&SiteID=40&mode=1
(в конце).
После этого сервер нормально проработал но до первой перезагрузки.

Ближайшее что нашел:
http://support.microsoft.com/default.aspx/kb/933994

Пока не пробовали (ждем вечера, на этом сервере просто еще одна задача вертится).
Может еще какие-то мысли есть ?

Rpc and windows 2003

Общие обсуждения

Имеем контроллер домена Windows 2003 EE En SP2.

После перезагрузки сервера не запускаются следующие службы:

COM+ System Application
DHCP Server
File Replication Service
System Event Notification

При попытке запуска служб появляется сообщение:
Error 1068: The dependency service or group failed to start

При попытке просмотреть dependencies у служб появляется сообщение:
WIN32: The RPC Server is unanavilable

Сама служба RPC запущена и прекрасно себя чувствует.
В остальном сервер визуально работает нормально, только «жалко» службу FRS.

Последними телодвижениями на сервере было устранение давно висящей в воздухе проблемы с COM+
по рецепту в http://forums.microsoft.com/TechNet-RU/ShowPost.aspx?PostID=4223131&SiteID=40&mode=1
(в конце).
После этого сервер нормально проработал но до первой перезагрузки.

Ближайшее что нашел:
http://support.microsoft.com/default.aspx/kb/933994

Пока не пробовали (ждем вечера, на этом сервере просто еще одна задача вертится).
Может еще какие-то мысли есть ?

Exchange 2003 SP1 RPC по HTTP

Как использовать управляемую топологию, реализованную в пакете SP1

Пользователи системы Exchange Server 2003 могут устанавливать соединения клиента Microsoft Office Outlook 2003 с сервером Exchange с помощью удаленного вызова процедур интерфейса Messaging API (MAPI), передаваемого по протоколу HTTP (вместо термина Messaging API Remote Procedure Call over HTTP часто употребляется сокращение RPC over HTTP). Когда корпорация Microsoft выпустила в свет Exchange 2003, пользователи восприняли эту возможность с большим энтузиазмом, поскольку теперь они могли устанавливать соединения Outlook и Exchange практически в любых сетях. Но эта функция была наделена довольно слабыми средствами административного управления. Первоначальная настройка конфигурации требовала больших трудозатрат, и при этом администратору непросто было выполнить ее без ошибок; настройку многих разделов реестра приходилось выполнять на proxy-серверах RPC, на контроллерах доменов (domain controller, DC) и на серверах глобальных каталогов (Global Catalog, GC). Более того, со значительными неудобствами были сопряжены и процедуры оперативного администрирования, особенно при добавлении либо удалении серверов Exchange. Сведения об общих требованиях, а также о том, какие разделы реестра необходимо настраивать для использования технологии RPC over HTTP еще до установки Exchange 2003 Service Pack 1, SP1, можно почерпнуть из опубликованной в журнале Windows IT Pro /RE статьи «Удаленный доступ к Exchange 2003 по каналам HTTP», № 7 за 2003 год. О том, как выявлять неполадки в соединениях RPC по HTTP, рассказано в статье «Поиск неисправностей в соединениях RPC по HTTP», № 6 за 2004 год.

Exchange 2003 SP1 позволяет решить эти проблемы. Теперь для реализации технологии RPC по HTTP можно воспользоваться так называемой управляемой топологией RPC over HTTP, а такие оперативные изменения среды, как добавление или удаление серверов, автоматически отражаются в настройках.

Изменения в архитектуре

До выпуска Microsoft пакета Exchange 2003 SP1 под термином «proxy-сервер RPC» было принято понимать сервер Windows Server 2003 с установленными на нем (обычно с помощью оснастки Add/Remove Windows Components, доступной через модуль панели управления Add or Remove Programs) средствами RPC over HTTP. На proxy-сервере RPC не нужно было устанавливать систему Exchange 2003, — как правило, этого и не делали.

Клиент Outlook 2003 устанавливал соединение с proxy-сервером RPC (который часто располагался по другую сторону брандмауэра), а proxy-сервер связывался с контроллером домена или с сервером глобального каталога, выполнял аутентификацию запроса пользователя на установление соединения, а затем выступал в роли посредника при установлении соединения клиента Outlook 2003 с соответствующим сервером почтовых ящиков Exchange 2003, где и выполнялись последующие операции по аутентификации в системе Exchange. Если операции по аутентификации завершались успешно, все последующее взаимодействие между клиентом Outlook и Exchange на протяжении данного сеанса связи осуществлялось через proxy-сервер RPC. Вместе с первоначальным запросом на установление соединения сервер почтовых ящиков Exchange 2003 предоставлял клиенту Outlook 2003 сформированную на базе глобального списка адресов (Global Address List, GAL) ссылку на сервер глобального каталога. Клиент Outlook не мог связываться с сервером глобального каталога напрямую, поэтому соединение от имени данного клиента Outlook устанавливал proxy-сервер RPC, как показано на рис. 1. При работе в таком режиме администратор должен был конкретно задавать те серверы глобальных каталогов, которые proxy-сервер RPC мог использовать для обеспечения доступа к списку GAL по каналам RPC по HTTP. Для этого требовалось открыть реестр proxy-сервера RPC и внести в раздел HKEY_LOCAL_MACHINESOFTWARE MicrosoftRpcRpcProxyValid Ports детали соединений и портов соответствующих серверов глобального каталога. Затем нужно было создать параметр реестра HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesNTDSParametersNSPI Interface Protocol Sequences для серверов глобального каталога и модифицировать его значение так, чтобы обеспечить соединение RPC over HTTP с proxy-сервером RPC.

Администраторам систем Exchange 2003 SP1 с управляемой топологией RPC over HTTP уже не требуется модифицировать эти параметры. Достаточно соблюдения некоторых предварительных условий. Для формирования нужной конфигурации необходимо разместить на внешних серверах Exchange 2003 proxy-компоненты Windows 2003 RPC over HTTP. Тогда изображенный на рис. 1 proxy-сервер RPC, на котором выполняется только система Windows 2003, превращается в сервер, на котором функционируют и Windows 2003, и Exchange2003, как показано на рис. 2.

При использовании управляемой топологии RPC over HTTP раздел ValidPorts внешнего сервера Exchange 2003 (выполняющего функцию proxy-сервера RPC) не содержит каких-либо данных о конфигурации сервера глобального каталога. Когда внешний RPC-proxy-сервер Exchange 2003 от имени клиента Outlook устанавливает соединение с почтовым сервером Exchange 2003, в зависимости от того, какая версия системы Exchange 2003 установлена на почтовом сервере, происходит одно из двух событий.

Вариант первый: если на почтовом сервере выполняется система Exchange 2003 SP1, этот сервер определяет, что соединение с клиентом Outlook строится на основе технологии RPC over HTTP, поскольку запрос на соединение поступает от расположенного на внешнем сервере Microsoft IIS на конечную точку ncacn_http, расположенную на почтовом сервере. В этом случае почтовый сервер не направляет клиента Outlook непосредственно на сервер глобального каталога, а дает ему команду обратиться к размещенному на почтовом сервере proxy-серверу службы каталога Directory Service (DS), который от имени Outlook установит соединение с сервером глобального каталога. Эта новая функция системы Exchange 2003 SP1 изменяет систему приоритетов, в соответствии с которыми серверы глобальных каталогов назначаются клиентам RPC over HTTP.

Вариант второй: если на почтовом сервере работает система Exchange 2003 и модернизация до уровня SP1 пока не производилась, сервер вначале пытается в соответствии с обычной практикой направить клиента Outlook непосредственно на сервер глобального каталога. Клиент Outlook пытается связаться с сервером глобального каталога через размещенный на внешнем сервере Exchange 2003 proxy-сервер RPC, но, поскольку внешний сервер не имеет сведений о конфигурации, которые позволили бы установить соединение RPC over HTTP с каким-либо сервером глобального каталога, попытка установить соединение оказывается неудачной. Клиент Outlook вновь обращается к почтовому серверу с запросом об установлении соединения с сервером глобального каталога, но, поскольку почтовый сервер понимает, что первая попытка не увенчалась успехом, он приводит в действие посреднический механизм DS и обеспечивает доступ к серверу глобального каталога. Итак, оба описанных механизма позволяют получить нужный результат, однако второй механизм предполагает некоторую задержку, связанную с первой попыткой соединения. Поэтому наилучшее решение состоит в том, чтобы модернизировать до уровня SP1 сервер Exchange 2003, внешний сервер, почтовый сервер и внутренний сервер.

Управляемая топология RPC over HTTP

Обязательным условием использования реализованных в пакете SP1 обновлений средств автоматической настройки соединений по каналам RPC over HTTP является установка SP1 на внешнем сервере Exchange 2003. Запускать SP1 на почтовом сервере или на внутреннем сервере необязательно (однако не забывайте о том, что при использовании внутренних систем, не модернизированных до уровня SP1, после неудачной первой попытки установить соединение приводятся в действие посреднические механизмы).

На экране 1 показана новая закладка RPC-HTTP. Чтобы перейти на эту закладку из диалогового окна Properties сервера Exchange, нужно воспользоваться программой Exchange System Manager (ESM), установленной на сервере или рабочей станции Exchange 2003 SP1, где имеются средства административного управления Exchange2003 SP1.

Экран 1. Настройка свойств RPC over http

На первом этапе процедуры настройки нужно отметить все внутренние серверы организации, которые предстоит включить в управляемую топологию RPC over HTTP, и выбрать для каждого из этих серверов свойство RPC-HTTP back-end server. При этом нужно устанавливать в 0x20000000 атрибут Heuristics соответствующего почтового сервера Exchange 2003 в каталоге Active Directory (AD). Кроме того, нужно будет установить значение атрибута ServerRole почтового сервера равным 0, поскольку это внутренний сервер. Данную операцию необходимо выполнить для каждого почтового сервера, который вы хотите включить в управляемую топологию RPC over HTTP.

После настройки всех внутренних серверов можно переходить к внешним серверам, которые будут включены в управляемую топологию RPC over HTTP. Для выбора сервера, который решено использовать в качестве внешнего сервера Exchange и на который будет возложена функция посредника RPC, следует использовать диспетчер ESM. На этом сервере должна быть установлена система Exchange 2003 SP1 и он должен быть предварительно настроен как обычный внешний сервер; в противном случае вариант настройки в качестве внешнего сервера на закладке RPC-HTTP будет недоступным, как показано на экране 1. На закладке RPC-HTTP нужно выставить флажок RPC-HTTP front-end server и повторить эти действия для всех внешних серверов, которые будут использоваться в качестве proxy-серверов RPC. При выполнении перечисленных операций в атрибут Heuristics внешнего сервера будут внесены те же изменения, но атрибут ServerRole внешнего сервера будет иметь значение, равное 1.

После установки на внешних и внутренних серверах соответствующих атрибутов AD подготовка управляемой топологии RPC over HTTP, в сущности, завершена. Система Exchange 2003 SP1 включает в себя обновленную функцию System Attendant. Раз в 15 минут эта функция проверяет каталог AD на внешних серверах Exchange 2003, входящих в управляемую топологию RPC over HTTP, с тем чтобы обнаружить внутренние серверы со значением атрибута Heuristics, обеспечивающим их включение в управляемую топологию. На внешнем сервере функция System Attendant обновляет раздел ValidPorts для каждого обнаруженного ею внутреннего сервера, который является частью топологии. Изящество этого подхода становится очевидным при добавлении в среду новых внутренних серверов Exchange 2003. Как только вы выставите соответствующий флажок, указывающий на то, что данный сервер включается в управляемую топологию RPC over HTTP, внешние серверы автоматически обнаруживают этот внутренний сервер и обновляют конфигурацию. Подобным же образом, если подключать к сети новые внешние серверы и указывать в настройках, что они входят в структуру управляемой топологии, эти машины автоматически выявляют все входящие в данную структуру внутренние серверы.

Модернизация существующей конфигурации

Если вы уже пользуетесь средствами RPC over HTTP системы Exchange 2003 и при этом один из внешних серверов Exchange 2003 наделен функциями proxy-сервера RPC, после обновления внешних или внутренних серверов до уровня SP1 ваша конфигурация не изменится. Управляемая топология RPC over HTTP начинает функционировать лишь тогда, когда администратор выбирает и настраивает серверы с помощью свойств RPC-HTTP, как показано на экране 1.

Чтобы задействовать управляемую топологию RPC over HTTP, сначала нужно настроить все внутренние серверы и дождаться, пока атрибуты AD Heuristics будут растиражированы. В зависимости от сложности и топологии среды AD этот процесс может занять от 15 минут до нескольких часов. Но как бы то ни было, к настройке внешних серверов Exchange 2003 SP1, которые решено наделить функциями внешних серверов RPC over HTTP, можно приступать лишь после того, как репликация изменений будет завершена. При изменении настроек все существующие параметры, которые вы, возможно, вручную ввели в разделе ValidPorts внешнего сервера, будут заменены автоматически определяемыми значениями. При этом исходное состояние ValidPorts будет записано в файл, размещенный в каталоге system32 на системном накопителе внешнего сервера, а вы увидите сообщение, показанное на экране 2.

Экран 2. Извещение от ESM об уже проведенной настройке RPC over HTTP

Операции по подготовке управляемой топологии RPC over HTTP нужно выполнять в определенном порядке: сначала следует настроить внутренние серверы, затем дождаться завершения тиражирования данных службой AD и только после этого приступать к настройке внешних серверов. При несоблюдении указанной последовательности действий может возникнуть такая ситуация: внешние серверы будут искать в каталоге AD внутренние серверы, а когда убедятся, что их там нет, в разделе ValidPorts будет прописан параметр со значением «null», что приведет к сбою в работе службы. Более того, если вы решите вручную изменить раздел ValidPorts на включенном в структуру управляемой топологии внешнем сервере, имейте в виду, что эти изменения будут действительны в среднем в течение 7,5 минуты; в ходе следующей проверки внешних серверов функцией System Attendant взамен внесенных значений будут введены новые.

Автоматизация процедуры настройки

Если вы еще не провели модернизацию системы до уровня SP1 и при этом располагаете полнофункциональной средой RPC over HTTP, то у вас есть возможность частично автоматизировать настройку управляемой топологии RPC over HTTP. Эта возможность особенно порадует тех администраторов, которым приходится обслуживать множество внутренних серверов Exchange 2003 и которых не вдохновляет перспектива подключать их к структуре управляемой топологии один за другим. Можно написать собственный сценарий и с его помощью сформировать соответствующую битовую маску для атрибута Heuristics, а затем просто подключить внешние серверы, которые обнаружат только что настроенные внутренние серверы.

Есть и другая возможность: загрузить сценарий Microsoft Exchange2003 SP1 RPC-HTTP Topology Manager, опубликованный по адресу http://www.gotdotnet.com/community/ workspaces/workspace.aspx?id=4a0c34b7-d3dd- 478991b7-6880ecc5f910. Этот сценарий выполняется в трех режимах.

В режиме Registry считывает существующие внутренние серверы, уже указанные в разделе ValidPorts внешнего сервера, и устанавливает значение атрибута Heuristics внутренних серверов таким образом, чтобы их можно было немедленно обнаружить при активизации внешних серверов.

В режиме Server List считывает подготовленный пользователем текстовый файл и определяет, какие серверы следует добавить или удалить из структуры управляемой топологии RPC over HTTP.

В режиме Scan выявляет в каталоге AD все внешние и внутренние серверы, атрибуты Heuristics которых настроены в соответствии с требованиями управляемой топологии RPC over HTTP.

Безусловно, реализованный в пакете Exchange 2003 набор функций RPC over HTTP представляет собой замечательное нововведение. Благодаря усовершенствованиям, внесенным в управляемую топологию RPC over http разработчиками пакета обновлений SP1, сегодня администраторы имеют больше оснований для применения данной технологии доступа, чем когда-либо прежде. Это решение не связано с большими затратами; в худшем случае, если у вас еще нет подходящих внешних серверов Exchange 2003, вам придется приобрести дополнительные аппаратные компоненты и лицензии. Если вы откладывали развертывание технологии RPC over HTTP в ожидании, когда специалисты Microsoft исправят ошибки в коде и доработают свой продукт, знайте, что это время настало.

Главный консультант подразделения HP Advanced Technology Group в Ирландии. kieran. mccorry@hp.com

Поделитесь материалом с коллегами и друзьями