Topologie & Replikation: Sites, FSMO und Global Catalog
Einführung · 8 Abschnitte · ~8 Min Lesezeit · Stand
Die physische Sicht: Sites, DCs und Site-Links
Die logische AD-Struktur (Forest, Domäne, OU) sagt nichts darüber, wo die Domain Controller stehen und wie sie sich synchronisieren. Dafür gibt es die physische Topologie: Sites sind Gruppen gut angebundener Subnetze (typisch ein Standort), verbunden über Site-Links, die die WAN-Strecken abbilden.
AD repliziert Multi-Master — jeder DC ist beschreibbar, Änderungen konvergieren zu allen anderen. Innerhalb einer Site repliziert AD fast sofort (Change Notification), zwischen Sites nach Zeitplan und Intervall, damit die WAN-Leitung nicht dauernd belastet wird. Welche Verbindungen dafür entstehen, plant AD selbst über den KCC (Knowledge Consistency Checker) und pro Site den ISTG (Inter-Site Topology Generator).
FSMO: fünf Rollen, die nicht Multi-Master sind
Einige Operationen vertragen keine parallelen Änderungen an verschiedenen DCs. Für sie gibt es FSMO-Rollen (Flexible Single Master Operations): fünf Sonderaufgaben, die zu jedem Zeitpunkt genau ein DC hält. Zwei sind forest-weit (einmal pro Forest), drei domänenweit (einmal pro Domäne).
| **Schema Master** (forest-weit) | einziger DC, der das Schema ändern darf. Nötig bei Schema-Erweiterungen, z. B. adprep /forestprep vor einer App-Installation. |
|---|---|
| **Domain Naming Master** (forest-weit) | kontrolliert das Hinzufügen/Entfernen von Domänen und Anwendungspartitionen im Forest. |
| **RID Master** (domänenweit) | vergibt RID-Pools an die DCs, damit jeder eindeutige SIDs für neue Objekte bilden kann. |
| **PDC-Emulator** (domänenweit) | Passwort-Sonderpfad, autoritative Zeitquelle, Account-Lockout, Standardziel fürs GPO-Editing. Kein „Master“. |
| **Infrastructure Master** (domänenweit) | aktualisiert domänenübergreifende Objektverweise. In Multi-Domain-Forests nicht auf einen GC legen (außer alle DCs sind GC). |
Transfer vs. Seize: die riskanteste Ops-Entscheidung
FSMO-Rollen haben kein automatisches Failover. Fällt der Inhaber aus, musst du entscheiden, wie die Rolle woanders hinkommt:
- Transfer (geordnet): der aktuelle Inhaber lebt und übergibt die Rolle sauber. Der Normalfall — etwa vor einer geplanten Außerbetriebnahme.
- Seize (erzwungen): der Inhaber ist dauerhaft weg und kommt nicht zurück. Die Rolle wird einem gesunden DC zugewiesen, ohne dass der alte zustimmt.
Sites & Subnets: Authentifizierung lokal halten
Clients finden ihren DC nicht über eine feste Adresse, sondern über den DC-Locator: Sie fragen DNS nach passenden SRV-Records. Damit ein Client den DC in seiner eigenen Site bekommt (statt irgendeinen über die WAN-Leitung), muss AD sein Subnet kennen und einer Site zuordnen.
Fehlt die Subnet-zu-Site-Zuordnung, ist der Client „ohne Site“: Der DC-Locator kann keine Lokalität herstellen, und Anmeldung, GPO-Verarbeitung und DFS laufen womöglich quer über die WAN-Strecke an einen entfernten DC — langsam und fragil.
Global Catalog & Universal-Group-Caching
Der Global Catalog (GC) ist ein DC, der zusätzlich eine partielle Kopie aller Objekte des gesamten Forests hält. Beim interaktiven Logon werden die Universal-Group-Mitgliedschaften eines Nutzers ermittelt — und die kann nur der GC forest-weit auflösen. Ist an einem Standort kein GC erreichbar, kann eine Anmeldung scheitern.
Für kleine Zweigstellen an dünnen/unzuverlässigen Leitungen gibt es die leichtgewichtige Alternative UGMC (Universal Group Membership Caching): pro Site aktivierbar, cacht der lokale DC die Universal-Group-Mitgliedschaften nach dem ersten Logon und frischt sie standardmäßig alle 8 Stunden gegen einen GC auf. So funktionieren Anmeldungen auch bei WAN-Ausfall — ohne die volle GC-Replikation über die Leitung zu ziehen.
Replikationstopologie tunen — ohne den KCC zu umgehen
Die Inter-Site-Replikation steuerst du über drei Site-Link-Parameter: Kosten (der KCC bevorzugt den günstigsten Pfad, wenn mehrere Wege existieren), Intervall (wie oft repliziert wird — Standard 180 Minuten, Minimum 15) und Zeitplan (in welchen Fenstern überhaupt). Der KCC baut daraus automatisch die Verbindungsobjekte.
Zu langsame Konvergenz? Intervall senken und Zeitplan öffnen. Falscher Pfad? Kosten korrigieren. Was du nicht dauerhaft tust: von Hand feste Verbindungsobjekte bauen — die pflegt der KCC nicht mit, sie veralten bei jeder Topologieänderung. Und erzwungene Sofort-Replikation überall sättigt genau die schwachen Leitungen, die das Intervall schützen soll.
AD-integrierte DNS: Zonenreplikation & Scavenging
AD-integrierte DNS-Zonen liegen in der Verzeichnisdatenbank und replizieren mit AD selbst (in Anwendungspartitionen, domänen- oder forest-weit). Jeder DC/DNS-Server hat dieselbe Zone — eine Änderung an einer Stelle verteilt sich über die AD-Replikation an alle.
Clients registrieren ihre Records dynamisch. Verschwinden Geräte ohne Abmeldung, bleiben veraltete Records liegen und zeigen auf falsche IPs. Dagegen hilft Aging/Scavenging: Records bekommen Zeitstempel; nach No-Refresh- + Refresh-Intervall (Standard je 7 Tage, zusammen ~14 Tage ohne Auffrischung) gelten sie als veraltet und werden entfernt.
Zusammenfassung — gleich im Check
Du kennst jetzt die Achsen dieses Moduls: die fünf FSMO-Rollen und ihre Zuständigkeit, Transfer vs. Seize, Sites & Subnets für Auth-Lokalität, GC-Platzierung vs. UGMC, das Tunen der Replikation über Site-Link-Parameter und AD-integrierte DNS mit Aging/Scavenging.