Exchange steht nicht neben Active Directory, sondern mittendrin. Postfächer, Verteiler und Datenbanken sind AD-Objekte mit Mail-Attributen; Schema, Konfiguration und Adressbuch leben in denselben Partitionen, aus denen auch die restliche Domäne kommt. Wenn DNS, Global Catalog oder die Standortzuordnung haken, merkt man das oft zuerst am Mailserver – nicht an einem Benutzerlogin.
Was Exchange im AD erwartet
Bei der Vorbereitung der Gesamtstruktur schreibt Exchange seine Klassen und Attribute ins Schema (msExch*). Danach liegen Server, Verwaltungsgruppen und Empfängerrichtlinien unter der Configuration-Partition. Das Adressbuch und Autodiscover beziehen ihre Daten vom Global Catalog; der Service Connection Point in AD zeigt Clients den richtigen Exchange-Endpunkt.
Praktisch heißt das: Jeder Exchange-Server braucht mindestens einen erreichbaren Domänencontroller in seiner AD-Site, einen Global Catalog und eine stimmige DNS-Auflösung. Zeitdrift zwischen DC und Exchange bringt Kerberos und damit fast alles zum Stehen.
Kurzer Gesundheitscheck
Ob Exchange die richtigen DCs sieht:
Ob die Site und der GC aus Sicht des Betriebssystems passen:
Wenn hier ein DC aus einer anderen Site oder gar kein GC auftaucht, lohnt sich zuerst die Active-Directory-Standorte und -Dienste-Konsole – nicht die Exchange-Warteschlange.
Empfänger und das Schema
Wird ein Postfach angelegt, schreibt Exchange die Mail-Attribute direkt ins Benutzerobjekt. Hängt die Recipient Update, fehlen oft mailNickname, Proxy-Adressen oder die Richtlinien-GUIDs. Ein Blick auf das Objekt im AD zeigt dann schneller den Fehler als ein isolierter Exchange-Log.
Die Schema-Version der Organisation (nützlich nach CU-Updates oder einer fehlgeschlagenen Vorbereitung) lässt sich so ablesen:
Stimmt der Wert nicht zur installierten Exchange-Version, war Setup /PrepareAD unvollständig – und nicht der Informationsspeicher das eigentliche Problem.
Kurz: Bei merkwürdigem Exchange-Verhalten zuerst AD, DNS und GC prüfen. Oft ist der Mailserver nur der Bote.