Leitfaden zur Problembehandlung bei Rpc-Fehlern (Remote Procedure Call, Remoteprozeduraufruf)

Gilt für: Windows-Client

Möglicherweise tritt der Fehler "RPC-Server nicht verfügbar" auf, wenn Sie eine Verbindung mit der Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) oder Microsoft SQL Server herstellen, während einer RPC-Sitzung (Remote Procedure Call) oder wenn Sie verschiedene MmC-Snap-Ins (Microsoft Management Console) verwenden. Die folgende Abbildung zeigt ein Beispiel für einen RPC-Fehler.

Dies ist ein häufiger Netzwerkfehler, der einige grundlegende Kenntnisse mit dem Prozess erfordert, um eine erfolgreiche Problembehandlung zu ermöglichen. Zunächst sind einige wichtige Begriffe zu verstehen:

• Endpunktzuordnung (Endpoint Mapper, EPM): Ein Dienst, der auf dem Server lauscht und Client-Apps mithilfe von Port- und UUID-Informationen zu Server-Apps leitet.
• Tower: Beschreibt das RPC-Protokoll, mit dem Client und Server eine Verbindung aushandeln können.
• Etagen: Die Inhaltsschichten in einem Tower, die bestimmte Daten enthalten, z. B. Ports, IP-Adressen und Bezeichner.
• UUID: Eine bekannte GUID, die eine RPC-Anwendung identifiziert. Während der Problembehandlung können Sie die UUID verwenden, um die RPC-Unterhaltungen eines einzelnen Anwendungstyps nachzuverfolgen (unter den vielen Typen, die gleichzeitig auf einem einzelnen Computer auftreten).
• Opnum: Identifiziert eine Funktion, die der Client vom Server ausführen soll. Dies ist einfach eine hexadezimale Zahl. Ein gutes Netzwerkanalysetool übersetzt die Funktion jedoch für Sie. Wenn die Funktion nicht identifiziert werden kann, wenden Sie sich an den Anbieter Ihrer Anwendung.
• Port: Der Kommunikationsendpunkt für die Client- oder Serveranwendung. Der EPM weist dynamische Ports (auch als hohe Ports oder kurzlebige Ports bezeichnet) für Clients und Server zu, die verwendet werden können.

  Hinweis

  In der Regel ist die Portnummer die wichtigsten Informationen, die Sie für die Problembehandlung verwenden.

• Stubdaten: Die Daten, die zwischen den Funktionen auf dem Client und den Funktionen auf dem Server ausgetauscht werden. Diese Daten sind die Nutzlast, der wichtige Teil der Kommunikation.

Funktionsweise der Verbindung

Das folgende Diagramm zeigt einen Client, der eine Verbindung mit einem Server herstellt, um einen Remotevorgang auszuführen. Der Client kontaktiert zunächst TCP-Port 135 auf dem Server und verhandelt dann mit EPM um eine dynamische Portnummer. Nachdem EPM einen Port zugewiesen hat, trennt der Client die Verbindung und verwendet dann den dynamischen Port, um eine Verbindung mit dem Server herzustellen.

Wichtig

Wenn eine Firewall den Client und den Server trennt, muss die Firewall die Kommunikation an Port 135 und an den dynamischen Ports zulassen, die EPM zuweist. Ein Ansatz zum Verwalten dieses Szenarios besteht darin, Ports oder Portsbereiche anzugeben, die von EPM verwendet werden sollen. Weitere Informationen finden Sie unter Konfigurieren der Zuweisung dynamischer Ports durch RPC.

Einige Firewalls ermöglichen auch die UUID-Filterung. Wenn in diesem Szenario eine RPC-Anforderung Port 135 verwendet, um die Firewall zu durchqueren und EPM zu kontaktieren, notiert die Firewall die UUID, die der Anforderung zugeordnet ist. Wenn EPM antwortet und eine dynamische Portnummer für diese UUID sendet, notiert die Firewall auch die Portnummer. Die Firewall lässt dann RPC-Bindungsvorgänge für diese UUID und diesen Port zu.

Konfigurieren der Zuweisung dynamischer Ports durch RPC

Standardmäßig ordnet EPM dynamische Ports nach dem Zufallsprinzip aus dem Bereich zu, der für TCP und UDP konfiguriert ist (basierend auf der Implementierung des verwendeten Betriebssystems). Dieser Ansatz ist jedoch möglicherweise nicht praktikabel, insbesondere wenn Client und Server über eine Firewall kommunizieren müssen. Eine alternative Methode besteht darin, eine Portnummer oder einen Bereich von Portnummern anzugeben, die von EPM verwendet werden sollen, und diese Ports in der Firewall zu öffnen.

Viele Windows Server-Anwendungen, die auf RPC basieren, bieten Optionen (z. B. Registrierungsschlüssel), um die zulässigen Ports anzupassen. Windows-Dienste verwenden für diese Aufgabe den UnterschlüsselHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet .

Wenn Sie einen Port oder Portbereich angeben, verwenden Sie Ports, die außerhalb des Bereichs häufig verwendeter Ports liegen. Eine umfassende Liste der Serverports, die in Windows und wichtigen Microsoft-Produkten verwendet werden, finden Sie unter Dienstübersicht und Netzwerkportanforderungen für Windows. Der Artikel listet auch RPC-Serveranwendungen auf und erwähnt, welche RPC-Serveranwendungen so konfiguriert werden können, dass sie benutzerdefinierte Serverports verwenden, die über die Funktionen der RPC-Runtime hinausgehen.

Wichtig

Dieser Abschnitt, diese Methode bzw. diese Aufgabe enthält eine Beschreibung der Schritte zum Bearbeiten der Registrierung. Durch die falsche Bearbeitung der Registrierung können schwerwiegende Probleme verursacht werden. Daher ist es wichtig, bei der Ausführung der folgenden Schritte sorgfältig vorzugehen. Erstellen Sie eine Sicherungskopie der Registrierung, bevor Sie Änderungen vornehmen, damit Sie die Registrierung wiederherstellen können, falls ein Problem auftritt. Weitere Informationen zum Sichern und Wiederherstellen der Registrierung finden Sie unter Sichern und Wiederherstellen der Registrierung in Windows.

Standardmäßig ist der Internetschlüssel nicht vorhanden. Daher müssen Sie es erstellen. Für den Internetschlüssel können Sie die folgenden Einträge konfigurieren:

• Ports REG_MULTI_SZ: Gibt einen Port oder einen inklusiven Portbereich an. Die anderen Einträge, die unter Internet angezeigt werden, geben an, ob dies die zu verwendenden Ports oder die Ports sind, die von der Verwendung ausgeschlossen werden sollen.

  • Wertbereich: 0 - 65535
    Beispielsweise steht 5984 für einen einzelnen Port und 5000 bis 5100 für einen Satz von Ports. Wenn Werte außerhalb des Bereichs von 0 bis 65535 liegen oder ein Beliebiger Wert nicht interpretiert werden kann, behandelt die RPC-Runtime die gesamte Konfiguration als ungültig.

• PortsInternetAvailable REG_SZ: Gibt an, ob der Wert Ports einzufügende Ports oder auszuschließende Ports darstellt.

  • Werte: Y oder N (keine Groß-/Kleinschreibung beachten)
    • Y: Die im Eintrag Ports aufgeführten Ports stellen alle Ports auf diesem Computer dar, die für EPM verfügbar sind.
    • N: Die im Eintrag Ports aufgeführten Ports stellen alle Ports dar, die für EPM nicht verfügbar sind.

• UseInternetPorts REG_SZ: Gibt die Standardsystemrichtlinie an.

  • Werte: Y oder N (keine Groß-/Kleinschreibung beachten)
    • Y: Den Prozessen, die die Standardsystemrichtlinie verwenden, werden Ports aus der Gruppe der im Internet verfügbaren Ports zugewiesen, wie zuvor definiert.
    • N: Den Prozessen, die die Standardsystemrichtlinie verwenden, werden Ports aus dem Satz von Nur-Intranet-Ports zugewiesen.

Sie sollten einen Bereich von Ports öffnen, die größer als Port 5000 sind. Portnummern, die kleiner als 5.000 sind, werden möglicherweise bereits von anderen Anwendungen verwendet und können Konflikte mit Ihren DCOM-Anwendungen verursachen. Darüber hinaus zeigen die bisherigen Erfahrungen, dass mindestens 100 Ports geöffnet werden sollten. Dies liegt daran, dass mehrere Systemdienste diese RPC-Ports verwenden, um miteinander zu kommunizieren.

Hinweis

Die Mindestanzahl der erforderlichen Ports kann sich von Computer zu Computer unterscheiden. Bei Computern, die mehr Datenverkehr unterstützen, kann es zu einer Portauslastung kommen, wenn die dynamischen RPC-Ports eingeschränkt sind. Berücksichtigen Sie dies, wenn Sie den Portbereich einschränken.

Warnung

Wenn in der Portkonfiguration ein Fehler auftritt oder nicht genügend Ports im Pool vorhanden sind, kann EPM KEINE RPC-Serveranwendungen (einschließlich Windows-Diensten wie Netlogon) registrieren, die dynamische Endpunkte verwenden. Wenn ein Konfigurationsfehler auftritt, ist der Fehlercode 87 (0x57) ERROR_INVALID_PARAMETER. Wenn beispielsweise nicht genügend Ports vorhanden sind, protokolliert Netlogon das Ereignis 5820:

Protokollname: System
Quelle: NETLOGON
Ereignis-ID: 5820
Ebene: Fehler
Schlüsselwörter: Klassisch
Beschreibung:
Der Netlogon-Dienst konnte die AuthZ-RPC-Schnittstelle nicht hinzufügen. Der Dienst wurde beendet. Der folgende Fehler ist aufgetreten: "Der Parameter ist falsch."

Weitere Informationen zur Funktionsweise von RPC finden Sie unter RPC über IT/Pro.

Beispiel für eine benutzerdefinierte Portkonfiguration

In diesem Beispiel wurden die Ports 5000 bis 6000 (einschließlich) willkürlich ausgewählt, um zu veranschaulichen, wie die neuen Registrierungseinträge konfiguriert werden können. In diesem Beispiel wird keine Mindestanzahl von Ports empfohlen, die für ein bestimmtes System erforderlich sind. Eine solche Konfiguration erfordert das Hinzufügen des Internetschlüssels unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpcund das Hinzufügen der folgenden Einträge:

• Ports MULTI_SZ
  • Datentyp: MULTI_SZ
  • Wert: 5000-6000
• PortsInternetAvailable REG_SZ
  • Datentyp: REG_SZ
  • Wert: Y
• UseInternetPorts REG_SZ
  • Datentyp: REG_SZ
  • Wert: Y

Der Computer muss neu gestartet werden, damit diese Konfiguration wirksam wird. Danach werden allen Anwendungen, die RPC verwenden, dynamische Ports im Bereich von 5000 bis 6000 (einschließlich) zugewiesen.

Problembehandlung bei RPC-Fehlern

PortQry

PortQry bietet einen schnellen Einblick in die Funktionsweise von RPC, bevor Sie sich mit Netzwerkablaufverfolgungsdaten beschäftigen. Sie können schnell ermitteln, ob Sie eine Verbindung herstellen können, indem Sie den folgenden Befehl auf dem Clientcomputer ausführen:

Portqry.exe -n <ServerIP> -e 135

Hinweis

In diesem Befehl stellt ServerIP> die IP-Adresse des Servers dar, < den Sie kontaktieren.

Betrachten Sie beispielsweise den folgenden Befehl:

Portqry.exe -n 169.254.0.2 -e 135

Dieser Befehl erzeugt eine Ausgabe, die dem folgenden Auszug ähnelt:

Querying target system called:
169.254.0.2
Attempting to resolve IP address to a name...
IP address resolved to RPCServer.contoso.com
querying...
TCP port 135 (epmap service): LISTENING
Using ephemeral source port
Querying Endpoint Mapper Database...
Server's response:
UUID: d95afe70-a6d5-4259-822e-2c84da1ddb0d
ncacn_ip_tcp:169.254.0.2[49664]

Wenn Sie diese Ausgabe untersuchen, können Sie die folgenden Informationen ermitteln:

• DNS funktioniert ordnungsgemäß (die IP-Adresse wurde in einen vollqualifizierten Domänennamen (FQDN) aufgelöst).
• PortQry hat den RPC-Port (135) auf dem Zielcomputer kontaktiert.
• EPM hat auf PortQry geantwortet und den dynamischen Port 49664 (in eckigen Klammern eingeschlossen) für die nachfolgende Kommunikation zugewiesen.
• PortQry wurde erneut mit Port 49664 verbunden.

Wenn einer dieser Schritte fehlschlägt, können Sie normalerweise mit dem Sammeln gleichzeitiger Netzwerkablaufverfolgungen beginnen, wie im nächsten Abschnitt beschrieben.

Weitere Informationen zu PortQry finden Sie unter Verwenden des PortQry-Befehlszeilentools.

Netsh

Sie können das Windows netsh-Tool verwenden, um Netzwerkablaufverfolgungsdaten gleichzeitig auf dem Client und dem Server zu sammeln.

Um gleichzeitige Netzwerkablaufverfolgungen zu erfassen, öffnen Sie ein Eingabeaufforderungsfenster mit erhöhten Rechten sowohl auf dem Client als auch auf dem Server.

Führen Sie auf dem Client den folgenden Befehl aus:

Netsh trace start scenario=netconnection capture=yes tracefile=c:\client_nettrace.etl maxsize=512 overwrite=yes report=yes

Führen Sie auf dem Server den folgenden Befehl aus:

Netsh trace start scenario=netconnection capture=yes tracefile=c:\server_nettrace.etl maxsize=512 overwrite=yes report=yes

Versuchen Sie nun, das Problem auf dem Clientcomputer zu reproduzieren. Führen Sie dann an der Eingabeaufforderung in beiden Fenstern den folgenden Befehl aus, um die Ablaufverfolgungen zu beenden:

Netsh trace stop

Öffnen Sie die Ablaufverfolgungsdateien in Microsoft Network Monitor 3.4 oder Message Analyzer, und filtern Sie die Ablaufverfolgungsdaten nach der IP-Adresse des Servers oder Clientcomputers und tcp-Port 135. Verwenden Sie beispielsweise Filterzeichenfolgen wie die folgenden:

• Ipv4.address==<client-ip> and ipv4.address==<server-ip> and tcp.port==135

  In dieser Filterzeichenfolge < stellt client-ip> die IP-Adresse des Clients und <server-ip> die IP-Adresse des Servers dar.

• tcp.port==135

Suchen Sie in den gefilterten Daten in der Spalte Protokoll nach dem EPM-Eintrag.

Suchen Sie nach einer Antwort von EPM (auf dem Server), die eine dynamische Portnummer enthält. Wenn die dynamische Portnummer vorhanden ist, notieren Sie sie zur späteren Referenz.

Filtern Sie die Ablaufverfolgungsdaten erneut nach der dynamischen Portnummer und der IP-Adresse des Servers. Verwenden Sie beispielsweise eine Filterzeichenfolge wie tcp.port==<dynamic-port-allocated> und ipv4.address==<server-ip>. In dieser Filterzeichenfolge < stellt dynamic-port-allocated> die dynamische Portnummer und <server-ip> die IP-Adresse des Servers dar.

Suchen Sie in den gefilterten Daten nach Beweisen, dass der Client erfolgreich mit dem dynamischen Port verbunden ist, oder suchen Sie nach Netzwerkproblemen, die möglicherweise aufgetreten sind.

Port nicht erreichbar

Die häufigste Ursache für fehler "RPC-Server nicht verfügbar" ist, dass der Client keine Verbindung mit dem dynamischen Port herstellen kann, der zugewiesen wurde. Die clientseitige Ablaufverfolgung zeigt dann TCP SYN-Neuübertragungen für den dynamischen Port an.

Dieses Verhalten gibt an, dass eine der folgenden Bedingungen die Kommunikation blockiert:

• Der dynamische Portbereich ist in der Firewall in der Umgebung blockiert.
• Ein mittleres Gerät verwirft die Pakete.
• Der Zielserver verwirft die Pakete. Diese Bedingung kann durch Konfigurationen wie das Löschen von Paketen der Windows-Filterplattform (Windows Filtering Platform, WFP), das Löschen von Paketen der Netzwerkschnittstellenkarte (Network Interface Card, NIC) oder Änderungen des Filtertreibers verursacht werden.

Sammeln von Daten für eine tiefergehende Problembehandlung

Bevor Sie sich an den Microsoft-Support wenden, empfehlen wir Ihnen, Informationen zu Ihrem Problem zu sammeln.

Voraussetzungen

In diesen Verfahren wird das TsS-Toolset (TroubleShootingScript) verwendet. Um dieses Toolset verwenden zu können, sollten Sie die folgenden Voraussetzungen beachten:

• Sie müssen auf dem lokalen Computer über die Berechtigung auf Administratorebene verfügen.

• Wenn Sie das Toolset zum ersten Mal ausführen, müssen Sie einen Lizenzvertrag akzeptieren.

• Stellen Sie sicher, dass die Windows PowerShell Skriptausführungsrichtlinie für den Computer auf RemoteSignedfestgelegt ist. Weitere Informationen zur PowerShell-Ausführungsrichtlinie finden Sie unter about_Execution_Policies.

  Hinweis

  Wenn Ihre Umgebung verhindert, dass Sie auf Computerebene verwenden RemoteSigned , können Sie sie vorübergehend auf Prozessebene festlegen. Führen Sie dazu das folgende Cmdlet in einem PowerShell-Eingabeaufforderungsfenster mit erhöhten Rechten aus, bevor Sie das Tool starten:

  PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned
  

  Führen Sie das Cmdlet aus, um zu überprüfen, ob die PS C:\> Get-ExecutionPolicy -List Änderung wirksam wird.

  Die Berechtigungen auf Prozessebene gelten nur für die aktuelle PowerShell-Sitzung. Nachdem Sie das PowerShell-Fenster geschlossen haben, wird die Ausführungsrichtlinie auf die ursprüngliche Einstellung zurückgesetzt.

Sammeln Sie wichtige Informationen, bevor Sie sich an den Microsoft-Support wenden.

1. Laden Sie TSS auf allen Knoten herunter, und erweitern Sie es im Ordner C:\tss .

2. Öffnen Sie den Ordner C:\tss in einem PowerShell-Eingabeaufforderungsfenster mit erhöhten Rechten.

3. Starten Sie Ablaufverfolgungen auf dem Problemcomputer, indem Sie das folgende Cmdlet ausführen:

   TSS.ps1 -Scenario NET_RPC
   

4. Reagieren Sie auf die Aufforderung zum Lizenzvertrag.

5. Reproduzieren Sie das Problem. Sie können Tools wie Ereignisanzeige oder wbemtest verwenden, um das Problem zu überwachen oder zu testen.

6. Nachdem Sie das Problem reproduzieren, beenden Sie sofort das Sammeln von Daten.

7. Nachdem die automatisierten Skripts die erforderlichen Daten erfasst haben, fügen Sie die Daten an Ihre Supportanfrage an.