Behandlung von Verbindungsproblemen durch Registrierungseinträge für RPC-Clientprotokolle

Gegenstand dieses Artikels sind die Registrierungsschlüssel für das RPC-Protokoll (RPC = Remote Procedure Call/Remoteprozeduraufruf) und deren mögliche Auswirkungen auf Microsoft Outlook-Verbindungen zu Microsoft Exchange Server. Außerdem werden in diesem Artikel grundlegende Verfahren zur Problembehandlung beschrieben.

Outlook verwendet RPCs für Aufrufe an das Netzwerk. Mithilfe von RPCs kann Outlook Aufrufe an viele verschiedene Protokollstapel senden. Welche Aufrufe verwendet werden, ist von dem Protokollstapel abhängig, der auf dem betreffenden Computer verfügbar ist. Das gebräuchlichste Protokoll ist TCP/IP. Weitere RPC-Protokolle sind NetBIOS, NetBIOS über TCP/IP und IPX/SPX. Wenn ein Clientcomputer entsprechende RPC-Protokollanforderungen sendet, müssen diese Protokolle auf dem Server verfügbar sein.

Registrierungseinträge für RPC-Protokolle

Dieser Abschnitt beschreibt die wichtigsten Registrierungseinträge, die das von Outlook verwendete RPC-Protokoll bestimmen.

RPC_Binding_Order

Der Eintrag "RPC_Binding_Order" wird erstellt, wenn Sie den Outlook-Client oder Exchange Server installieren. Der Eintrag "RPC_Binding_Order" bestimmt die Protokollreihenfolge, die verwendet wird, wenn Outlook-RPC-Kommunikationsvorgänge initiiert werden.

Hinweis: Der Eintrag "RPC_Binding_Order" wird in Microsoft Exchange Server 2003 und Microsoft Exchange 2000 Server nicht erstellt. Dieser Eintrag wird nur in Microsoft Exchange Server 5.5 und früheren Exchange-Versionen erstellt.

Diesen Eintrag finden Sie in folgendem Registrierungsschlüssel: Standardmäßig enthält "RPC_Binding_Order" die folgenden Werte: Weitere Informationen zum Ändern oder Wiederherstellen der Bindungsreihenfolge finden Sie im folgenden Artikel der Microsoft Knowledge Base:

RPC_Srv_Binding_Order

Der Registrierungseintrag "RPC_Svr_Binding_Order" wird erstellt, wenn Sie den Outlook-Client oder Exchange Server installieren. Verwechseln Sie diesen Eintrag nicht mit dem Registrierungseintrag "RPC_Binding_Order". Dieser Eintrag wird bei Outlook-RPC-Verbindungen nicht verwendet. Dieser Eintrag bestimmt die Protokollreihenfolge, die für bestimmte Server-zu-Server-Verbindungen verwendet wird. Sie können mithilfe des Dienstprogramms "RPC DUMP" ermitteln, welche Protokolle den Clients zur Verfügung stehen. Weitere Informationen zum Dienstprogramm "RPC DUMP" finden Sie im nachstehenden Abschnitt "Erkennen von RPC-Serverproblemen mit RPC Dump" in diesem Artikel.

Sie finden den Eintrag "RPC_Svr_Binding_Order" im folgenden Unterschlüssel der Registrierung: Standardmäßig enthält "Rpc_Svr_Binding_Order" die folgenden Werte: Hinweis: Es können noch weitere Werte vorhanden sein, wenn zusätzliche Protokolle installiert sind.

ClientProtocols

Der Registrierungsunterschlüssel ClientProtocols wird erstellt, wenn Sie das Betriebssystem und das erste Netzwerkprotokoll installieren. Der Unterschlüssel ClientProtocols enthält Einträge, durch die festgelegt wird, welche Protokolle das Client-Betriebssystem für Verbindungen mit Exchange Server verwenden kann. Outlook kann das zu sendende RPC-Protokoll festlegen; dieser Registrierungsunterschlüssel bestimmt, ob das Betriebssystem dieses Protokoll unterstützt. Unter Microsoft Windows 2000 und Microsoft Windows XP finden Sie diesen Unterschlüssel im folgenden Registrierungsschlüssel: Standardmäßig enthält der Unterschlüssel ClientProtocols die folgenden Registrierungseinträge für TCP/IP: Hinweis: In Microsoft Windows NT 4.0 ist zwar der Speicherort des Unterschlüssels gleich, die standardmäßigen TCP/IP-Einträge sind jedoch anders. In der folgenden Tabelle sind die standardmäßigen TCP/IP-Einträge für Windows NT aufgeführt: Hinweis: In Microsoft Windows 98 ist zwar der Speicherort des Unterschlüssels gleich, die standardmäßigen TCP/IP-Einträge unterscheiden sich jedoch von denen unter Windows NT. In der folgenden Tabelle sind die standardmäßigen TCP/IP-Einträge für Windows 98 aufgeführt:

Problembehandlung für RPC-Registrierungseinträge

Wenn RPC-Registrierungseinträge fehlen, kann Outlook eventuell keine Verbindung zu Exchange Server aufbauen. Wenn der Unterschlüssel ClientProtocols fehlt oder Datenwerte nicht vorhanden sind, kann der Outlook-Client eventuell nicht das erwartete Protokoll für Verbindungen verwenden. Damit Outlook das richtige RPC-Protokoll verwenden kann, müssen der Unterschlüssel ClientProtocols und die entsprechenden Datenwerte vorhanden und korrekt sein.

Ist zum Beispiel auf dem Computer, auf dem Outlook ausgeführt wird, nur der RPC ClientProtocols-Registrierungseintrag "ncacn_np" (mit dem Wert "rpcrt4.dll" vorhanden), versucht Outlook, die Verbindung zu dem Exchange Server-Computer mit Named Pipes über TCP/IP und unter Verwendung des Standardports 139 aufzubauen. Falls bei der Verbindung eine Firewall überwunden werden muss, muss Port 139 geöffnet sein. Der fehlende Registrierungseintrag "ncacn_ip_tcp" (mit dem Wert "rpcrt4.dll") muss wiederhergestellt werden, damit eine TCP/IP-Verbindung zu dem Exchange Server-Computer über Port 135 oder Port 445 unterstützt wird.

Wenn RPC-Registrierungseinträge auf dem Server fehlen, sind außerdem die Exchange-Dienste nicht so registriert, dass sie auf Clientanforderungen antworten können. Aus diesem Grund kann der Client keine Verbindung zu Exchange unter Verwendung des angeforderten Protokolls aufbauen. Fehlt auf dem Server zum Beispiel der RPC ClientProtocols-Registrierungseintrag "ncacn_ip_tcp", ist der Microsoft Exchange-Informationsspeicher nicht verfügbar, wenn Sie die Verbindung über TCP/IP aufbauen. Sie können das Dienstprogramm "RPC Dump" zur Behebung dieses Problems verwenden.

Outlook-Fehlermeldungen

Auf dem Outlook-Client können die folgenden Fehlermeldungen angezeigt werden, wenn RPC-Registrierungseinträge fehlen oder beschädigt sind:

• Der Name kann nicht aufgelöst werden. Das Microsoft Exchange-Adressbuch kann sich beim Microsoft Exchange Server nicht anmelden.
• Die Anmeldung von Outlook ist fehlgeschlagen. Überprüfen Sie Ihre Netzwerkverbindung, sowie den Server- und Postfachnamen.
• Der Name kann nicht aufgelöst werden. Die Verbindung mit dem Microsoft Exchange Server kann aufgrund von Netzwerkproblemen nicht hergestellt werden. Wenden Sie sich an Ihren Administrator, wenn das Problem andauert.
• Die Anmeldeinformationen sind ungültig. Überprüfen Sie Benutzername und Domäne, und geben Sie Ihr Kennwort erneut ein. Wenn es sich um ein neues Konto handelt oder Ihr Administrator eine Kennwortänderung gefordert hat, klicken Sie auf "Kennwort ändern" und melden Sie sich mit dem neuen Kennwort an.
• Microsoft Outlook konnte nicht gestartet werden. Die Anmeldung beim Microsoft Exchange Server ist fehlgeschlagen.
• Der Server, der die globale Adressliste enthält, ist nicht mehr verfügbar. Stellen Sie eine Verbindung zu einem anderen Server her, indem Sie Outlook neu starten, oder wiederholen Sie den Vorgang, wenn der Server wieder erreichbar ist. (The server containing the global address list is no longer available. You can reconnect to a different server by restarting Outlook or retry the operation when the server is reachable.)
• Die Verbindung mit dem Microsoft Exchange Server ist nicht verfügbar. Outlook muss im Onlinemodus oder verbunden sein, um diesen Vorgang auszuführen.

Wenn RPC-Registrierungseinträge fehlen oder beschädigt sind, können die folgenden Probleme auftreten:

• Benutzer erhalten zwar neue E-Mail-Nachrichten, die Option "Hinweis auf neue Nachrichten" funktioniert jedoch nicht. Dieses Problem kann auftreten, wenn RPC-Registrierungswerte für UDP (User Datagram Protocol) fehlen.
• Benutzer können keine Verbindung zu dem Computer herstellen, auf dem Exchange Server ausgeführt wird.
• Benutzer können Aliasnamen nicht in der "Globalen Adressliste" (GAL) überprüfen.
• Benutzer werden mehrmals aufgefordert, ihre Anmeldeinformationen einzugeben. Danach werden die zuvor in diesem Artikel aufgeführten Fehlermeldungen angezeigt.
• Auf Faxdrucker kann nicht zugegriffen werden.

Erkennen von RPC-Problemen mit dem Netzwerkmonitor

Mit dem Netzwerkmonitor können Sie RPC-Probleme erkennen. Beispiel:

• Wenn in Ihrer aufgenommenen Ablaufverfolgung keinerlei RPC-Verkehr vom Client zum Server verzeichnet ist, fehlt eventuell der gesamte RPC-Unterschlüssel. Falls der Unterschlüssel vorhanden ist, vergewissern Sie sich, dass der Eintrag "ncacn_ip_tcp" (mit dem Wert "rpcrt4.dll") nicht fehlt. Fehlt der Eintrag "ncacn_ip_tcp" (mit dem Wert "rpcrt4.dll"), versucht der Client nicht, über Port 135 eine Verbindung zu TCP/IP aufzubauen. Der Client versucht in diesem Fall nur solche Verbindungen aufzubauen, die NetBIOS oder Named Pipes über TCP/IP (Port 139 oder 445) verwenden.
• Wenn Ihrer aufgenommenen Ablaufverfolgung zu entnehmen ist, dass der Client die Verbindung zur Endpunktzuordnung erfolgreich hergestellt hat, kann der Client eine RPC-opnum0x3-Anforderung senden. Der Client erhält dann eine Antwort, deren letzte vier Paare von Hexadezimaldaten wie folgt aussehen: D6 A0 C9 16. Diese Antwort enthält typischerweise dann Nullen, wenn die Anforderung erfolgreich war. Dieses Verhalten kann auftreten, wenn auf dem Server der Registrierungswert "ncacn_ip_tcp" im Registrierungsunterschlüssel ClientProtocols fehlt. In diesem Szenario ist der Microsoft Exchange-Informationsspeicherdienst nicht für die Verwendung über TCP/IP verfügbar.

Weitere Informationen zum Analysieren von Client-Netzwerkverkehr mithilfe von Exchange Server finden Sie auf folgender Microsoft-Website:

Erkennen von RPC-Serverproblemen mit "RPC Dump"

Sie können das Dienstprogramm "RPC Dump" zur Behebung von RPC-Serverproblemen verwenden. Sie können mithilfe des Dienstprogramms "RPC DUMP" die RPC-Anwendungen auflisten lassen, die auf dem Server ausgeführt werden. Drei RPC-Komponenten müssen verfügbar sein, damit der Outlook-Client erfolgreich eine Verbindung aufbauen kann:

• Die Endpunktzuordnung.
• Der Microsoft Exchange-Informationsspeicherdienst mit dem UUID (Universal Unique Identifier) a4f1db00-ca47-1067-b31e-00dd010662da.
• Die Namensdienstanbieter-Schnittstelle (Name Service Provider Interface, NSPI) mit dem UUID f5cc5a18-4264-101a-8c59-08002b2f8426.
  • In Exchange Server 5.5 und früher wurde die NSPI durch den Microsoft Exchange-Verzeichnisdienst bereitgestellt.
  • In Exchange Server 2003 und Exchange 2000 Server wird die NSPI über den globalen Katalogserver bezogen. Auf einem globalen Katalogserver wird die NSPI unter dem NetLogon-Dienst (lsass.exe) ausgeführt. Der Exchange-Server kann die NSPI-Verweis- und Proxy-Funktionalität gewährleisten.
  Weitere Informationen zu NSPI und Outlook-Clients finden Sie im folgenden Artikel der Microsoft Knowledge Base:
  256976  (http://support.microsoft.com/kb/256976/DE/ ) XCLN: greift MAPI-Client wie darauf zu aktiv Verzeichnis

Das Dienstprogramm "RPC Dump" muss von einer Eingabeaufforderung ausgeführt werden. Einige der wichtigsten Befehlszeilen für dieses Dienstprogramm sind:

• rpcdump.exe /i > rpcdump.txt
• rpcdump.exe /p > rpcdump.txt

Durch diese beiden Befehle wird die generierte Ausgabe in der Datei "Rpcdump.txt" gespeichert.

Das Dienstprogramm "RPC Dump" wird in der Regel in Verbindung mit dem Netzwerkmonitor verwendet. Kann der Outlook-Client beispielsweise einen Namen nicht erfolgreich überprüfen, können Sie das Dienstprogramm "RPC Dump" auf dem Server ausführen, der die NSPI bereitstellt.

Hinweis: Fehlt der Wert f5cc5a18-4264-101a-8c59-08002b2f8426 auf einem globalen Katalogserver für TCP/IP (ncacn_ip_tcp), können die Outlook-Clients keine Verbindung zu der NSPI über TCP/IP herstellen.

Sie können das Dienstprogramm "RPC Dump" außerdem verwenden, wenn Outlook-Clients Namen zwar erfolgreich überprüfen, sich jedoch nicht bei dem Postfach anmelden können. Durch das Ausführen des Dienstprogramms "RPC Dump" können Sie ermitteln, ob der Speicher (a4f1db00-ca47-1067-b31e-00dd010662da) für Remoteprozeduraufrufe mit TCP/IP (ncacn_ip_tcp), Named Pipes (ncacn_np) oder anderen Protokollen registriert ist. Dieses Problem wird in der Regel durch fehlende Registrierungseinträge des Typs ClientProtocols auf dem Server verursacht. Dieses Problem kann auch dann auftreten, wenn sowohl die NSPI als auch der Speicher demselben Port statisch zugeordnet sind.

Weitere Informationen zu statischen Portzuordnungen für Exchange Server 2003 und Exchange 2000 Server finden Sie im folgenden Artikel der Microsoft Knowledge Base: Hinweis: Das Dienstprogramm "RPC Dump" listet die Endpunktzuordnung nicht auf. Weitere Informationen zum Beziehen des Dienstprogramms "RPC Dump" finden Sie auf folgender Microsoft-Website:

Wiederherstellen fehlender RPC-Registrierungswerte

Gehen Sie folgendermaßen vor, um RPC-Registrierungswerte auf dem Client oder Server wiederherzustellen.

Warnung: Die unkorrekte Verwendung des Registrierungseditors kann schwerwiegende Probleme verursachen, die das gesamte System betreffen und eine Neuinstallation des Betriebssystems erforderlich machen. Microsoft kann nicht garantieren, dass Probleme, die von einer falschen Verwendung des Registrierungseditors herrühren, behoben werden können. Benutzen Sie den Registrierungseditor auf eigene Verantwortung.

Schritt 1: Registrierungseinträge überprüfen

1. Klicken Sie auf Start und anschließend auf Ausführen.
2. Geben Sie in das Feld Öffnen den Befehl regedit ein, und klicken Sie auf OK.
3. Suchen Sie den folgenden Schlüssel in der Registrierung:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ClientProtocols
   Vergewissern Sie sich mithilfe der Tabellen aus dem Abschnitt "ClientProtocols" in diesem Artikel, dass alle Einträge vorhanden und korrekt sind.
4. Sollten Werte fehlen, fügen Sie diese hinzu. Gehen Sie hierzu folgendermaßen vor:
   1. Zeigen Sie im Menü Bearbeiten auf Neu, und klicken Sie auf Zeichenfolge.
   2. Geben Sie den Namen des fehlenden Zeichenfolgenwertes ein, und drücken Sie die [EINGABETASTE].
   3. Drücken Sie die [EINGABETASTE].
   4. Geben Sie im Dialogfeld Zeichenfolge bearbeiten den fehlenden Wert in das Feld Wert ein, und klicken Sie auf OK.
5. Beenden Sie den Registrierungseditor.
6. Starten Sie den Computer neu.
7. Testen Sie die Exchange Server-Konnektivität.

Schritt 2: Version der DLL-Datei überprüfen

Falls alle Registrierungseinträge vorhanden sind, überprüfen Sie die auf dem Computer installierte Version der RPC-DLL. Die Version der RPC-DLL muss mit der Version und der Buildnummer des auf dem Computer installierten Windows-Betriebssystems übereinstimmen.

Hinweis: In der Liste der Registrierungsschlüssel in diesem Artikel sind die Namen der DLL-Dateien aufgelistet, die von den jeweiligen RPCs verwendet werden. "Rpc4rt4.dll" ist beispielsweise die DLL-Datei, die von TCP/IP unter Windows 2000 und Windows XP verwendet wird.

Gehen Sie folgendermaßen vor, um Version und Buildnummer des Windows-Betriebssystems auf dem Computer zu ermitteln:

1. Klicken Sie auf Start und anschließend auf Ausführen.
2. Geben Sie in das Feld Öffnen den Befehl winver ein.
3. Notieren Sie sich die Version und die Buildnummer.

Gehen Sie folgendermaßen vor, um die Version der DLL-Datei zu ermitteln:

1. Gehen Sie mit dem Windows Explorer zu der RPC-DLL-Datei im Ordner "Windows\System32".
2. Klicken Sie mit der rechten Maustaste auf die Datei, und klicken Sie auf Eigenschaften.
3. Klicken Sie auf Version.
4. Notieren Sie sich die Dateiversion.
   
   Die Dateiversion muss die Buildnummer des Windows-Betriebssystems auf dem Computer widerspiegeln. Bei der Windows XP-Version 5.1 mit der Buildnummer 2600 lautet die Versionsnummer der Datei "Rpcrt4.dll" beispielsweise 5.1.2600.0.

Passt die Version der DLL-Datei nicht zu Version und Buildnummer des auf dem Computer installierten Windows-Betriebssystems, ersetzen Sie die DLL-Datei durch eine andere DLL-Datei der richtigen Version. Gehen Sie hierzu folgendermaßen vor:

1. Suchen Sie die korrekte Version der DLL-Datei.
   
   Sie finden die Datei auf der Windows CD, in Windows Service Packs oder auf einem anderen Computer, auf dem das gleiche Build von Windows ausgeführt wird.
2. Gehen Sie auf dem Computer, auf dem das Problem auftritt, zu der fraglichen DLL-Datei.
3. Ändern Sie die Dateinamenerweiterung der DLL-Datei zu .bak oder .old.
4. Kopieren Sie die DLL-Datei der richtigen Version auf den Computer, auf dem das Problem auftritt.
5. Starten Sie den Computer neu.
6. Testen Sie die Exchange Server-Konnektivität.

Schritt 3: TCP/IP entfernen und neu installieren

Wichtig: Dieser Schritt muss nur auf dem/den Clientcomputer(n) durchgeführt werden.

Falls Sie die Exchange Server-Konnektivität mithilfe der Schritte 1 und 2 nicht wiederherstellen konnten, entfernen Sie TCP/IP auf dem Outlook-Clientcomputer, und installieren Sie es danach neu. Microsoft empfiehlt, das TCP/IP-Protokoll nicht vom Server zu entfernen. Gehen Sie folgendermaßen vor, um TCP/IP auf dem Clientcomputer zu entfernen und danach neu zu installieren:

1. Melden Sie sich als lokaler Administrator an.
2. Klicken Sie auf Start und anschließend auf Systemsteuerung.
3. Doppelklicken Sie auf Netzwerkverbindungen.
4. Klicken Sie mit der rechten Maustaste auf die LAN-Verbindung, und klicken Sie auf Eigenschaften.
5. Installieren Sie ein anderes Protokoll als Platzhalter für die Verbindung. Installieren Sie zum Beispiel NWLink.
6. Deaktivieren Sie das Kontrollkästchen Internetprotokoll (TCP/IP), und klicken Sie auf OK.
7. Klicken Sie auf Ja.
8. Wiederholen Sie die Schritte 3 bis 5 für jede aufgelistete Netzwerkverbindung.
9. Starten Sie den Computer neu.
10. Klicken Sie auf Start und anschließend auf Systemsteuerung.
11. Doppelklicken Sie auf Netzwerkverbindungen.
12. Klicken Sie mit der rechten Maustaste auf die Netzwerkverbindung, und klicken Sie auf Eigenschaften.
13. Deaktivieren Sie das Kontrollkästchen Internetprotokoll (TCP/IP), und klicken Sie auf OK.
14. Klicken Sie auf Ja.
15. Installieren Sie TCP/IP für jede Netzwerkverbindung neu.
16. Entfernen Sie in jeder Netzwerkverbindung das Protokoll, das als Platzhalter installiert war (zum Beispiel NWLink). Entfernen Sie keine anderen Protokolle, die bereits installiert waren.
17. Starten Sie den Computer neu.

Weitere Informationen zur Behebung von Verbindungsproblemen finden Sie in den folgenden Artikeln der Microsoft Knowledge Base: