AD Sitelink Replication Notification

Ein Exchange Administrator muss auch über das Active Directory Bescheid wissen, denn viele „Effekte“ und Probleme von Exchange sind oftmals im Active Directory oder sogar in DNS begründet. Auf dieser Seite möchte ich einen Einblick in die Probleme größerer Umgebungen geben. Auch wenn ich denke, dass die meisten MSXFAQ-Leser dies nicht benötigen so zeigt es gut die Abhängigkeiten zwischen Exchange und AD.

Grundlagen der Replikation

Die AD-Replikation unterscheidet zwischen „Same Site“ und „Inter-Site“. Alle DCs in der gleichen AD-Seite bilden Replikationsringe von bis zu 5 DCs in einem Ring, die Änderungen sehr schnell replizieren. Ca. 5 Sek (300 bei Windows 2000) nach einer Änderung informiert der DC seine Partner über Änderungen , die dann per Replikation die Änderungen beziehen.. In der Regel dauert es daher nicht länger als 20 Sek, bis alle DCs (win2003 und höher) in der gleichen Site ein Update bekommen haben.

Anders sieht es aus, wenn DCs in unterschiedlichen Sites stehen. Der KCC erstellt dann anhand der konfigurierten „SiteLinks“ entsprechende Partnerschaften, die die Replikation zwischen den Standorten steuern. Per Default sind hier 180 Minuten eingetragen, die aber per GUI bis auf 15 Minuten zwischen zwei Sites gesenkt werden können. Dabei handelt es sich aber um einen „Zeitplan“. Per Default gibt es keine Benachrichtigungen.

Es gibt Umfelder, in denen die Verzögerung nicht wünschenswert ist und die Belastung der DCs und Bandbreiten nicht dagegen sprechen, dass zwischen den beiden Sites häufiger repliziert wird. Es ist seit Windows 2003 möglich, diese „Change Notification“ auch zwischen Sites zu aktivieren. Dazu muss aber im Feld „Options“ ein Bit gesetzt werden. Wer also ADSIEDIT nicht gut kennt und mit dem Binärsystem auf Kriegsfuß steht, sollte doppelt vorsichtig sein. Die Einstellung wird pro Sitelink aktiviert. Wenn dann eine Änderung auf einem DC passiert, dann informiert er auch über Sitegrenzen hinweg die Partner. Aber nicht alle gleichzeitig sondern etwas verzögert und auch die Partner, die die Daten holen müssen, starten nicht sofort. So soll verhindert werden, dass ein Bridgehead-DC vielleicht unter der Last der Anfragen in die Knie geht. Je größer eine Umgebung ist, desto genauer sollten Sie daher die Belastung der DCs beobachten.

Hinweis:
Diese Notification greift nur für „automatisch durch den KCC erstellte Links“. Wer also Sitelinks manuell erstellt, ist für diese Verbindungen weiter auf die 15 Minuten Intervalle festgelegt.

Negativbeispiel: Eine eigene Exchange-Site und Exchange Domäne

In vielen Microsoft Dokumenten wird empfohlen, dass besonders in größeren Installationen die Exchange Server in einer eigenen AD-Site platziert werden und dedizierte DCs/GCs in dieser Site aufgebaut werden. So benutzen die Exchange Server auch nur die DCs in dieser Site und "belästigen" nicht die DCs, die von Anwendern zur Anmeldung benutzt werden. Umgekehrt wird die Performance der DCs in der Exchange Site nicht durch Anmeldeverkehr von Clients belastet. Sie könnten sogar die DCs in der Site per Firewall von den Clientnetzwerken abschotten und so Angriffe (primär DoS) verhindern. Eine weitere Sicherheit können Sie erreichen, indem die Exchange Server in einer eigenen Subdomäne stehen. Die DCs dazu haben Sie ja schon in der Exchange Site. Dann sind nämlich die Domänen Administratoren der Anmeldedomäne nicht zugleich Domänen Administratoren in der Exchange Server Domäne.

So schön diese Konstruktion erscheint, so gut eignet sie sich die Probleme von mehreren Sites mit einer eigenen Domäne für Server an einem konkreten Beispiel zu erläutern. Dazu eignet sich z.B. die Exchange ActiveSync Quarantäne (Siehe EAS Quarantäne), bei der Mobilgeräte erst durch privilegierte Personen freigeschaltet werden müssen. Die Umgebung entspricht dem Bild:

  • Site: "Hauptsite"
    Enthält alle DCs der Anmeldedomäne, die Benutzer, Workstations etc.
  • Site: Exchange
    Enthält DCs/GCs für die Exchange Server in der „Exchange-Domäne". Hier steht auch der CAS-Server.
  • Exchange EAS Quarantäne ohne automatische Regel ist aktiv
    Neue Geräte können also nicht direkt lossynchronisieren, sondern müssen erst freigegeben werden.

Nun schauen wir uns die Schritte genauer an, die bei der Verbindung eines neuen Mobilgerätes durchlaufen werden:;

  1. Anwender richtet ein neues Gerät ein
    Per Autodiscover oder manueller Eingabe des Servers und der Anmeldedaten startet eine HTTPS-Transaktion mit dem CAS-Server
  2. Exchange CAS trägt das Gerät beim Benutzer ein mit Status „Quarantäne“
    Der CAS-Server prüft, ob das Gerät für den Benutzer freigegeben ist, indem er vom lokalen GC die Liste der "AllowedDevices" abfragt. Das Gerät ist nicht vorhanden, also legt Exchange ein neues Gerät beim Benutzer an. Dazu schreibt der CAS in die Domänenpartition der Benutzerdomäne, von der die DCs aber in der Hauptsite stehen.
  3. Exchange sendet eine Mail an den Helpdesk zur Prüfung der Quarantäne
    Parallel informiert Exchange die konfigurierten Mailadressen über ein neues Gerät in der Quarantäne.
  4. Helpdesk schaut in die Quarantäne und... muss warten
    In der Regel nutzt der Helpdesk das Exchange Control Panel (/ECP), um die Gerät in der Quarantäne zu kontrollieren und gegebenenfalls freizugeben. Die Funktion führt die Exchange CAS-Rolle aus, welche natürlich die GCs in der lokalen Site befragt.
    Erst nachdem die Änderungen am Benutzer in der zentralen Site in die Exchange Site repliziert wurden, kann der Helpdesk das Gerät auch in ECP sehen
  5. Helpdesk gibt Gerät frei
    Wenn der Helpdesk nun endlich das Gerät in der Quarantäne entdeck, kann er es auch frei geben. Technisch schreibt auch hier wieder das CAS ein LDAP-Feld beim Benutzer auf einem DC in der Benutzerdomäne in der Hauptsite.
    Schon klar, dass es nun wieder einige Zeit dauert, bis diese Information letztlich auch auf den DC/GCs in der Exchange Site erscheinen.
  6. Anwender kann endlich replizieren
    Erst wenn die CAS-Rolle in seinem DC die geänderte Konfiguration findet, kann kann das mobile Gerät endlich auch Nutzdaten replizieren.

Sie sehen also, das gerade die Replikation zwischen Sites in solchen Umgebungen unschöne Effekte haben kann. Das betrifft auch andere Prozesse rund um Exchange. Alle Änderungen am Benutzer (.z.B. POP3 ein/ausschalten, Quotas ändern, Mailadresse ändern) aber auch die Änderung von Verteilermitgliedschaften etc. werden von den Exchange Servern erst gesehen, wenn die Information auch in der eigenen Exchange Site angekommen ist. Nur Änderungen an der Konfiguration werden von den Exchange Commandlets auf einem „nahen DC“ vorgenommen, der eine schreibbare Partition der „cn=configuration,dc=domain,dc=tld“ hat.

Und bei einer Single Domain ?
Auch hier kann es zu Problemen kommen, wenn das Provisioning der user oder die Pflege der Gruppenmitgliedschaften mit FIM oder einem anderen Tool in der user-Domäne erfolgt und Exchange diese Änderungen erst verzögert sieht.

Konfiguration

Sie haben nun aber schon weiter oben gelesen, dass Windows 2003 und höher hier eine Lösung über die Funktion "AD Sitelink Notification" haben. Wird diese Funktion eingeschaltet, dann sendet ein DC bei Änderungen eine Information auch über Sitelinks an DCs in anderen Sites, die ihrerseits dann nach kurzer Zeit die Änderungen replizieren. Das Ziel dabei ist, die bislang bis zu 15 Minuten Verzögerung zu reduzieren.

Die Change Notification wird immer pro IP-Sitelink eingestellt. Ein Sitelink ist keine direkte Verbindung zwischen zwei Servern aus unterschiedlichen Sites, die Sie mit „Active Directory Sites and Services“ auch manuell eintragen können sondern eher ein Hinweis, wie das Active Directory zwei Standorte miteinander verbinden soll. Es ist dann die Aufgabe des KCC, entsprechend die erforderlichen Verbindungen zwischen den Server einzurichten. Bei wenigen Sitelinks können Sie die Einstellung auch mal schnell per ADSIEDIT vornehmen. Sie müssen dazu einfach auf dem entsprechenden Sitelink in der Configuration-Partition das Feld "Options" setzen

ADSIEDIT zeigt ihnen die aktuellen Optionen auch an. Es ist aber ein numerischer Wert, in dem jedes Bit eine eigene Bedeutung hat:

Bit Wertigkeit Bedeutung Beschreibung

0

1

USE_NOTIFY

Dieses Bit ist zu setzen, damit eine Benachrichtigung an DCs in andere Standorte gesendet wird, die über diesen Sitelink verbunden sind.

1

2

TWOWAY_SYNC

Mit diesem Bit wird durch den Trigger eine bidirektionale Replikation gestartet. Heute kaum benötigt aber denken Sie mal an "Dialup"-Verbindungen. Wenn die Verbindung durch einen Trigger schon mal steht, dann kann die quasi angefangene Einheit auch in beide Richtungen genutzt werden

2

4

DISABLE_COMPRESSION

Compression "kostet" CPU-Leistung und wenn DCs schwach ausgestattet sind und die Kosten für mehr Datenvolumen einfacher zu tolerieren sind, kann damit die Kompression abgeschaltet werden.

Der effektive Wert berechnet sich also aus der Addition der Bitwerte. In der Regel ist das Feld aber "leer" und damit ist keine der Optionen aktiv. Um den Sitelink zu triggern reicht es aus, den Wert auf 0x1 zu setzen. Die Einstellungen werden aber auch nicht „sofort“ aktiv. Zumindest die Server der entfernten Site benötigen erst eine normal schnelle Replikation, bis die Konfiguration dort auch ankommt.

Weitere Links