Replication Boost in Active Directory 2025
Eines der neuen Features, welches mit Active Directory 2025 angekündigt wurde, ist der „replication boost„.
Der Replication Priority Boost (RPB) ist ein Lenkungsinstrument, welches eingesetzt werden kann, wenn die bisherige Replikationsheuristik nicht ausreichend ist.
Die bisherige Replikationsheuristik hat die RWDCs, mehr oder minder, über den gleichen Kamm „geschoren“. Der KCC berechnet zwar die Topologie gemäß den Eigenschaften eines DCs (Betriebsmaster, globaler Katalog, DNS-Server und Application Partition), jedoch kann dieses paritätische Prinzip nicht immer geeignet sein.
Eines dieser Einsatzszenarien vom RPB kann es sein, wenn man möchte, dass ein Replikat vorab nur zu einem Replikationspartner geht und nicht zu allen gemäß der aktuellen Topologie.
RPB ist grundsätzlich bei DCs mit Server 2025 als Betriebssystem verfügbar, es wird aber auch das Szenario zwischen einem Quell-DC mit Server 2022 und einem Ziel-DC mit Server 2025 bedient.
Quizz-Frage:
Welches ist der am höchsten priorisierte Namenskontext im Active Directory?
Configuration!
Voraussetzungen für den Replication Boost
Der Replication Boost ist grundsätzlich ab Server 2025 als Domain Controller verfügbar. Das bedeutet:
- Domain Functional Level muss 2016 oder höher sein
- Forest Functional Level muss 2016 oder höher sein
- Das Active Directory Schema muss auf 2025 erweitert worden sein
Wobei gemäß Microsoft auch ein Server 2022 als Domain Controller „ge-boostet“ werden kann.
Den Transistions-Pfad zu Server 2025 als Domain Controller inklusive aufräumen und grundlegender Sicherheit kann man hier erlernen: Essential Active Directory 2025
Einrichten des Replication Boost
Der Replication Boost wird, wahlweise, über ldifde.exe (per LDF-Datei) oder per ldp.exe eingerichtet.
Bevor man den Replication Boost konfiguriert, muss man sich über drei Punkte im Klaren sein:
- Welcher Namenskontext (NC) soll geboostet werden?
- Welcher Quell-DC, der jenen Namenskontext hält, soll geboostet werden?
- Wie soll geboostet werden?
ldp.exe und ldifde.exe
Mit der LDP.exe die Konfiguration simpel:
- Verbindung mit dem Quell-DC herstellen (TCP 389 oder TCP 636)
- Steuerung / Control + M
- DN: leer lassen
- Attribute: setPriorityBoost
- Values: DC=CLOUD-HYBRID,DC=DE:7CC19B7A-2657-4F3A-9AC0-7C3C44EC0CA0:2
- Operation: Add
- Enter
- Run
Bei der LDF-Datei ist die Syntax wie folgt:
dn:
changetype: modify
add: setPriorityBoost
setPriorityBoost: DC=CLOUD-HYBRID,DC=DE:7CC19B7A-2657-4F3A-9AC0-7C3C44EC0CA0:2
-Danach die LDF-Datei per ldifde.exe importieren:
ldifde.exe -i -f .\RepBoost.ldf -s CH-VDC04Und nun?
Tja, spannende Frage.
Ich habe eine einfache Teststellung aufgebaut mit einem Forest, einer Domäne, sechs Read-Write Domain Controller, jeweils zu dritt ein zwei Sites (HQ und Branch). Die Default-Einstellungen des AD habe ich unverändert übernommen.
Dieses wunderschöne Visio-Diagramm habe ich nicht nur mit Visio, sondern mit dem Active Directory Topology Diagrammer (ADTD) erstellt.
Bedeutet: wird ein Objekt in der Site HQ oder BRANCH erzeugt, benötigt dieses maximal 180 Minuten, bis es in die andere Site repliziert wird.
Also:
- der CH-VDC02 wurde geboostet.
- auf dem CH-VDC02 wurde ein Objekt erzeugt (Kontakt ReplTest1)
- ich beobachte die Replikation und die Dauer der Replikation
CH-VDC02
nach 15 Sekunden wird der erste Replikationspartner (CH-VDC03) per change notification benachrichtigt.
Der zweiter Partner wird nach weiteren 3 Sekunden (jetzt 18 Sekunden in Summe) per change notification benachrichtigt.
CH-VDC03
Nach 15 Sekunden: Pullreplikation von CH-VDC02 + change notification zum CH-VDC01
CH-VDC01
nach 18 Sekunden: Pullreplikation von CH-VDC02 + change notification zum CH-VDC03
Die change notification vom CH-VDC03 wird hier ignoriert (gleiche originating USN).
Nach weiteren maximal 180 Minuten wird über den Site-Link repliziert, CH-VDC01 ist ein outbound bridge head server
CH-VDC04
Nach maximal 180 Minuten und 18 Sekunden empfängt der CH-VDC04 als inbound bridge head server das Replikat.
CH-VDC04 benachrichtigt nun im 3 Sekundenabstand seine Replikationspartner per change notification.
CH-VDC06
Nach maximal 180 Minuten un 21 Sekunden empfängt CH-VDC06 das Replikat per pull replication und sendet eine change notification an CH-VDC05
CH-VDC05
Nach maximal 180 Minuten und 24 Sekunden empfängt CH-VDC07 das Replikat von CH-VDC04 per pull replikation und sendet eine change notification an CH-VDC06.
Die change notification von CH-VDC06 wird aufgrund der identischen originating USN irgnoriert.
Where's the boost?
Ehrlich gesagt: ich weiß es nicht!
Die ganze Replikation hat 8692 Sekunden gedauert (die 855 Ticks lasse ich einfach unter den Tisch fallen, die Katze kann sich die holen). Das ist in dieser Konstellation die ganz nomale Latenz im Active Directory. Über die Bordmittel per Attribute options, msDS-Replication-Notify-First-DSA-Delay und msDS-Replication-Notify-Subsequent-DSA-Delay geht mehr, viel mehr bzw. viel schneller.
Mit den Optimierungen, welche ich seit Jahren predige und praktiziere, wäre ich dieser Topologie die Änderung in unter 10 Sekunden durch.
Dennoch: nur weil das bei mir im Labor keinen messbaren Wert in der Replikation hat, muss das nicht heißen, dass es nichts bringt. Ggf. habe ich es falsch umgesetzt oder messe etwas vollkommen falsches.
Wir werden sehen, aktuell kann ich aber keinen „boost“ in der Replikation feststellen.
ComputerLogbuch der IQunit, Sternzeit -297667.6959665144, Captian Handl
Der „call to action“ soll sich wie ein roter Faden durch meine Blogartikel ziehen, so das Kommando der Sternenflotte der Vertrieb.
Bitteschön: Essential Active Directory 2025 – im Kapitel Advanced Site Management
Da hab ich mal eine Frage. Wie sollen msDS-Replication-Notify-First-DSA-Delay und msDS-Replication-Notify-Subsequent-DSA-Delay die Zeiten beschleunigen, wenn die meiste Zeit durch den Standard Wert von 180min. für die Mitteilung von Änderungen für Site Links gesetzt ist. Das änderen doch die beiden Parameter nicht.
Und soviel ich weiß kann ich das per GUI bis 15min. herabsetzen.
Vielleicht fehlen mir einfach die Zusammenhänge. Könntest du das hier kurz erklären oder ein Tipp geben wonach ich da suchen muss bei der Microsoft Doku?
msDS-Replication-Notify-First-DSA-Delay und msDS-Replication-Notify-Subsequent-DSA-Delay beeinflussen die INTRA-Site-Replikation, die Replikation innerhalb einer Site.
Ich empfehle hier seit bestimmt 15 Jahren die Werte pro Partition auf „1“ (= eine Sekunde Latenz) zu setzen.
-> msDS-Replication-Notify-First-DSA-Delay entspricht der initialen Verzögerung von 15 Sekunden (Default)
-> msDS-Replication-Notify-Subsequent-DSA-Delay entspricht der initialen Verzögerung von 3 Sekunden (Default).
Bei der INTER-Site-Replikation, bei der Replikation zwischen Standorten wird dieses über zwei Attribute am Site-Link gesteuert:
1) options: sollte immer auf „7“ (= Change notification, reziproke Replikation und keine Komperssion) gesetzt sein und
2) ReplInterval: sollte immer auf „1“ (= ein Mal pro Minute wird repliziert) gesetzt sein.
Wenn die Details hierzu interessieren, kann ich meinen Workshop dazu empfehlen.
😉
Danke für den Wink du meinst sicher die AD Schulung. Ich versuche die Freigabe für die Schulung zu bekommen. Daumen drücken das es klappt. Privat ist es mir bissel teuer für mal aus Interesse …
Dann schlage ich vor, ich post nächste Woche einen Artikel zum Thema „Turbolader für Active Directory„.
Dort beschreibe ich dann, wie man die Replikationsgeschwindigkeit ohne Replication Boost schneller bekommt.