Problembehandlung bei der Replikation öffentlicher Ordner – Teil 4: Exchange Server 2007/2010-Tipps

Veröffentlichung des Originalartikels: 28.11.2011

Datum des Originalbeitrags im US-Blog: 11.01.2008

Vor zwei Jahren habe ich eine dreiteilige Reihe von Blogbeiträgen zur Problembehandlung bei der Replikation öffentlicher Ordner veröffentlicht. In Teil 1 wird die Replikation neuer Daten und in Teil 2 die Replikation vorhandener Daten behandelt. In Teil 3 geht es um den Prozess zum Löschen von Replikaten sowie einige häufige Probleme in Exchange 2003. Mit diesem Beitrag möchte ich die Reihe mit Informationen zu Exchange 2007 ergänzen.

In Exchange 2007 wird die Replikation öffentlicher Ordner im Grunde genau wie immer ausgeführt. Die Problembehandlungsschritte in den ersten drei Teilen der Reihe sind immer noch gültig. Die Administratortools haben sich jedoch geändert, und auch die häufigen Probleme unterscheiden sich in Exchange 2007 etwas von denen in Exchange 2003, und diese Punkte möchte ich hier behandeln.

Änderungen in den Administratortools

Das Ereignisprotokoll ist immer noch das beste Tool, um ein Replikationsproblem auf eine bestimmte Fehlerquelle einzugrenzen. In Teil 1 habe ich vorgeschlagen, die Protokollierung für „Eingehende Nachrichten (Replikation)“ und „Ausgehende Nachrichten (Replikation)“ auf ein Maximum zu erhöhen. Dies trifft immer noch zu, außer dass Sie in Exchange 2007 hierzu das Cmdlet Set-EventLogLevel verwenden, um „MSExchangeIS\9001 Public\Replication Incoming Messages“ und „MSExchangeIS\9001 Public\Replication Outgoing Messages“ auf die Stufe Expert zu setzen.

In Teil 2 habe ich beschrieben, wie die Optionen Hierarchie synchronisieren und Inhalt synchronisieren in Exchange-System-Manager (ESM) verwendet werden, um eine Statusmeldung zu erzwingen und ein Timeout aller ausstehenden Abgleicheinträge zu veranlassen. Dies ist in Exchange 2007 immer noch über die Cmdlets Update-PublicFolderHierarchy und Update-PublicFolder möglich. Diese Cmdlets sind auch im Tool zur Verwaltung öffentlicher Ordner in SP1 verfügbar, und erscheinen dort als Hierarchie aktualisieren , wenn der Stamm von „Öffentliche Ordner“ ausgewählt ist, und als Inhalt aktualisieren, wenn ein bestimmter öffentlicher Ordner ausgewählt ist. Da Sie diese Cmdlets über die Befehlszeile aufrufen können, sind sie sehr viel flexibler als Exchange 2003-Optionen. Beispielsweise ist es jetzt mit dem simplen Befehl „Get-PublicFolderStatistics | Update-PublicFolder“ sehr einfach, ein Timeout der Abgleicheinträge für jeden Ordner zu veranlassen, der über ein Replikat auf Ihrem Exchange 2007-Server verfügt. In Exchange 2003 waren hierzu viele Klicks erforderlich.

In Teil 3 habe ich beschrieben, wie Sie in der Ansicht der Instanzen öffentlicher Ordner prüfen können, ob das Löschen eines Replikats abgeschlossen wurde. In Exchange 2007 können Sie dieselben Informationen mit dem Befehl „Get-PublicFolderStatistics“ anzeigen.

Häufige Probleme in Exchange 2007

Das häufigste Symptom, das ich bisher festgestellt habe, ist ein Problem mit dem Informationsspeichertreiber. Beispielsweise wird eine Abgleichantwort an den Exchange 2007-Server gesendet, aber im Anwendungsprotokoll auf der Exchange 2007-Seite ist das eingehende Replikationsereignis nicht protokolliert. Der Nachrichtenverfolgung können Sie entnehmen, dass die Replikationsnachricht bis zum Hub-Transport-Server gelangt ist und dass dann im Informationsspeichertreiber ein Fehler aufgetreten ist.

Dies kann eine Reihe von Ursachen haben, und erfreulicherweise ist die Problembehandlung nicht sehr schwierig. Der beste Problembehandlungsansatz ist in diesem Fall, die Pipelineablaufverfolgung und die Transportinhaltskonvertierung zu verwenden, die auf dem Hub-Transport-Server verfügbar sind. Wenn Sie „Get-TransportServer | fl“ ausführen, sehen Sie einige Einstellungen, die sich hierauf beziehen:

PipelineTracingEnabled : False
ContentConversionTracingEnabled : False
PipelineTracingPath : C:\Programme\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing
PipelineTracingSenderAddress : SERVER01-IS@contoso.com

Gehen Sie wie folgt vor, um herauszufinden, warum die Abgleichantwort im Informationsspeichertreiber scheitert: Legen Sie „PipelineTracingSenderAddress“ auf die SMTP-Adresse des Informationsspeichers des öffentlichen Ordners fest, der die Abgleichantwort sendet. Legen Sie dann „ContentConversionTracingEnabled“ auf „$true“ und „PipelineTracingEnabled“ auf „$true“ fest, und stellen Sie das Problem nach. Sehen Sie sich anschließend den Ordner an, der von „PipelineTracingPath“ angegeben wird. Der Ordner sollte einen Unterordner namens „ContentConversionTracing“ enthalten und dieser wiederum den Ordner „InboundFailures“. Im Ordner „InboundFailures“ befindet sich eine EML-Datei mit der Replikationsnachricht selbst und eine TXT-Datei mit einigen Informationen zum Fehler. Oben in der TXT-Datei finden Sie häufig einen nützlichen Hinweis zur Fehlerursache.

In einigen Fällen sah die TXT-Datei beispielsweise wie folgt aus:

Microsoft.Exchange.Data.Storage.PropertyValidationException: Fehler bei der Eigenschaftenüberprüfung. Eigenschaft = [{00020329-0000-0000-c000-000000000046}:'Keywords'] Categories
Fehler = Das Element 0 in der mehrwertigen Eigenschaft ist ungültig..

Hier wird ein Problem mit der Eigenschaft „Categories“ gemeldet. Dies geschieht, wenn der fragliche öffentliche Ordner Elemente enthält, für die konfiguriert ist, dass die Eigenschaft „Categories“ zwar keinen Wert, aber beispielsweise ein einzelnes Leerzeichen enthält, anstatt wirklich leer zu sein. Sie können dies erkennen, indem Sie in Outlook einige Elemente nach Kategorie anzeigen. Dann sollten Sie sehen können, dass es zwei verschiedene Gruppen von Elementen mit der Angabe „Kein“ (None) gibt. Sie können das Problem beheben, indem Sie in Outlook einfach die Kategorie für alle Elemente mit der Angabe „Kein“ löschen. Möglicherweise müssen Sie die Elemente auf eine andere Kategorie und dann wieder auf „Kein“ setzen. Sobald die Eigenschaft „Categories“ wirklich leer ist, haben Sie nur eine Gruppe von Elementen, für die „Kein“ angegeben ist, und die Elemente werden erfolgreich repliziert.

Weiteres Beispiel:

Microsoft.Exchange.Data.Storage.PropertyValidationException: Fehler bei der Eigenschaftenüberprüfung. Eigenschaft = [{00062004-0000-0000-c000-000000000046}:0x8092] Email2AddrType
Fehler = Email2AddrType ist zu lang. Die maximal zulässige Länge beträgt 9, die tatsächliche Länge ist 35..

In diesem Fall wird ein Problem mit der Email2AddrType-Eigenschaft gemeldet. Wir haben herausgefunden, dass die Eigenschaft bei bestimmten Kontakten irgendwie mit der vollständigen E-Mail-Adresse gefüllt wurde und nicht nur den normalen Adresstyp, z. B. „SMTP“ oder „EX“ enthielt, wie dies normalerweise der Fall sein sollte. Nachdem die Eigenschaft korrigiert wurde, konnten die Elemente repliziert werden.

Mitunter wird bei einem Fehler im Informationsspeichertreiber die bestimmte Eigenschaft, bei der ein Problem aufgetreten ist, nicht identifiziert, beispielsweise in der folgenden Ausgabe:

Microsoft.Exchange.Data.Storage.ConversionFailedException: Der Inhalt der Nachricht ist beschädigt. ---> Microsoft.Exchange.Data.Storage.ConversionFailedException: Fehler der Inhaltskonvertierung aufgrund fehlerhaften TNEF-Inhalts (Verletzungsstatus: 0x00000800)

So sieht der Fehler aus, wenn das in KB 936000 beschriebene Problem aufgetreten ist. Wenn Sie die Korrektur auf dem Exchange 2003-Server vornehmen, der die Replikationsnachricht generiert, wird das Problem behoben.

Die wichtige Erkenntnis hierbei ist, dass in Exchange 2007 eine umfangreiche Eigenschaftenüberprüfung stattfindet, um zu verhindern, dass fehlerhafte Daten in den Informationsspeicher gelangen. Obwohl das eine gute Sache ist, kann dies dazu führen, dass die Daten von den Exchange 2003-Servern erst repliziert werden, nachdem die Probleme mit dem Inhalt auf dem Exchange 2003-Server behoben wurden. Die Ablaufverfolgung für die Inhaltskonvertierung (ContentConversionTracing) kann Ihnen beim Identifizieren dieser Probleme helfen und weist häufig auf die genaue Eigenschaft hin, die das Problem verursacht.

Es gibt ein weiteres häufiges Problem, das mit ContentConversionTracing identifiziert werden kann, das aber nicht durch ein tatsächliches Inhaltsproblem verursacht wird. Die TXT-Datei im Ordner „InboundFailures“ sieht wie folgt aus:

Microsoft.Exchange.Data.Storage.ConversionFailedException: Der Grenzwert der Inhaltskonvertierung wurde überschritten.
at Microsoft.Exchange.Data.Storage.InboundMimeConverter.ConvertToItem(MimePromotionFlags promotionFlags)
at Microsoft.Exchange.Data.Storage.ItemConversion.InternalConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options, MimePromotionFlags promotionFlags, Boolean isStreamToStream)
at Microsoft.Exchange.Data.Storage.ItemConversion.ConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options)

InboundConversionOptions:
- preferredCharset: iso-8859-1
- trustAsciiCharsets: True
- isSenderTrusted: False
- imceaResolveableDomain: contoso.com
- preserveReportBody: False
- clearCategories: True
- userADSession:
- recipientCache: Microsoft.Exchange.Data.Directory.Recipient.ADRecipientCache
- clientSubmittedSecurely: False
- serverSubmittedSecurely: False

ConversionLimits:
- maxMimeTextHeaderLength: 2000
- maxMimeSubjectLength: 255
- maxSize: 2147483647
- maxMimeRecipients: 12288
- maxRecipientPropertyLength: 1000
- maxBodyPartsTotal: 250
- maxEmbeddedMessageDepth: 30
- exemptPFReplicationMessages: True

Die erste Zeile besagt: „Der Grenzwert der Inhaltskonvertierung wurde überschritten“. Normalerweise ist eine Replikationsnachricht für einen öffentlichen Ordner von Größenlimits und dergleichen befreit, warum sollte also die Replikationsnachricht aus diesem Grund scheitern? Beachten Sie, dass „isSenderTrusted“ FALSE ist. Das bedeutet, dass die Nachricht über eine SMTP-Verbindung eingegangen ist, die nicht authentifiziert wurde. Entweder ist die Authentifizierung des sendenden Servers gescheitert, oder die Authentifizierung wurde nicht einmal versucht. Dies ähnelt sehr der Situation, die im Abschnitt „Häufige Probleme“ von Teil 3 geschildert wurde, wo aufgrund eines Authentifizierungsfehlers ein Problem mit dem XEXCH50-Verb in Exchange 2003 auftritt. Da der sendende Server nicht authentifiziert wurde, wendet der Exchange 2007-Server die normalen Größenlimits auf die Nachricht an. Wenn es sich hierbei um eine Inhaltsreplikationsnachricht mit mehr als 250 Anlagen handelt (nicht ungewöhnlich bei einer Inhaltsabgleichantwort), dann scheitert die Nachricht aufgrund einer Limitüberschreitung. Dies geschieht häufig, wenn ein Administrator einen zweiten Empfangsconnector erstellt hat, der keine Authentifizierung erlaubt, dieser aber so konfiguriert ist, dass der internen IP-Adresse und nicht der externen IP-Adresse gelauscht wird. Wenn dies nicht die Ursache ist, müssen Sie möglicherweise eine NetMon-Aufzeichnung durchführen, um das Problem zu identifizieren, so wie in Teil 3 beschrieben.

Schlussfolgerung

Mit diesem letzten Blogbeitrag der Reihe sollten Sie jetzt alles Notwendige wissen, um Probleme mit der Replikation öffentlicher Ordner in einer Umgebung mit Exchange 2007 zu behandeln. Alle alten Problembehandlungsschritte haben immer noch Gültigkeit. Es sind jetzt einfach nur andere Verwaltungstools verfügbar, und die Probleme unterscheiden sich etwas. Ich hoffe, das hilft Ihnen!

- Bill Long

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Public Folder Replication Troubleshooting - Part 4: Exchange Server 2007/2010 tips