How it works troubleshooting rpc errors

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

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

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

RPC - це метод взаємодії між процесами (IPC), який використовується клієнтами і серверами для зв'язку. Простіше кажучи, RPC використовується програмами, зазвичай на клієнтському комп'ютері, для виконання програми на серверному комп'ютері. Наприклад, клієнти Microsoft ® Outlook ® зв'язуються з Microsoft Exchange Server за допомогою RPC. Клієнтський комп'ютер відправляє повідомлення серверу з певними аргументами. Сервер відповідає клієнту повідомленням з результатами виконаної програми.

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

Іншим важливим компонентом RPC є служба локатора. Вона підтримує список серверів і служб RPC в мережі. Клієнт Windows ® підключається до контролера домену через порти протоколу SMB (TCP 139 і 445) і виконує пошук серверів або служб RPC за допомогою служби локатора.

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

Тепер розглянемо деякі з помилок, які можуть статися при збої служби RPC. (Це ні в якому разі не вичерпний список.)

При збої служби реплікації файлів може виникнути жахлива помилка «RPC Unavailable». При підключенні диска може з'явитися помилка "Немає доступу». При використанні оснащення «Active Directory - користувачі і комп'ютери» може з'явитися помилка «Зазначений домен не існує або з ним неможливо зв'язатися». При вході в домен може з'явитися помилка «The system can not 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, можна використовувати кілька інструментів для діагностики проблем.

Можна використовувати засіб 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.

Дозвіл помилок RPC

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

Клієнти Microsoft підключаються до системи відображення кінцевих точок RPC через порт 135. Потім система відображення кінцевих точок повідомляє клієнту порт, прослуховується запитаної службою. Номери портів призначаються динамічно і можуть перебувати в діапазоні від 1024 до 65 535. Поява помилок, таких як тисячі сімсот п'ятьдесят три, означає, що для системи відображення кінцевих точок не доступно жодних певних кінцеві точки, що свідчить про те, що система відображення кінцевих точок RPC не змогла використати для служб порт з номером більше 1024. Я більш докладніше розгляну це пізніше.

Перш за все необхідно перевірити стан служби RPC на сервері. Залежно від типу ролі сервера служба RPC і служба локатора RPC повинні мати стан, вказане на рис. 2. Якщо одна з двох служб не налаштована так, як показано на малюнку, спробуйте налаштувати стан, перезавантажте сервер і перевірте наявність проблеми.

Figure 2 Стан служби RPC

Мал. 4 Перераховані в реєстрі протоколи ClientProtocols RPC

Якщо будь-які записи відсутні, додайте новий строковий параметр з ім'ям і типом, показаними на рис. 4. За замовчуванням існує п'ята запис з ім'ям ncacn_nb_tcp, яка використовується для визначення NetBIOS через TCP як сімейства протоколів для кінцевої точки. Залежно від настройки цей запис серед протоколів ClientProtocol може бути відсутнім, в цьому випадку її можна додати вручну і подивитися, чи допоможе це розв'язання проблем з RPC.

Зверніть увагу на параметри в папці Rpc в лівій панелі малюнка, а саме ClientProtocols, NameService, NetBios і SecurityService. Якщо присутній параметр Internet без значення, видаліть його і перезавантажте комп'ютер. Це може вирішити проблему. Як завжди, необхідно бути обережним при зміні реєстру Windows.

Як згадувалося раніше, RPC може використовувати порти від 1024 до 65 535, тому необхідно переконатися, що ці порти не заблоковані брандмауером. Найпростішим способом визначення того, що порт відкритий, є використання засобу Port Query. Існує дві версії цього засобу: версія для командного рядка (PortQry) і версія з графічним інтерфейсом (PortQueryUI).

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

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

Останній рядок показує, що порт 135 відкритий. В іншому випадку в останньому рядку містилося б NOT LISTENING.

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

Якщо ви використовували всі зазначені прийоми, але проблему вирішити не вдається, існує кілька додаткових рішень. Залежно від певних проблем у вашому середовищі ви можете виконати одну з наступних змін реєстру. (Почекайте. Перед зміною реєстру необхідно зробити резервну копію системи, особливо реєстру, щоб в разі збою можна було відновити попередній стан комп'ютера.)

Мал. 5 Параметр MaxUserPort в реєстрі

Крім того, можна змінити значення TcpMaxDataRetransmissions. Для пакетів TCP необхідно підтвердження приймаючої сторони. При відсутності підтвердження до закінчення часу передача пакетів повторюється кількість разів, певне параметром TcpMaxDataRetransmissions. Значення цього параметра за замовчуванням - 5, але ви можете змінити значення на 4 або навіть 3. Але не можна використовувати значення менше 3.

Якщо параметр реєстру TcpMaxDataRetransmissions не існує, його можна додати в наступне місце реєстру:

Параметр TcpTimedWaitDelay додається в наступне місце розташування в реєстрі:

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

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

Figure 6 Засоби усунення неполадок RPC

Аналіз стану контролерів домену.

Відображення зареєстрованих подій.

Визначення вірності і узгодженості політик.

Перевірка працездатності мережі.

Відстеження і запис мережевого трафіку.

Надає засоби керування для Active Directory.

Використовується для перевірки підключення TCP / IP.

Діагностика проблем реплікації контролерів домену Windows.

Зазвичай використовується разом з мережевим монітором.

Використовується для підтвердження підключення RPC.