Der heutige Artikel betrifft ein mehr als ungewöhnliches, leider aber auch seit langer Zeit bekanntes Problem, welches in der vergangenen Woche auftauchte. Bei einem unserer Kunden hatte ich erfolgreich eine Swing-Migration der Exchange-Umgebung von Exchange Server 2003 SP2 nach Exchange Server 2010 SP1 vollzogen. Dabei half mir unter anderem der sehr detaillierte Artikel von , weshalb die Migration relativ unkompliziert  und zügig verlief.

Problem

Dennoch meldeten einige Benutzer bereits nach der Verschiebung der Postfächer vom alten zum neuen Exchange-Server, dass ihre E-Mails nicht mehr versendet wurden.

Das Problem selber war relativ schwierig einzugrenzen, da ich die Nachrichten nicht in der Verfolgung auf dem Exchange-Server sah und so erst beim Spiegeln einer Citrix-Terminal-Sitzung erkannte, wo die Ursache liegen musste. Außerdem vermutete ich zunächst ein Problem mit dem Mailserver eines externen Anbieters, bei dem eine Domäne mit IMAP-Postfächern genutzt wurde. Die Fehlermeldung von Outlook lautet:

Fehler (0x800CCC13) beim Ausführen der Aufgabe “Nachrichten werden gesendet”: “Es kann keine Netzwerkverbindung hergestellt werden. Überprüfen Sie die Netzwerkverbindung oder das Modem.”

Dabei verbleibt eine zu versendende E-Mail-Nachricht (mit Anhang) im Postausgang, über Extras, Senden/Empfangen, Übermittlungseinstellungen, Status anzeigen erfährt man nur die irreführende Meldung:

Diese Meldung trat unter den folgenden Gegebenheiten auf:

  • Microsoft Exchange Server 2010 (Version 14.1 (Build 218.15))
  • Outlook 2007 SP3 auf Citrix XenApp 4.6 Terminalserver Windows Server 2003 R2 Standard, SP2
  • zusätzliches POP3- oder IMAP-Postfach im Outlook welches zum Versand genutzt wird
  • eine E-Mail mit Anhang muss über das IMAP-Konto versendet werden

Bei meinen ersten Tests prüfte ich auf der Firewall, ob IMAP und SMTP Pakete problemlos passieren konnten und kontrollierte die Einstellungen des Virenscanners auf den Terminalservern auf evtl. Blockierungen des SMTP-Verkehrs – nichts. Nachdem ich die IMAP-Funktionen des externen Anbieters manuell getestet hatte, war ich mit meinem Latein am Ende.

Lösung

Bei meiner Suche im Internet fand ich dann einige treffende Hinweise. Daniel Holm berichtet auf dem Blog von Interworks in seinem Artikel von dem oben beschriebenen Verhalten. Leider wird als Lösung nur das Aktivieren des Exchange-Cache-Modus erwähnt, was in einer Terminalserver-Umgebung wirklich keinen Sinn macht und somit für mich unbrauchbar war.

Beim weiteren Suchen fiel mir auf, dass das Problem bereits seit der ersten Version von Exchange 2010 (Version 14.00.0639.021) bekannt ist, laut Microsoft KB-Eintrag soll das Service Pack 1 für Exchange Server 2010 Abhilfe schaffen. Der Exchange Server 2010 verfügte allerdings bereits über Service Pack 1 inkl. Rollup 5 (Version 14.1 (Build 218.15)) – ebenfalls Fehlanzeige.

Allerdings fand ich auch einen Hinweis, dass möglicherweise Outlook Express als Ursache für das Problem in Frage kommt. Allerdings ließ sich selbiges auf Grund der folgenden Gruppenrichtlinien-Einstellung nicht als Benutzer starten (Richtlinie war aktiv!):

Nachdem ich diese Einstellung (Benutzerkonfiguration, Windows-Komponenten, Internet Explorer, Assistenten für Internetzugang deaktivieren) wieder auf “Nicht konfiguriert” gesetzt hatte, musste der Terminalserver neu gestartet werden, die Aktualisierung mit Hilfe von gpupdate allein brachte keinen Erfolg.

Seit dem Neustart der Server funktioniert der Versand von E-Mail-Nachrichten mit Anhang nun auch über ein zusätzlich eingebundenes IMAP-Konto ohne Probleme.

Update 14.12.2011

Mit dem Update Rollup 6 for Exchange Server 2010 Service Pack 1 (KB2608646) tritt das Problem erneut auf. In meiner obigen Anleitung funktionierte die Lösung für den Stand des Rollup 5 (KB2582113).

Update 15.12.2011

Es gibt Dinge, die begreift man einfach nicht. Das beschriebene Problem ist – wie von Zauberhand – über Nacht verschwunden, mehrere unterschiedliche Tests haben das bestätigt. Die folgenden Windows Updates (inkl. Neustarts der betreffenden Maschinen) wurden auf dem Exchange Server und Terminalserver (mit installiertem Outlook 2007 SP3) angewendet:

Exchange Server 2010

  • Sicherheitsupdate für Microsoft Windows (KB2639417)
  • Update für Microsoft Windows (KB2633952)
  • Sicherheitsupdate für Microsoft Windows (KB2620712)
  • Sicherheitsupdate für Microsoft Windows (KB2618451)
  • Sicherheitsupdate für Microsoft Windows (KB2618444): Dieses Update löst unter anderem das Problem, dass sich die Exchange Management Console nicht beenden läßt, wenn der Internet Explorer 9 installiert wurde.
  • Update für Microsoft Windows (KB2607047)

Terminalserver 2003

  • Hotfix für Windows Server 2003 (KB2633952-v2)
  • Sicherheitsupdate für Microsoft Windows (KB2639417)
  • Sicherheitsupdate für Microsoft Windows (KB2624667)
  • Sicherheitsupdate für Microsoft Windows (KB2620712)
  • Sicherheitsupdate für Microsoft Windows (KB2618451)
  • Sicherheitsupdate für Microsoft Windows (KB2633171)

Welches Update nun auf welchem Server für die Behebung des Problems verantwortlich ist, lässt sich leider sehr schwer nachvollziehen. In einer produktiven Kundenumgebung mag ich auch nur ungern ein Rollback der durchgeführten Aktionen beginnen, zumal die Funktionalität nun wieder gegeben ist. Wer die beschriebenen Ereignisse bestätigen kann und evtl. das verantwortliche Update identifizieren konnte, schreibt mir bitte eine Nachricht oder hinterlässt einen Kommentar.

Fazit

Ein ziemlich merkwürdiges Problem, welches meiner Meinung nach in dieser Konstellation nicht allzu selten auftreten dürfte. Allein die Menge an Treffern bei der Suche im Internet bereitete mir einige Sorgen, da keine wirkliche Lösung des Problems in verschiedenen Foren publiziert wurde. Wer das von mir beschriebene Verhalten bestätigen kann, oder Gegenteiliges zu berichten weiß, bitte die Kommentar-Funktion nutzen. Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.