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

Ця документація переміщена до архіву і не підтримується.

Принцип роботи Виправлення помилок віддаленого виклику процедур

Зубаїр Олександр

Якщо ви працювали з серверними платформами 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 – користувачі та комп'ютери» може з'явитися помилка «Вказаний домен не існує або з ним неможливо зв'язатися». При вході в домен може з'явитися помилка "Система може не отримувати log you on to 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 - Directory Service впевнений, що повертається партія 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 Помічено, щоб install the directory service (1722)

Зверніть увагу на код помилки 1722, який чотири рази зустрічається у цьому повідомленні та позначає недоступність сервера RPC. на Мал. 1наведено деякі коди помилок та їх описи, але багато інших кодів помилок наведено на веб-сайті msdn2.microsoft.com/ms681386 .

Figure 1 Коди помилок та їх описи

Вирішення помилок RPC

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

Клієнти Microsoft підключаються до системи відображення кінцевих точок RPC через порт 135. Потім система відображення кінцевих точок повідомляє клієнту порт, який прослуховує запитана служба. Номери портів призначаються динамічно і можуть знаходитися в діапазоні від 1024 до 65535. Поява помилок, таких як 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 з 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 до 65535, тому необхідно переконатися, що ці порти не заблоковані брандмауером. Найпростішим способом визначення того, що порт відкритий, є використання засобу 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 (Зміна тайм-ауту максимальної кількості повторних передач TCP/IP) бази знань Майкрософт.

Інше значення, яке можна спробувати змінити – TcpTimedWaitDelay. Якщо клієнт використовує велику кількість портів, порти можуть закінчитися, перш ніж TCP/IP звільнить закриті підключення. Це відбувається через те, що TCP/IP не звільняє підключення до закінчення двох максимальних термінів життя сегментів (MSL) (це називається станом часу очікування). Більше того, оскільки кожен MSL визначено як 120 секунд, TCP/IP не звільняє підключення до закінчення двох MSL; звільнення TCP/IP закритого підключення займає 240 секунд (4 хвилини). Це було відомою проблемою Windows NT®, яка була виправлена ​​в пакеті оновлень; внаслідок поява цієї проблеми сьогодні малоймовірна. Однак корпорація Майкрософт рекомендує змінити цей параметр як одне з можливих рішень для вирішення помилок системи відображення кінцевих точок RPC, як було пояснено в статті бази знань Майкрософт.

Помилки RPC можуть бути вихідною причиною різних помилок зв'язку в мережі. На щастя, є кілька винахідливих способів усунення цих важких проблем. Деякі запропоновані засоби є вбудованими, інші є в комплекті Windows Server Resource Kit. Багато з них наведено на Мал. 6. Ці засоби можна використовувати для визначення причини та розташування помилок RPC і подальшого використання одного з описаних у цій статті методу для усунення помилок.

Figure 6 Засоби усунення несправностей 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 як зображено нижче. Ви потрапите до панелі керування службами комп'ютера.

Тут перейдіть до властивостей перелічених вище служб, де ви зможете провести зміну їхніх параметрів.

Виконайте перезавантаження комп'ютера після виконання дій.

Поява помилки "сервер 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 року продовжує з'являтися, можна спробувати інший спосіб. Для цього, як і в попередній методиці, слід перейти до служб операційної системи.

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

У меню, що відкрилося, потрібно перевірити роботу служб «Харчування», «Сервер», «Віддалений реєстр»і «Видалений виклик процедур». Ті, які не працюють, потрібно включити. Після цього комп'ютер перезавантажується, що зазвичай призводить до зникнення помилки. Хоча для гарантії працездатності аудіо та всієї системи загалом можна додатково запустити.

Доброго дня шановні читачі та передплатники, минулого разу ми з вами усували проблему в 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 недоступний. Порти я перевірив, що вони слухалися. Хто не знає як перевірити, то ось вам команда telnet на допомогу.

Наступним кроком йде перевірка DNS серверів, в налаштуваннях стека TCP/IP. Якщо у вас більше одного контролера домену, то у вас першим dns сервером в налаштуваннях мережного інтерфейсу повинен йти dns іншого контролера домену, потім або адресу поточного або петлевого IP, а вже потім будь-які, що вам потрібні.

Так що правильний порядок DNS серверів, це 90 відсотків випадків

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

Ось так просто вирішується помилка 1722 сервер RPC не доступний на контролері домену по Windows Server 2012 R2. Якщо у вас є чим доповнити статтю, прохання написати це в коментарях.