Zugriff auf Outlook Web Access mit E-Mail-Adresse im Pfad funktioniert nicht

Ich bin gerade dabei, die wirklich empfehlenswerte E-Mail-Archivierungssoftware MailStore Server 4 zusammen mit Exchange Server 2003 SP2 zu testen. Die Software bietet unter anderem eine automatische Archivierung und greift dazu via HTTP auf die einzelnen Postfächer zu. Der verwendete Pfad entspricht dem von Outlook Web Access und enthält dabei immer die E-Mail-Adresse des entsprechenden Benutzers:

http://mailserver/exchange/user@domain.de

Während die Archivierung in meiner Testumgebung einwandfrei funktionierte, erhielt ich in der Produktivumgebung jedes Mal den HTTP Error 404 – File or directory not found. Die genaue Fehlermeldung im Log von MailStore sah dabei folgendermaßen aus:

16:17:41.637 [5] INFO Worker started.
16:17:41.637 [5] INFO Notify:set-title 'Exchange-Postfach via HTTP'
16:17:41.637 [5] INFO RPC:UserPrimarySmtpMappingDict
16:17:41.652 [7] INFO Worker started.
16:17:41.652 [7] INFO Notify:set-title 'michael.douglas '
16:17:41.652 [7] INFO Initializing import...
16:17:41.652 [7] INFO Cut-off date 08.12.2009 14:17:41 UTC calculated.
16:17:41.652 [7] INFO EWS URL is https://exchange.company.intern/EWS/Exchange.asmx
16:17:41.652 [7] INFO EWS Settings: MailboxEmailAddress=michael.douglas@company.de, PublicFolders=False, Timeout=300000
16:17:41.652 [7] INFO Sending EWS Request (GetRootFolderId)
16:17:41.871 [7] INFO Detecting WebDAV authentication type for https://exchange.company.intern/exchange/michael.douglas@company.de
16:17:41.871 [7] INFO PROPFIND request returned 401. Assuming that basic auth is enabled.
16:17:42.246 [7] INFO PROPFIND request with credentials returned 404. Mailbox not found.
16:17:42.246 [7] EXCEPTION Worker has thrown an exception.
x1e0a3ab552a37532.x3faa0301a70b1db9: Die Authentifizierung war erfolgreich, jedoch konnte MailStore das zugehörige Exchange-Postfach nicht finden. Bitte tragen Sie eine gültige SMTP-E-Mail-Adresse im Postfach-Feld ein.
   at x1e0a3ab552a37532.xb3945755616fc02f.x519302db962881d2(String x218764376be92b39, String xe8e4b5871d71a79a)
   at x1e0a3ab552a37532.xb3945755616fc02f.x20aee281977480cf(String x218764376be92b39, String xe8e4b5871d71a79a)
   at x1e0a3ab552a37532.xe407d1fc015e1828.xe4186db941eb3b15()
   at x1e0a3ab552a37532.x1c99866f9eedb8b9.xd163366a2934e2d0(x68643caa7f9b193e xb6b3da7953a69f26)
   at x1e0a3ab552a37532.x1c99866f9eedb8b9.xe8104f075b8c79cd(x68643caa7f9b193e xb6b3da7953a69f26)
   at x1e0a3ab552a37532.xa337ebecd75ea144.xe8104f075b8c79cd(x68643caa7f9b193e xb6b3da7953a69f26)
   at xf22d66fa21615d06.x6a73c17378e42077.GetSourceFolders(Boolean withkeys)
   at x8894990f73349d39.xc31d7520e8eb9685.Initialize()
   at xf22d66fa21615d06.xc00832b4251338c6.Initialize()
   at x8894990f73349d39.xc31d7520e8eb9685.DoWork()
   at xa09a46f04c08f2df.xaa0919120ad92013.x356882ad8f141ffb()
16:17:42.246 [5] INFO Worker completed. No exception catched.

Eine Einzelarchivierung – ebenfalls über HTTP – funktionierte dagegen völlig problemlos. Allerdings wird der OWA-Pfad in diesem Fall nicht mit der E-Mail-Adresse des Benutzers, sondern lediglich mit dessen Benutzernamen aufgerufen:

http://mailserver/exchange/user

Analog zum beschriebenen Verhalten ließ sich Outlook Web Access in der Produktivumgebung nicht aufrufen, wenn der Pfad die E-Mail-Adresse des Benutzers enthielt – auch hier kam es jedes Mal zum HTTP Error 404. In der Testumgebung klappte dagegen auch das problemlos. Ergo: Es musste an irgendwelchen Einstellungen in Exchange bzw. Outlook Web Access liegen.

Nach einer Weile bin ich dann auf die Idee gekommen, auf dem produktiven Exchange-Server einfach mal den Exchange Best Practice Analyzer auszuführen. Und siehe da: Es wurde folgende, sehr verdächtig klingende Konfiguration mit einem gelben Ausrufezeichen hervorgehoben:

Wie im TechNet beschrieben, kann der Wert für Probleme im Zusammenhang mit ActiveSync sorgen und sollte deshalb an folgender Stelle in der Registrierung einfach deaktiviert bzw. wieder auf Null gesetzt werden:

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA\DisableSMTPMailboxAddressing

Nach Entfernen des Wertes und Neustart des Server-Dienstes ließ sich das Problem 1a reproduzieren. Ist der Wert vorhanden, funktioniert der Aufruf von Outlook Web Access nur ohne explizite Angabe oder mit dem Benutzernamen im Pfad. Ohne den Wert klappt es dagegen auch mit der E-Mail-Adresse.

Update: Offenbar lässt sich Outlook Web Access gar nicht über den Benutzernamen, sondern nur über ein gültige E-Mail-Adresse aufrufen.

Wird statt einer vollständigen E-Mail-Adresse nur der localpart angegeben, funktioniert dies nur, wenn eine entsprechende E-Mail-Adresse mit eben diesem localpart und der Default Domain existiert [1].

Beispiel: Benutzer michael.jackson (UPN michael.jackson@domain.local) mit E-Mail-Adresse michael.jackson@domain.de (Default Domain).

In diesem Fall kann MailStore die Verbindung zum Postfach nur herstellen, wenn als Benutzername “michael.jackson” angegeben wird (da eine entsprechende E-Mail-Adresse mit der Default Domain existiert). Bei der Angabe des UPN (michael.jackson@domain.local) kommt es dagegen zur beschriebenen Fehlermeldung, wenn der User nicht über eine entsprechende Adresse verfügt. Die Angabe in Form von DOMAIN\user funktioniert ebenfalls nicht.

[1] Es muss übrigens nicht zwingend die Default Domain sein. Es ist vielmehr die Domain, die im ESM unter “Protokolle” -> “HTTP” -> “Virtueller Exchange-Server” -> “Exchange” konfiguriert ist.

Probleme mit Exchange 2003 nach Migration auf Windows Server 2008 R2 Active Directory?

Laut Exchange Server Supportability Matrix wird der Betrieb von Exchange 2003 in einem Active Directory auf Basis von Windows Server 2008 R2 offiziell unterstützt. Trotzdem finden sich einige Beiträge im Internet, die von Problemen mit Exchange nach erfolgter Migration der Domänencontroller auf 2008 R2 berichten. So wird im Artikel Exchange 2003 SP2 on 2008 R2 domain? Not so fast beschrieben, dass nach dem Upgrade keine Mailboxen mehr erstellt werden konnten und eine Migration auf Exchange 2010 erforderlich war.

Da ich vor einer ähnlichen Migration stehe, habe ich das in einer kleinen Testumgebung mal durchgespielt und dabei nach jedem einzelnen Schritt auf Probleme im Zusammenhang mit Exchange geachtet. Die Testumgebung besteht aus dem Windows Server 2003 Domänencontroller DC01 und dem Exchange Server 2003 EX01.

Schritt 1: Gesamtstruktur- und Domänenvorbereitung mit adprep32.exe

Auf DC01 werden mittels adprep32.exe /forestprep und adprep32.exe /domainprep /gpprep Gesamtstruktur und Domäne für 2008 R2 vorbereitet. Dabei wird das Schema auf Version 47 aktualisiert. Eine detaillierte Beschreibung gibt es auf Yusufs Directory Blog: Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen.

Ergebnis: Keine anschließenden Probleme mit Exchange.

Schritt 2: Hinzufügen eines Windows Server 2008 R2 Domänencontrollers

Da der bestehende Domänencontroller nicht durch ein Inplace-Update auf 2008 R2 aktualisiert werden kann, wird ein zusätzlicher Server (DC02) mit 2008 R2 installiert und mittels dcpromo zum Domänencontroller hochgestuft.

Ergebnis: Keine Probleme. Der neue Domänencontroller wird von Exchange zudem erfolgreich als Global Catalog verwendet.

Schritt 3: Transfer der FSMO-Rollen von DC01 nach DC02

Bevor DC01 zum Memberserver heruntergestuft werden kann, sollten die FSMO-Rollen über die entsprechenden Snap-Ins der MMC oder mittels ntdsutil.exe auf DC02 verschoben werden. Zwar kann dcpromo das bei der Herabstuftung von DC01 auch automatisch durchführen, ausprobiert habe ich das aber noch nicht. Auch von Yusuf genau dokumentiert: Die FSMO-Rollen verschieben.

Ergebnis: Keine Probleme.

Schritt 3: Herabstufen von DC01 zum Memberserver

Nach dem Transfer der FSMO-Rollen kann DC01 heruntergestuft und damit die Active Directory-Dienste vom Server entfernt werden. Im Active Directory der Testumgebung existieren damit keine Domänencontroller mehr auf Basis von Windows Server 2003.

Ergebnis: Probleme! Wie im oben genannten Artikel beschrieben, werden Mailboxen beim Anlegen eines neuen Benutzers nicht erstellt und keine Mailadressen mehr generiert. Bei der Angabe des entsprechenden Benutzers in Outlook erscheint die Meldung, dass der Benutzer in der Adressliste nicht existiert. Wie kommt es dazu?

Eine lebenswichtige Komponente zwischen Exchange 2003 und dem Active Directory ist der Recipient Update Service (RUS). Der auf Deutsch genannte “Empfängeraktualisierungsdienst” versieht z.B. Objekte mit Mailadressen, wenn diese bislang noch keine hatten bzw. neu angelegt wurden. Damit das funktioniert, benötigt der RUS eine funktionierende Verbindung zum Active Directory.

Standardmäßig werden bei der Installation von Exchange zwei RUS-Einträge erstellt: Der Enterprise RUS für die allgemeine Aktualisierung der Exchange Systemobjekte und der Domain RUS für die Aktualisierung der Empfänger einer Domäne. Beide Einträge verweisen auf einen Domänencontroller. Ist dieser, wie nach dem Herunterstufen von DC01, nicht mehr verfügbar, kann der RUS keine Verbindung zum Active Directory mehr herstellen und es kommt zu den geschilderten Problemen.

Glücklicherweise ist es ein Leichtes, im Exchange System Manager den Domänencontroller zu ändern oder, falls mehrere DC verfügbar sind, zusätzliche RUS-Einträge vorzunehmen. Unmittelbar nach Ersetzen von DC01 durch DC02 wurden die fehlenden Adressen generiert und die Mailboxen erstellt.

Stellt sich jetzt noch eine Frage: Welche Folgen hat das Heraufstufen der Funktionebenen auf 2008 R2?

Schritt 4: Anheben der Funktionsebenen auf Windows Server 2008 R2

Nachdem keine Domänencontroller mit Windows Server 2003 mehr existieren, können die Funktionsebenen von Gesamtstruktur und Domäne in den entsprechenden Snap-Ins auf Windows Server 2008 R2 angehoben werden.

Ergebnis: Keine Probleme!

Es bleibt also festzuhalten: Ein explizites Problem mit Exchange 2003 in Verbindung mit Windows Server 2008 R2 Active Directory gibt es nicht. Bei einer entsprechenden Migration sollte man allerdings die Abhängigkeit des RUS nicht aus den Augen verlieren.

Generell zum Thema empfehlenswert sind übrigens der Artikel W2K3 to W2K8 and W2K8R2 Active Directory Upgrade Considerations von Glenn LeCheminant und das OpenBook Windows Server 2008 R2 von Galileo Computing.