Problembehandlung bei der Replikation öffentlicher Ordner – Teil 3: Problembehandlung beim Löschen von Replikaten und häufige Probleme
Veröffentlichung des Originalartikels: 28.11.2011
Datum des Originalbeitrags im US-Blog: 24.01.2006
Dies ist der dritte Blogbeitrag zur Problembehandlung bei der Replikation öffentlicher Ordner. Im ersten Beitrag wird die Problembehandlung bei der Replikation neuer Änderungen behandelt. Im zweiten Blogbeitrag geht es um die Problembehandlung bei der Replikation vorhandener Daten. Dieser Blogbeitrag in der Reihe befasst sich mit der Problembehandlung beim Löschen von Replikaten und den häufigen Problemen. Lesen Sie das gesamte Referenzmaterial, um umfassend informiert zu sein!
Problembehandlung beim Löschen von Replikaten
Angenommen, Sie haben einen alten Server aus der Replikatliste aller Ordner entfernt. Wenn Sie jedoch in Exchange-System-Manager (ESM) zu den Instanzen für öffentliche Ordner navigieren, sehen Sie dort dennoch eine Reihe von Ordnern. Dies ist auf ein Problem mit dem Prozess zum Löschen von Replikaten zurückzuführen. Wenn Sie in der Exchange 2003 SP2-Version von ESM versuchen, einen öffentlichen Informationsspeicher in diesem Zustand zu löschen, wird in ESM ein Dialogfeld mit dem folgenden Text angezeigt:
„You cannot delete this public folder store because it contains folder replicas. To avoid data loss, right click the public folder store and use Move Replicas to move the replicas to a different server. It may take several hours until the content is replicated to the new server and the local replicas are removed.“
Wenn Sie einen Informationsspeicher aus der Replikatliste eines Ordners entfernen, löscht dieser Informationsdaten die Daten nicht sofort. Stattdessen wird eine spezielle 0x20-Statusanforderung an alle anderen Replikate gesendet. Dies wird als RDPSR (Replica Delete Pending Status Request) bezeichnet und lässt sich nicht von einer normalen Statusanforderung im Anwendungsprotokoll unterscheiden. Eine RDPSR-Nachricht enthält ein Kennzeichen, das auf die bevorstehende Löschung des Replikats hinweist. Wenn die anderen Informationsspeicher diese 0x20-Nachricht erhalten, antworten Sie mit einer speziellen 0x10-Nachricht namens RDPA (Replica Delete Pending Ack). Mit der RDPA-Nachricht wird angezeigt, dass es OK ist, diese Daten zu löschen – aber die anderen Informationsspeicher senden diese 0x10-Nachricht nur, wenn sie bereits alle Änderungsnummern (Change Numbers, CNs) besitzen, die das Replikat aufweist, dessen Löschung aussteht. Das Replikat wird erst gelöscht, sobald der Informationsspeicher eine 0x10-Nachricht empfängt, in der angegeben wird, dass ein anderer Informationsspeicher die Daten besitzt.
Das bedeutet, wenn Sie den Informationsspeicher löschen, bevor die Instanzen der öffentlichen Ordner leer sind, gehen wahrscheinlich Daten verloren. Nur in der Exchange 2003 SP2-Version von ESM werden Sie daran gehindert. In älteren Versionen müssen Sie die Instanzen der öffentlichen Ordner manuell prüfen, um festzustellen, ob der Informationsspeicher gelöscht werden kann. Sie sollten die Instanzen der öffentlichen Ordner immer prüfen, bevor Sie einen öffentlichen Informationsspeicher löschen. Wenn Sie dann in der Exchange 2003 SP2-Version von ESM die obige Warnung erhalten, sollten Sie nicht versuchen, diese zu ignorieren oder zu umgehen, sondern stattdessen das Problem mit dem Prozess zum Löschen von Replikaten behandeln.
Vor Exchange 2003 SP2 war es so, dass der Server, der aus der Replikatliste entfernt wird, nur einmal eine RDPSR-Nachricht sendet. Empfängt er keine Antwort auf diese Nachricht, bleibt dieser Ordner einfach auf unbestimmte Zeit in den Instanzen für öffentliche Ordner, sofern Sie den Informationsspeicher nicht der Replikatliste hinzufügen und dann wieder daraus entfernen, damit eine neue RDPSR-Nachricht gesendet wird. In Exchange 2003 SP2 wurde dieses Verhalten geändert, sodass der Informationsspeicher den Versuch stündlich wiederholt, bis er eine RDPA-Nachricht empfängt.
Problembehandlung
Die Problembehandlung ist fast mit der beim Abgleichprozess identisch.
1. Hat das Replikat, dessen Löschung aussteht, eine 0x20-Nachricht gesendet?
Das werden Sie nur erfahren, wenn Sie beim Entfernen des Replikats die Protokollierung aktiviert haben. Ist dies nicht geschehen, müssen Sie das Replikat einfach nur der Liste hinzufügen und dann wieder daraus entfernen. Suchen Sie dann im Anwendungsprotokoll nach der 0x20-Nachricht.
2. Hat die 0x20-Nachricht andere Replikate erreicht?
Sie sollten inzwischen wissen, wie Sie das feststellen können. Prüfen Sie die Anwendungsprotokolle auf den anderen Replikaten, um zu sehen, ob dort 0x20-Nachrichten eingegangen sind.
3. Hat ein anderes Replikat mit einer 0x10-Nachricht geantwortet?
Dies ist der Teil, auf den Sie sich wahrscheinlich letztendlich konzentrieren werden. Wenn ein Replikat die 0x20-Nachricht von dem Replikat empfangen hat, dessen Löschung aussteht, aber nicht mit einer 0x10-Nachricht geantwortet hat, bedeutet dies, dass das Replikat mit ausstehender Löschung über Daten verfügt, die das andere Replikat nicht besitzt. Da Ihnen bekannt ist, dass soeben eine 0x20-Nachricht von diesem Replikat eingegangen ist, wissen Sie auch, dass dem Replikat bereits bekannt ist, welche Daten fehlen. Daher gehen Sie davon aus, dass alle 24 bis 48 Stunden eine Abgleichanforderung für diesen Ordner gesendet wird. Überprüfen Sie das Anwendungsprotokoll, und führen Sie genau dieselbe Problembehandlung wie für den normalen Abgleichprozess aus, die in einem vorherigen Blogbeitrag beschrieben wurde.
4. Hat das Replikat, dessen Löschung aussteht, die 0x10-Nachricht empfangen?
Sobald das andere Replikat über alle Daten verfügt, sollte dieses Replikat mit einer 0x10-Nachricht antworten. Wenn das Replikat, dessen Löschung aussteht, diese 0x10-Nachricht empfängt, ist es letztendlich zum Löschen dieser Daten bereit. Das bedeutet aber nicht, dass die Daten sofort gelöscht werden. Wenn dieses Replikat von Clients verwendet wird, wird es erst später bei der Onlinewartung gelöscht. Bei Bedarf können Sie dies beschleunigen, indem Sie die Informationsspeichereinbindung aufheben und den Informationsspeicher dann wieder einbinden.
Häufige Probleme
Möglicherweise stellen Sie fest, dass ein Server zwar eine Art von Replikationsnachricht an einen anderen Server gesendet hat, der empfangende Server diese eingehende Nachricht aber nie im Anwendungsprotokoll protokolliert hat. Der Nachrichtenverfolgung können Sie jedoch entnehmen, dass die Nachricht lokal an den Informationsspeicher auf diesem Server übermittelt wurde. Dieses Verhalten weist normalerweise entweder auf ein Problem mit der Tabelle Replication State oder auf ein Berechtigungsproblem auf dem virtuellen SMTP-Server hin.
Widmen wir uns zuerst dem einfacheren Problem. Wenn eine eingehende Replikationsnachricht vom empfangenden Server ignoriert wird, ist das Problem auf die Tabelle Replication State oder die ReplState-Tabelle zurückzuführen. Beachten Sie, dass ein Problem mit der ReplState-Tabelle auch dazu führen kann, dass der Server keine Abgleichanforderungen (0x8) für einige Ordner ausgibt. Daher sind diese Informationen auch für diese Situation relevant. In allen Informationsspeichern wird mithilfe der ReplState-Tabelle der Replikationsstatus für alle replizierten Ordner nachverfolgt. Die Tabelle enthält für jeden Ordner mehrere Zeilen - eine Zeile pro Replikat. Es ist möglich, dass die Zeilen in der ReplState-Tabelle nicht mehr mit der Replikatliste synchron sind, sodass die Tabelle zu viele oder zu wenige Zeilen enthält. Sie können die Tabelle ggf. wieder mit der Replikatliste synchronisieren, indem Sie eine Änderung vornehmen. Entfernen Sie beispielsweise einen Server aus der Replikatliste, übernehmen Sie die Änderung, und fügen Sie den Server dann sofort wieder der Replikatliste hinzu. Dies funktioniert jedoch nicht immer. Erfreulicherweise wurde dem isinteg-Befehl ein ReplState-Test hinzugefügt. Weitere Informationen finden Sie im Knowledge Base-Artikel KB889331 für Exchange 2003 oder KB892485 für Exchange 2000. Sofern Sie über die aktualisierten Programme „isinteg.exe“ und „store.exe“ verfügen, können Sie das Problem mit der ReplState-Tabelle mithilfe des isinteg-Befehls beheben. Wenn Sie nur den ReplState-Test ausführen, geht das normalerweise sehr schnell – sogar bei einem großen Informationsspeicher dauert der Vorgang weniger als eine Minute. Sobald Sie den isinteg-Befehl ausgeführt haben, müssen Sie möglicherweise immer noch eine Änderung am Ordner vornehmen, damit die ReplState-Tabelle mit der Replikatliste synchronisiert wird. Sobald beide synchron sind, sollte der Server normalerweise die eingehenden Replikationsnachrichten verarbeiten können oder mit dem Ausgeben von Abgleichanforderungen beginnen.
Das andere häufige Problem, das zum Ignorieren einer eingehenden Replikationsnachricht führt, ist ein Exchange 2003-spezifisches Problem. Ein Exchange 2003-Server erfordert, dass der sendende Server auf dem virtuellen SMTP-Server über das Recht „Senden als“ verfügt. Das heißt, wenn ServerA Exchange 2003 ist und ServerB eine Öffentliche Ordner-Replikationsnachricht an ServerA sendet, muss ServerB auf dem virtuellen SMTP-Server von ServerA über das Recht „Senden als“ verfügen. Andernfalls verarbeitet ServerA die eingehende Replikationsnachricht nicht. Diese Berechtigung wird normalerweise über die Gruppe „Exchange Domain Servers“ erteilt. Wenn das Problem auf das Recht „Senden als“ zurückzuführen ist, scheitern alle eingehenden Replikationsnachrichten von einem bestimmten Server. Ich habe festgestellt, dass das Problem am einfachsten mit einer Netzwerkablaufverfolgung identifiziert werden kann. Diese sollte durchgeführt werden, während eine Replikationsnachricht von einem Server an einen anderen gesendet wird. Zwischen den Servern sollte folgende Unterhaltung stattfinden:
ServerA: 220 ServerA.microsoft.com Microsoft ESMTP MAIL Service...
ServerB: EHLO ServerB.microsoft.com
ServerA: 250-ServerA.microsoft.com Hello
250-TURN
250-SIZE
250-ETRN
250-PIPELINE
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-X-EXCH50
250 OK
Wichtig ist hierbei, dass ServerA die GSSAPI NTLM LOGIN-Optionen ankündigen muss. Sind diese nicht in der Antwort von ServerA auf EHLO enthalten, ist dies normalerweise darauf zurückzuführen, dass die integrierte Windows-Authentifizierung auf dem virtuellen SMTP-Server nicht aktiviert ist. Dies ist in Schritt 1 von KB843106 und in Schritt 3 von KB842273 erwähnt. Sofern diese Authentifizierungsverben erscheinen, sollte erkennbar sein, dass ServerB sie zu verwenden versucht:
ServerB: X-EXPS GSSAPI
ServerA: 334 GSSAPI supported
ServerB: <Base64-verschlüsselte Daten>
ServerA: 334 <mehr Base64-verschlüsselte Elemente>
ServerB: CRLF
ServerA: 235 2.7.0 Authentication successful.
Wenn die Authentifizierung nicht erfolgreich ist, besteht vielleicht ein Kerberos-Problem oder ein Problem mit dem Computerkonto für ServerB. Als Nächstes senden die Server Verbindungsstatusinformationen. Danach werden dann schließlich die E-Mails übermittelt:
ServerB: MAIL FROM:<ServerB-IS@microsoft.com>
ServerA: 250 2.1.0 ServerB-IS@microsoft.com....Sender OK
ServerB: RCPT TO:<ServerA-IS@microsoft.com> NOTIFY=NEVER
ServerA: 250 2.1.5 ServerA-IS@microsoft.com
ServerB: XEXCH50 2404 2
ServerA: 354 Send binary data
Es ist diese letzte Antwort auf das XEXCH50-Verb, die wichtig ist. Wenn die Antwort „354 Send binary data“ lautet, ist alles in Ordnung, zumindest was die Berechtigungen auf dem virtuellen SMTP-Server betrifft. Wenn die GSSAPI NTLM-Anmeldeoptionen nicht angekündigt wurden oder der Authentifizierungsversuch gescheitert ist, wird erwartet, dass ServerA stattdessen mit „504 Need to authenticate“ antwortet. Wenn diese Schritte erfolgreich sind, aber ServerA immer noch mit „504 Need to authenticate“ anstatt mit „354 Send binary data“ antwortet, dann besitzt ServerB auf dem virtuellen SMTP-Server nicht das Recht „Senden als“. Hierfür kann es mehrere Gründe geben. Erstens, wenn Sie Rechte (z. B. Exchange-Administrator mit vollständigen Berechtigungen) in ESM delegieren, erbt dieser Benutzer oder diese Gruppe eine Verweigerung des Rechts „Senden als“. Wenn Sie Administratorrechte mithilfe von ESM an das Computerkonto, die Exchange Domain Servers-Gruppe oder eine andere Gruppe, die die Exchange-Server enthält, delegieren, wird die Replikation des öffentlichen Ordners abgebrochen. Ein weiterer möglicher Grund ist, dass das Computerkonto sich nicht in der Exchange Domain Servers-Gruppe befindet und daher nicht das Recht „Senden als“ besitzt. Sie müssen die Berechtigungen auf dem virtuellen SMTP-Server auswerten und feststellen, warum das Computerkonto für den sendenden Server nicht über die entsprechenden Rechte verfügt. Weitere Informationen zum Problem „504 Need to authenticate“ finden Sie im Knowledge Base-Artikel KB843106 und KB842273.
Schlussfolgerung
Sie haben beim Lesen dieses Blogbeitrags vielleicht bemerkt, dass SP2 für Exchange 2003 mehrere wichtige Verbesserungen enthält, die dazu beitragen, Replikationsprobleme zu verhindern und die Problembehandlung zu vereinfachen. Umgebungen mit mehreren Informationsspeichern können wirklich enorm von SP2 profitieren, insbesondere was das Verschieben von Replikaten zwischen Servern und das Hinzufügen und Entfernen von öffentlichen Informationsspeichern betrifft.
Ich hoffe, die Informationen in diesem Beitrag waren für Sie hilfreich. Vielen Dank auch an Dave Whitney, der all dies geprüft hat!
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Public Folder Replication Troubleshooting – Part 3: Troubleshooting Replica Deletion and Common Problems