Exchange Server ist eine der wenigen verbliebenen Server Applikationen, die eine hohe Active Directory Integration aufweisen. Zahlreiche Konfigurationen sind in der Active Directory Konfigurationspartition gespeichert, um einen sicheren und stabilen Betrieb zu gewährleisten.
Active Directory ist als verteiltes Verzeichnissystem konzipiert, um den Betrieb einer einzelnen (Remote-) Site auch dann sicherzustellen, wenn die Verbindung zur Haupt-Site unterbrochen wird. Um die AD-Funktionen zu gewährleisten, besitzt jeder Domain Controller eine Replik (Kopie).
Zur Erinnernung:
Active Directory Domain Services provide multi-master update. Multi-master update means that all full replicas of a given partition are writable (the partial replicas on global catalog servers are not writable.) Multi-master update means that updates are not blocked even when some replicas are inoperable. The Active Directory server propagates the changes from the updated replica to all other replicas. Replication is automatic and transparent.
Microsoft Dokumentation – Replication and Data Integrity
Und genau hier beginnt unser Problem.
Das Problem
Wenn ein Exchange Server Kumulatives Update (CU) oder eine Sicherheitsaktualisierung (SU) zeitgleich auf mehr als einem Server installiert werden, tritt folgendes Phänomen auf.
Jedes CU oder SU aktualisiert RBAC-Managementrollen. Diese vermeintliche Aktualisierung besteht jedoch aus einer Löschung und einer Neuanlage der Rolle. Das Dilemma ist, dass bei einer einfachen Ausführung der CU- oder SU-Installation ein beliebiger Domain Controller ausgewählt wird, um Änderung am Active Directory durchzuführen. Diese Änderungen werden anschließend zu den anderen Domain Controllern repliziert.
Wird die Installation nun zeitgleich auf mehreren Exchange Servern ausgeführt, kommt es zu Replikationskonflikten und zu verwaisten Einträgen in der Active Directory Konfigurationspartition, wie der nachfolgende Screenshot zeigt.
Im Screenshot siehst du drei EInträge für die RBAC-Rolle “Reset Password”. Die beiden ersten Einträge enthalten den Zusatz CNF:GUID. CNF steht in diesem Zusammenhang für Conflict. Dank der bereits erwähnten Multi-Master-Replikation gewinnt immer der letzte Objekteintrag. Alle vorherigen (älteren) Einträge werden als Konflikt markiert. Es ist spannend dass vor der CNF:GUID Ergänzung auch noch ein New Line (Hex 0A, Dezimal 10) eingefügt wird. Dies ist der Grund für die nette Darstellung in der PowerShell-Ausgabe.
Zur Sicherheit habe ich noch einen Blick in die Active Directory Konfigurationspartition geworfen, um mir die Objekte etwas genauer anzuschauen. Das Ergebnis siehst du im folgenden Screenshot.
Das Problem solcher CNF-Einträge ist nicht spezifisch für Exchange Server, sondern ein allgemeines Active Directory Phänomen. Die kannst CNF-Einträge nicht nur in der Konfigurationspartition finden, sondern auch in der Standard-Partition. Solche Einträge meist ein Indiz für eine schlecht konfigurierte Active Directory Replikation oder, wie in unserem Fall, eine unbedachte Ausführung des Exchange Setups.
Die Lösung
Die CNF:GUID-Einträge gilt es aufzuräumen. ADSIEdit ist in diesem Fall das Werkzeug der Wahl.
HINWEIS
Die Nutzung von ADSIEdit ist immer mit einem Risiko verbunden. Ctrl-Z steht nicht zur Verfügung. Lösche Einträge daher mit Bedacht. Eine Haftung für fehlerhaftes Löschen von Objekten kann aus verständlichen Gründen nicht übernommen werden.
Öffne die Konfigurationspartition mit ADSIEdit und erstelle eine neue Suchabfrage mit dem Suchstring
(cn=*cnf:*)
Wähle die Exchange Organisation, im Beispiel ist es VARUNAGROUP, als Basis für die Suche aus und speichere die Abfrage. Anschließend kannst du im Ergebnisfenster die gefundenen Einträge löschen. Stelle sicher, das CNF im Namen wirklich vorkommt.
Alternativ kannst du auch direkt in den RBAC-Knoten navigieren und die Konflikteinträge dort löschen.
Für die Zukunft
Aber wie kannst du nun vermeiden, dass diese Replikationskonflikte erneut auftreten, wenn du ein CU oder SU gleichzeitig auf mehreren Exchange Servern ausführst?
Bei der Installation eines kumulativen Updates ist dies recht einfach. Installieren ein CU immer per Kommandozeile und ergänze den Installationsaufruf um den Parameter /DomainController oder /dc. Ohne die explizite Angabe eines Domain Controllers verwendet das Setup einen zufällig ausgewählten Domain Controller aus der gleichen Active Directory Site, in der sich der Exchange Server befindet.
Ein Beispiel
Setup.exe /Mode:Upgrade /dc:dc01.varunagroup.de /IAcceptExchangeServerLicensesTerms_DiagnosticDataOnDie zufällige Auswahl eines Domain Controllers aus der gleichen AD-Site macht das Thema AD-Replikation noch etwas spannender, wenn du ein CU oder SU gleichzeitig in zwei unterschiedlichen Sites installierst.
Leider unterstützten die Installationspakate der Exchange-Sicherheitsupdates die Angabe eines expliziten Domain Controllers nicht. Hier kann ich nur empfehlen, die Installation zu serialisieren und einen Server nach dem anderen zu aktualisieren.
Dank
Ein großer Dank für das Teilen dieses Phänomens geht an einen Microsoft Exchange DSE.
Links
- Naming Contexts and Directory Partitions
- Replication and Data Integrity
- Seek and Destroy duplicate AD objects with CNF in the name
- Active Directory: Duplicate Object Name Resolution
- Unbeaufsichtigte Installation von Exchange Server
Viel Spaß mit Exchange Server.
