# Topologie & Replikation: Sites, FSMO und GC

> FSMO-Rollen und wann man sie überträgt statt sie zu seizen, Sites und Subnets für lokale Authentifizierung, Global-Catalog-Platzierung und AD-integrierte DNS-Replikation.

Track: [Active Directory](https://physar.tech/learn/active-directory)  
Kanonische Fassung: https://physar.tech/learn/active-directory/topology-replication  
Stand: 2026-07-26  
Interaktiver Teil: 7 Checks (nur im Browser)

## Topologie & Replikation: Sites, FSMO und Global Catalog

### 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).

_[Abbildung: Sites bündeln Subnetze; Site-Links verbinden sie über die WAN-Strecken. Der KCC baut automatisch die Verbindungsobjekte, der ISTG die Inter-Site-Verbindungen. Multi-Master: jeder DC ist beschreibbar, Konvergenz braucht über Standorte hinweg Zeit.]_

> **Merksatz:** Die Topologie plant AD selbst. Deine Stellschrauben sind **Sites**, **Subnets** und **Site-Link-Parameter** — nicht handgebaute Verbindungen.

### 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). |

> **Merksatz:** FSMO ist die Ausnahme vom Multi-Master-Modell. Wer eine Operation nicht ausführen kann, fragt zuerst: **welche der fünf Rollen** ist dafür zuständig — und ist ihr Inhaber erreichbar?

### 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.

> **Kernregel:** Nach einem **Seize** darf der alte Inhaber **nie wieder** ans Netz — erst Metadata-Cleanup und Neuaufsetzen. Sonst existieren Rolle oder RID-Pool doppelt: Zwei Schema-/RID-Master im selben Bereich führen zu Directory-Inkonsistenz. Transfer geht **nur mit lebendem** Inhaber; ist er tot, bleibt nur Seize.

### 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.

> **Merksatz:** Auth-Lokalität ist eine **Subnet-Frage**. Ein lokaler DC nützt nichts, wenn das Client-Subnet keiner Site zugeordnet ist — dann kennt ihn der Locator nicht als „vor Ort“.

### 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.

> **Trade-off:** **Lokaler GC** = alles vor Ort, aber forest-weite Replikationslast auf der Leitung. **UGMC** = minimale Last, aber nur für Logon, braucht **einmal** einen erreichbaren GC zum Befüllen und passt für **wenige** Nutzer ohne GC-abhängige Apps.

### 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.

> **Merksatz:** Stell die **Regeln** ein (Kosten/Intervall/Zeitplan) und lass den KCC die Topologie bauen. Handarbeit an Verbindungsobjekten ist die Ausnahme, nicht das Tuning.

### 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.

> **Kernregel:** Scavenging **koordiniert** aufsetzen: Aging auf der Zone, und Scavenging an **einer definierten Stelle** (per „Scavenging Servers“-Liste). Da die Zone AD-integriert repliziert, räumt ein Server für alle auf. Ohne Einschränkung versucht **jeder** DNS-Server der Zone zu scavengen — mit womöglich abweichenden Einstellungen und unvorhersehbaren Löschungen.

### 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**.

> **Gleich im Check:** In den nächsten Entscheidungen wählst du für konkrete Ops-Situationen selbst — und siehst pro Option, **warum** sie trägt oder aus welchem konkreten Grund nicht.

## Quellen

- Microsoft Learn — Operations master roles (FSMO)
- Microsoft Learn — Transfer or seize FSMO roles in AD DS
- Microsoft Learn — Sites, subnets, and the DC Locator process
- Microsoft Learn — Planning Global Catalog Server Placement (Universal Group Membership Caching)
- Microsoft Learn — Active Directory Replication Concepts (KCC, ISTG, site links)
- Microsoft Learn — DNS aging and scavenging (No-refresh/Refresh interval, Scavenging Servers)
- Microsoft Learn — Operations master roles (Schema Master)
- Microsoft Learn — Adprep and schema updates (forestprep runs against the Schema Master)
- Microsoft Learn — Clean up server metadata after a failed DC / seize
- Microsoft Learn — Sites, subnets and the DC Locator process
- Microsoft Learn — Managing sites and subnets in Active Directory
- Microsoft Learn — Configure Universal Group Membership Caching in Active Directory
- Microsoft Learn — Active Directory replication concepts
- Microsoft Learn — Design and configure Active Directory sites
- Microsoft Learn — Aging and scavenging in Windows DNS
- Microsoft Learn — Active Directory-integrated DNS zones
- learn.microsoft.com/en-us/troubleshoot/windows…aster-roles-in-ad-ds — https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/transfer-or-seize-operation-master-roles-in-ad-ds
- learn.microsoft.com/en-us/windows-server/ident…ge/manage-fsmo-roles — https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/manage-fsmo-roles
- learn.microsoft.com/en-us/windows-server/ident…-ds-metadata-cleanup — https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup