How IT Works Problembehandlung bei RPC-Fehlern

Zubair Alexander

Wenn Sie in den letzten Jahren mit Windows-Serverplattformen gearbeitet haben, sind Sie wahrscheinlich hin und wieder auf RPC-Fehler (Remote Procedure Call, Remoteprozeduraufruf) gestoßen. Sie erhalten die Nachricht, dass der RPC-Server nicht verfügbar ist oder keine Endpunkte mehr verfügbar sind, oder eine andere merkwürdige Warnung. Wenn derartige Nachrichten für Sie verwirrend sind, sollten Sie weiterlesen. Im Folgenden werden

einige häufige Fehler sowie verschiedene Verfahren zum Identifizieren angezeigter RPC-Fehler aufgezeigt sowie Lösungen für bestimmte Probleme erörtert. Doch bevor ich auf bestimmte RPC-Fehler und -Lösungen eingehe, sollen Ihnen die Grundlagen der RPC-Terminologie vermittelt werden.

Was ist RPC?

RPC ist eine Methode für die Kommunikation zwischen Prozessen (Interprocess Communication, IPC), die von Clients und Servern zur Kommunikation untereinander verwendet wird. Einfach ausgedrückt, wird RPC von Programmen (normalerweise auf einem Clientcomputer) verwendet, um ein Programm auf einem Servercomputer auszuführen. Microsoft® Outlook®-Clients beispielsweise kommunizieren mit Microsoft Exchange Server mithilfe von RPC. Der Clientcomputer sendet eine Nachricht mit bestimmten Argumenten an den Servercomputer. Der Server antwortet dem Client mit einer Nachricht, die die Ergebnisse des ausgeführten Programms enthält.

Wesentlich für diesen Prozess ist der Endpunkt – der Name, Port oder die Gruppe von Ports auf einem Computer, die von einem Server auf eingehende Clientanforderungen überwacht wird. Genauer gesagt ist es die netzwerkspezifische Adresse eines Serverprozesses, die für RPCs verwendet wird.

Die Endpunktzuordnung als Teil des RPC-Subsystems ist dafür verantwortlich, auf die Anforderungen der Clients zu antworten, um dynamische Endpunkte aufzulösen. In manchen Situationen ist die Endpunktzuordnung auch für die dynamische Zuweisung von Endpunkten zu Servern verantwortlich.

Eine weitere wichtige RPC-Komponente ist der Locatordienst. Er verwaltet eine Liste von RPC-Diensten und Servern auf dem Netzwerk. Ein Windows®-Client stellt eine Verbindung zum Domänencontroller über die SMB-Ports (Server Message Block) (TCP 139 und 445) her und sucht über den Locatordienst nach RPC-Diensten oder Servern.

Die meisten integrierten Windows-Dienste kommunizieren mithilfe von RPC miteinander. Zertifikatsdienste, DCOM, FRS, MSMQ, MAPI und Active Directory® Replication Service beispielsweise verwenden RPC für die Kommunikation. Wenn daher der RPC-Dienst in einem Netzwerk nicht richtig funktioniert, kann es zu einer Reihe von Kommunikationsproblemen kommen.

RPC-Fehler

Hier werden einige Fehler näher beleuchtet, die auftreten können, wenn der RPC-Dienst versagt. (Dies ist keinesfalls eine vollständige Liste.)

Wenn der Dateireplikationsdienst (File Replication Service, FRS) versagt, könnte der gefürchtete Fehler „RPC nicht verfügbar“ am Werk sein. Wenn Sie versuchen, ein Laufwerk zuzuordnen, könnte der Fehler „Zugriff verweigert“ auftreten. Bei der Verwendung von Active Directory-Benutzer und -Computer könnte folgende Fehlermeldung angezeigt werden: „Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung mit ihr hergestellt werden.“ Beim Anmelden bei der Domäne könnte folgender Fehler auftreten: „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“ (Das System kann Sie an diese Domäne nicht anmelden, da das primäre Domänencomputerkonto des Systems fehlt oder das Kennwort für dieses Konto ungültig ist).

Wenn der Microsoft Outlook-Client versucht, mit Exchange Server zu kommunizieren, können RPC-Fehler dem Client eine irreführende Fehlernachricht angeben wie: „Your logon information is incorrect“ (Die Anmeldeinformationen sind ungültig) oder „Outlook could not log on“ (Outlook konnte sich nicht anmelden).

Neben diesen Fehlern kann es zu anderen Problemen kommen, wenn der RPC-Dienst nicht verfügbar ist. Sie können möglicherweise die Domäne in „Netzwerkumgebung“ nicht besuchen oder das Gruppenrichtlinien-Snap-In nicht öffnen.

Dies sind nur einige Situationen, in denen RPCs unerwartete Probleme verursachen. Es gibt noch viele weitere Beispiele, und jedes Mal, wenn Sie an Remoteprozessen beteiligt sind, sind RPC-Probleme möglicherweise die Hauptursache für auftretende Schwierigkeiten. Doch wie können Sie das genau feststellen, und, was noch wichtiger ist, wie können Sie den entsprechenden Fehler aufspüren? Genau darum geht es hier.

Problembehandlung

Wenn Sie vermuten, dass Sie Probleme mit dem RPC-Dienst haben, gibt es mehrere Tools für Diagnosezwecke.

Eins davon ist das Repadmin-Tool. Dieses Programm wird normalerweise zum Überwachen und zur Problembehandlung von Active Directory-Replikationsproblemen verwendet, doch Sie können mit seiner Hilfe auch Probleme mit der RPC-Endpunktzuordnung behandeln. Zum Ausführen des Tools geben Sie in der Eingabeaufforderung repadmin /bind ein. Bei RPC-Problemen könnten Sie etwa folgende Nachricht sehen: „In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar.“ Das ist ein erster Anhaltspunkt, dass das Problem mit RPC im Zusammenhang steht.

Eine weitere Option ist die Verwendung des Diagnosetools Domain Controller (DCDiag), eines Befehlszeilenprogramms zum Diagnostizieren von Problemen mit Domänencontrollern. Wenn Sie folgenden Fehler sehen: „Status ist 1722: Der RPC-Server ist nicht verfügbar“, wissen Sie, dass ein RPC-Problem vorliegt, das vom Domain Controller-Diagnosetool aufgedeckt wurde.

Bei der Verwendung von Ntdsutil (ein Befehlszeilenprogramm zum Verwalten von Active Directory und Durchführen zahlreicher Wartungsaufgaben) könnte es bei einem Verbindungsversuch mit dem Server zu RPC-Fehlern kommen. Wahrscheinlich wird einer der häufigeren Fehler angezeigt, z. B.: „In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar.“ Wieder ist dies ein Anhaltspunkt, dass es sich um Probleme mit dem RPC-Dienst handeln könnte. Das Gpotool-Tool, das die Konsistenz von Gruppenrichtlinienobjekten auf Domänencontrollern prüft, zeigt ähnliche Fehler an, wenn Schwierigkeiten mit RPC auftreten.

Das Dcpromo.log, das generiert wird, wenn Sie einen Windows 2000 Server- oder Windows Server® 2003-Server mithilfe des Dcpromo-Tools zu einem Domänencontroller hochstufen, kann ebenfalls Probleme mit RPC offen legen. Wenn die Hochstufung fehlschlägt, sollten Sie sich das Protokoll ansehen. Es befindet sich im Ordner %windir%\debug. Die aufgeführten Fehler zeigen beispielsweise an, dass der Verzeichnisdienst die Partition nicht repliziert oder das Objekt nicht erstellt hat. Am Ende der Nachricht wird ein Fehlercode angegeben. Hier sehen Sie ein Beispiel für eine Fehlermeldung im Dcpromo.log:

 
08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)

Beachten Sie den Fehlercode 1722, der in dieser Nachricht viermal auftaucht und anzeigt, dass der RPC-Server nicht verfügbar ist. In Abbildung 1 sind einige Fehlercodes und ihre Beschreibungen aufgeführt. Weitere Fehlercodes können Sie hier einsehen: msdn2.microsoft.com/ms681386.

Figure 1 Fehlercodes und ihre Beschreibungen

Beheben von RPC-Fehlern

Sie wissen nun, wie Sie manche RPC Fehler erkennen können. Nachstehend werden Lösungen erörtert.

Microsoft-Clients stellen eine Verbindung zur RPC-Endpunktzuordnung an Port 135 her. Dann teilt die Endpunktzuordnung dem Client mit, an welchem Port ein angeforderter Dienst abfragt. Die Portnummern werden dynamisch zugewiesen und liegen zwischen 1024 und 65.535. Wenn Fehler wie 1753 angezeigt werden, denen zufolge keine Endpunkte mehr von der Endpunktzuordnung zur Verfügung stehen, bedeutet dies, dass die RPC-Endpunktzuordnung für einen Dienst keinen Port verwenden konnte, der größer als 1024 ist. Dieses Thema wird weiter unten eingehender beleuchtet.

Zunächst sollten Sie den Status des RPC-Diensts auf dem Server überprüfen. Abhängig von der Art der Serverrolle sollten der RPC- und RPC-Locatordienst den in Abbildung 2 aufgeführten Status haben. Wenn einer der beiden Dienste nicht wie in der Abbildung dargestellt konfiguriert ist, passen Sie den Status an, starten Sie den Server neu, und testen Sie, ob das Problem auf diese Weise gelöst wird.

Figure 2 Status des RPC-Diensts

Überprüfen Sie, ob Ihr Client erfolgreich eine Pinganforderung an den Server senden kann, der Konnektivitätsprobleme hat. Wenn Sie beispielsweise Schwierigkeiten haben, mit einem Server mit der Bezeichnung DC1 zu kommunizieren, dessen IP-Adresse 192.168.1.200 ist, verwenden Sie folgenden Befehl in der Eingabeaufforderung, um zu überprüfen, ob DNS den Host DC1 richtig auflöst:

Ping –a 192.168.1.200

Stellen Sie sicher, dass Sie den –a-Schalter mit der IP-Adresse und nicht den Hostnamen verwenden.

Wenn alles richtig funktioniert, sollten Sie eine Antwort von DC1 erhalten, die etwa wie die Pingantwort in Abbildung 3 aussieht. Beachten Sie, dass anstelle einer einfachen Auflösung der IP-Adresse 192.168.1.200 die Pinganforderung auch den Hostnamen dc1.contoso.com aufgelöst hat. Hierdurch wird bestätigt, dass die DNS-Namensauflösung richtig funktioniert und den Hostnamen dc1.contoso.com wie erwartet auflöst.

Figure 3 Pingantwort

C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] 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

Sie sollten außerdem sicherstellen, dass die Registrierung auf dem Windows XP- oder Windows 2000-Client mindestens die vier im rechten Bereich in Abbildung 4 aufgeführten ClientProtocols enthält.

Abbildung 4 In der Registrierung aufgeführte RPC-ClientProtocols

Wenn Einträge fehlen, fügen Sie einen neuen Zeichenfolgenwert mit dem in Abbildung 4 dargestellten Namen und Datentyp hinzu. Standardmäßig gibt es einen fünften Eintrag namens „ncacn_nb_tcp“, der zum Identifizieren von NetBIOS über TCP als Protokollfamilie für den Endpunkt dient. Abhängig von Ihrer Konfiguration wird dieser Eintrag möglicherweise nicht unter ClientProtocols aufgeführt. Fügen Sie ihn in diesem Fall manuell hinzu, um festzustellen, ob die RPC-Fehler dadurch gelöst werden.

Beachten Sie die Schlüssel, die unter dem Rpc-Ordner im linken Bereich in der Abbildung aufgelistet sind, nämlich ClientProtocols, NameService, NetBIOS und SecurityService. Wenn Sie einen Schlüssel namens „Internet“ sehen, der keine Werte hat, versuchen Sie, den Schlüssel zu entfernen und den Computer neu zu starten. Auf diese Weise könnte das Problem behoben werden. Sie sollten jedoch wie immer vorsichtig sein, wenn Sie die Windows-Registrierung ändern.

Wie bereits erwähnt, verwendet RPC Ports zwischen 1024 und 65.535, und Sie müssen sicherstellen, dass diese Ports nicht durch eine Firewall gesperrt sind. Mithilfe des Port Query-Tools lässt sich am einfachsten sicherstellen, dass ein Port offen ist. Dieses Tool liegt in zwei Versionen vor: in einer Befehlszeilenversion (PortQry) und in einer Version mit grafischer Benutzeroberfläche (PortQueryUI).

PortQry kann im Microsoft-Downloadcenter heruntergeladen werden. Zusätzliche Informationen finden Sie im Artikel Beschreibung des Befehlszeilenprogramms Portqry.exe. Dort finden Sie kurze Beschreibungen von PortQry- Statusberichten und Beispiele für Befehle zur Problemlösung. Natürlich können Sie auch die einfacher zu verwendende Version mit der grafischen Benutzeroberfläche einsetzen. Sie finden diesen Download unter go.microsoft.com/fwlink/?LinkId=73740.

Port Query muss auf einem Computer ausgeführt werden, bei dem keine RPC-Fehler vorliegen. Das Tool muss für einen Computer ausgeführt werden, bei dem Probleme mit RPC vorhanden sind. Wenn Sie beispielsweise überprüfen wollen, ob Port 135, der von der RPC-Endpunktzuordnung verwendet wird, offen ist, verwenden Sie PortQry folgendermaßen in der Eingabeaufforderung:

portqry -n [servername] -e 135

Egal, ob Sie PortQuery oder PortQueryUI verwenden, erhalten Sie etwa folgende Ergebnisse:

Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING

Die letzten Zeile zeigt, dass Port 135 offen ist. Andernfalls wird in dieser letzten Zeile NOT LISTENING angegeben.

Um mehrere Ports auf einmal zu prüfen, geben Sie die Portnummern durch Kommas getrennt ein, z. B. „135,1024-5000“.

Zusätzliche Lösungen

Wenn Sie alle bisher aufgeführten Tricks ausprobiert haben und das Problem immer noch nicht behoben ist, stehen Ihnen weitere Optionen offen. Abhängig von den spezifischen Problemen in Ihrer Umgebung könnten Sie eine der folgenden Änderungen an der Registrierung durchführen. (Vorsicht! Bevor Sie Änderungen an der Registrierung vornehmen, müssen Sie unbedingt eine Sicherungskopie Ihres System und speziell von der Registrierung erstellen, damit Sie den ursprünglichen Zustand des Computers wiederherstellen können, falls der Lösungsversuch fehlschlägt.)

Eine Option besteht darin, MaxUserPort so anzupassen, dass von TCP die höchstmögliche Portnummer angegeben wird, wenn eine Anwendung einen verfügbaren Benutzerport vom System anfordert. Standardmäßig stellt Windows Server 2003 den MaxUserPort-Wert auf 5000 ein, d. h. 5000 wird als höchste Portnummer verwendet, selbst wenn der Eintrag nicht existiert. Abhängig von Ihrer Konfiguration ist dieser Eintrag u. U. nicht in der Registrierung vorhanden. In diesem Fall können Sie ihn an der in Abbildung 5 dargestellten Stelle hinzufügen.

Abbildung 5 MaxUserPort-Einstellung in der Registrierung

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000

Beim Ändern der Registrierung müssen Sie sich anderer möglicher Nebeneffekte bewusst sein, was nicht immer einfach ist. Die Änderung dieses Eintrags könnte sich auf Microsoft Exchange Server auswirken, wenn der Wert auf unter 50.000 eingestellt wird. Wenn der Exchange Server Best Practices Analyzer (BPA) feststellt, dass der Wert des MaxUserPort- Registrierungsschlüssels unter 50.000 liegt, wird eine Warnung angezeigt. Microsoft empfiehlt, den Wert auf 60.000 einzustellen. Andernfalls könnten Sie NSPI-Proxywarnungen (Name Service Provider Interface) wie Ereignis 9040 verursachen. Weitere Informationen finden Sie im Microsoft-Dokument MaxUserPort-Wert ist zu niedrig.

Sie können außerdem den Wert für TcpMaxDataRetransmissions einstellen. TCP-Pakete erwarten eine Bestätigung von der Empfangsseite. Wenn keine Bestätigung erfolgt, bevor der Zeitgeber abläuft, werden die Pakete bis zum TcpMaxDataRetransmissions-Wert erneut übertragen. Der Standardwert für diesen Parameter ist 5, doch Sie könnten den Wert 4 oder sogar 3 ausprobieren. Verwenden Sie keinen Wert unter 3.

Wenn der TcpMaxDataRetransmissions-Registrierungseintrag nicht vorhanden ist, können Sie ihn der Registrierung wie unten angegeben an der folgenden Stelle hinzufügen:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5

Weitere Informationen zu TcpMaxDataRetransmissions finden Sie im Microsoft Knowledge Base-Artikel 170359: Ändern des maximalen TCP/IP-Zeitüberschreitungswertes.

Ein weiterer Registrierungswert, mit dem Sie experimentieren könnten, ist TcpTimedWaitDelay. Wenn ein Client zu viele Ports verwendet, ist es durchaus möglich, dass nicht genug Ports vorhanden sind, bevor TCP/IP getrennte Verbindungen freigibt. Der Grund dafür ist, dass TCP/IP die Verbindung erst freigibt, wenn zwei MSLs (Maximum Segment Lives) vergangen sind (dies wird als Wartezeitzustand bezeichnet). Da jedes MSL zudem als 120 Sekunden definiert wird und TCP/IP die Verbindung erst freigibt, wenn zwei MSLs vergangen sind, dauert es bis zu 240 Sekunden (4 Minuten), bis TCP/IP eine getrennte Verbindung freigibt. Dies war ein bekanntes Problem in Windows NT®, das mit einem Service Pack korrigiert wurde. Daher ist das Auftreten dieses Problems heute relativ unwahrscheinlich. Microsoft empfiehlt allerdings das Anpassen dieser Einstellung als eine mögliche Lösung für die Fehler bei der RPC-Endpunktzuordnung, wie im Knowledge Base-Artikel Beheben von Fehlern bei der RPC-Endpunktzuordnung erläutert wird.

TcpTimedWaitDelay wird der Registrierung an folgender Stelle hinzugefügt:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD 
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)

Weitere Informationen zu TcpTimedWaitDelay finden Sie in diesem Knowledge Base-Artikel: Nicht genug Ports für Windows NT-Clients. Obwohl der Artikel keine bestimmten Zahlen empfiehlt, könnten Sie TcpTimedWaitDelay auf 60 (Sekunden) als Dezimalzahl reduzieren, was einem Hexadezimalwert von 3c entspricht.

Schlussbemerkung

RPC-Fehler können die Hauptursache zahlreicher Kommunikationsfehler in Ihrem Netzwerk sein. Glücklicherweise gibt es mehrere kreative Möglichkeiten, um diese schwer fassbaren Probleme zu beheben. Einige der hier vorgeschlagenen Tools sind integriert, während andere im Windows Server Ressource Kit zur Verfügung stehen. Viele sind in Abbildung 6 aufgeführt. Sie können diese Tools einsetzen, um Ursache und Ort von RPC-Fehlern festzustellen, und dann die in diesem Artikel aufgeführten Verfahren zur Fehlerbehebung verwenden.

Figure 6 Tools zur RPC-Problembehandlung

Zubair Alexander, MCSE, MCT und Microsoft MVP, ist Geschäftsinhaber von SeattlePro Enterprises, ein Unternehmen für IT-Schulung und -Beratung. Seine Erfahrung deckt das gesamte Spektrum der IT-Schulung ab: Autor, Hochschullehrer, Berater, Netzwerktechniker, Referent, Sicherheitsarchitekt, Systemadministrator, technischer Redakteur und Ausbilder. Sie können Zubair Alexander unter alexander@techgalaxy.net erreichen.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.