Ich hatte bei einem Kunden das Problem, das Benutzer A an Benutzer B keine Mail mehr schicken konnte. Benutzer A erhielt einen “Non Delivery Report”, trotz korrekt eingegebener Adresse. Was ist passiert?

Vor einiger Zeit haben wir bei diesem Kunden den Exchange Server 2003 abgelöst und einen Exchange Server 2010 eingeführt. Das allein konnte ja nicht der Grund sein, deswegen bin ich auf die Suche nach dem Fehler gegangen.

Erster Anhaltspunkt war natürlich der NDR, der wie folgt aussieht:

Was mich hier stutzig gemacht hat ist die Adresse, an die es geschickt werden soll:

IMCEAEX-_O=Domäne_OU=First+20administrative+20group_cn=Recipients_cn=benutzer@domain.de

Der Wert “First Administrative Group” sollte nicht mehr auftauchen, da dies auf den Exchange Server 2003 hinweist. Wenn man sich auf dem Domänencontroller in “Active Directory-Benutzer und –Computer” einmal in den Eigenschaften des Benutzers die Attribute anschaut, sieht das Attribut “legacyExchangeDN” wie folgt aus:

Wie man sieht, ist das Attribut anders als die Adresse, an die die Mail hingeschickt werden soll. Woher also kommt nun der falsche Wert?

Die Lösung ist der automatische Vervollständigungs-Cache (auto-complete cache). Dieser nutzt X.500-Adressen, und wenn der gespeicherte Wert (gespeichert zu Zeiten des Exchange 2003) genutzt wird (was gemacht wird, egal ob man die Adresse nur anfängt zu tippen und dann die gespeicherte Adresse nutzt oder ob man die komplette Adresse neu tippt), dann will die Email an die alte zwischengespeicherte Adresse gesendet werden.

Wie kann man den Fehler nun beheben? Auf dem Exchange 2010-Server in den Eigenschaften des Benutzers (an den die Email gesendet werden soll) trägt man eine zusätzliche X.500-Adresse ein. Das sieht dann wie folgt aus:

Wichtig ist, das man hier den Haken bei “E-Mail-Adressen automatisch basierend auf der E-Mail-Adressrichtlinie aktualisieren” entfernt.

Nach dem Eintragen dieser Adresse kam die Email an, trotz Auto-Vervollständigung :)

Neulich hatte ich das Problem, das bei einem Kunden auf einen Schlag alle Outlook 2003 Clients nicht mehr mit dem Exchange 2003 Server kommunizieren konnten. Nach etwas Recherche stellte sich heraus, das alle Clients per HTTPS angebunden waren und das das selbstsignierte Zertifikat, das der Small Business Server 2003 bei der Installation ausstellt, abgelaufen war. Da der Kunde kein offizielles Zertifikat kaufen wollte dachte ich mir, ich könnte mit SelfSLL.exe aus den “IIS 6.0 Resource Kit Tools (IIS 6.0)” ein neues Zertifikat erstellen. Bei genauerem untersuchen des Zertifikats stellte sich allerdings heraus das darin mehrere Namen vorhanden sind. SelfSLL.exe ist nicht in der Lage SAN Zertifikate auszustellen. Also was nun? Beim Recherchieren bin ich dann unter folgender URL http://www.sbs-rocks.com/sbs2k3/sbs2k3-n2.htm auf die Lösung gestoßen: man kann mit dem im SBS2003 enthaltenen “Configure E-Mail and Internet Connection Wizard” (kurz CEICW) ein neues SAN Zertifikat, welches dann wieder 5 Jahre gültig ist, erstellen.