← Active Directory

Topologie & Replikation: Sites, FSMO und GC

Ein Domain Controller stand nach einem Wasserschaden drei Monate im Lager. Anschließen oder neu aufsetzen? Die Antwort hängt an einer einzigen Zahl, die kaum jemand kennt: der Tombstone-Lifetime des Forests — 60 oder 180 Tage, je nachdem, wann er angelegt wurde, und ein Upgrade hat sie nicht verändert. Liegt sie darunter, bringt der Server gelöschte Konten samt ihrer Berechtigungen zurück, ohne dass ein Fehler erscheint. Dieses Modul behandelt die physische Seite von Active Directory: Sites und Subnetze als Voraussetzung lokaler Anmeldung, der KCC, der die Topologie selbst baut und handgebaute Verbindungen nie wieder anfasst, die fünf FSMO-Rollen und die nicht rücknehmbare Entscheidung zwischen Übertragen und Erzwingen, Global Catalog und die Rolle, die nicht daneben liegen darf — und die Befehle, mit denen man Rückstand von Fehler unterscheidet.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-06

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

SITE: HQDC01DC02Intra-Site: schnellSite-LinkKosten · IntervallSITE: BRANCHDC03Multi-Master: jeder DC ist schreibbar; die KCC baut die Verbindungen, Site-Links steuern die Standort-Replikation.
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.
MerksatzDie 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).
MerksatzFSMO 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?
Wo die Rollen tatsächlich liegennetdom query fsmo beantwortet in einer Zeile, welcher DC welche der fünf Rollen hält — und ist damit der erste Befehl, wenn eine Operation ohne erkennbaren Grund scheitert. Bemerkenswert oft weicht die Antwort von dem ab, was in der Dokumentation der Umgebung steht: Rollen wandern bei Außerbetriebnahmen mit, ohne dass es jemand notiert.

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

Praktisch läuft beides über dasselbe Werkzeug: Move-ADDirectoryServerOperationMasterRole überträgt geordnet, und mit dem zusätzlichen Schalter -Force erzwingt es die Übernahme, wenn der bisherige Inhaber nicht mehr antwortet. Dass ein einzelner Schalter den Unterschied zwischen einer Routinehandlung und einer nicht rücknehmbaren Entscheidung macht, ist die eigentliche Gefahr dieser Operation — er lässt sich in einem Wartungsfenster aus Gewohnheit mittippen.

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.

MerksatzAuth-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“.
Das Signal, das dir die Lücke nenntEin DC, der Anmeldungen aus Adressen ohne Standortzuordnung erhält, protokolliert das als Ereignis 5807 des Netlogon-Dienstes — samt der betroffenen Adressen. Diese Liste ist die genaueste Antwort auf die Frage, welche Subnetze noch fehlen: Sie stammt aus dem tatsächlichen Betrieb statt aus einer Netzdokumentation, die selten vollständig ist.

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-offLokaler 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.
Die Rolle, die man nicht zusammen mit dem GC platziertDer Infrastructure Master hat eine Sonderregel, die regelmäßig übersehen wird: In einer Domäne mit mehreren Domänen im Forest soll er nicht auf einem Global Catalog liegen — er würde seine Aufgabe dann für erledigt halten und Verweise auf Objekte fremder Domänen nicht mehr aktualisieren. Der Effekt ist still: Umbenannte oder verschobene Objekte anderer Domänen bleiben unter ihrem alten Namen in Gruppenmitgliedschaften stehen. In einer Umgebung mit nur einer Domäne ist die Regel dagegen bedeutungslos, weil es keine fremden Verweise gibt — und genau deshalb wird sie bei der ersten zusätzlichen Domäne zum Problem.

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.

MerksatzStell die Regeln ein (Kosten/Intervall/Zeitplan) und lass den KCC die Topologie bauen. Handarbeit an Verbindungsobjekten ist die Ausnahme, nicht das Tuning.
Der Preis kürzerer IntervalleEin Intervall zu senken wirkt harmlos und ist es nicht: Jeder Durchlauf kostet Verbindungsaufbau und Bandbreite auf genau der Leitung, deren Enge der Grund für den Zeitplan war. In Umgebungen mit vielen Standorten summiert sich das zu dauerhafter Grundlast. Die ehrlichere Frage lautet deshalb nicht „wie schnell geht es“, sondern „welche Änderung muss tatsächlich schneller ankommen“ — dringende Ereignisse wie Kontosperrungen replizieren ohnehin außerhalb des Zeitplans.

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.

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

Wenn ein DC zu lange weg war

Eine Löschung repliziert AD nicht als „weg“, sondern als Grabstein (Tombstone): ein Restobjekt mit wenigen Attributen, das den anderen DCs die Löschung mitteilt. Der Grabstein bleibt eine festgelegte Zeit erhalten und wird danach endgültig entfernt.

Tombstone-Lifetime — Die Zeitspanne, in der ein Grabstein im Verzeichnis erhalten bleibt — und damit das Fenster, in dem eine Löschung alle Replikationspartner erreicht haben muss. Danach existiert kein Beleg mehr, dass das Objekt je gelöscht wurde.

Der Wert hängt am Alter des ForestsDer Standardwert richtet sich laut Dokumentation danach, welche Betriebssystemversion auf dem ersten DC des Forests lief: 60 Tage für ältere, 180 Tage ab Windows Server 2003 SP1. Und der Nachsatz ist der eigentliche Punkt: Ein späteres Upgrade ändert den bestehenden Wert nicht — er bleibt, bis ihn jemand von Hand setzt. Ein gewachsener Forest kann also bis heute auf 60 Tagen stehen, ohne dass es je aufgefallen wäre. Das ist eine Zahl, die man in der eigenen Umgebung nachsieht statt sie anzunehmen.

Kommt ein DC, der länger als diese Zeit offline war, wieder ans Netz, hat er die Grabsteine nie gesehen. Die dort gelöschten Objekte existieren auf ihm weiter — als Lingering Objects. Was dann passiert, hängt an einer einzigen Einstellung.

Strenge Replikationskonsistenz aktiv
Der Zielserver erkennt, dass er das Objekt nicht aktualisieren kann, und hält die eingehende Replikation dieser Partition von dieser Quelle an. Laut, sichtbar, sicher.
Strenge Replikationskonsistenz inaktiv
Der Zielserver fordert das Objekt vollständig an — und das gelöschte Objekt wird wieder ins Verzeichnis eingeführt. Leise, unsichtbar, gefährlich.
Was das für die Praxis heißtDieselbe Lage endet je nach Einstellung in einem angehaltenen Replikationspfad oder in wiederauferstandenen Konten und Gruppen, die längst gelöscht sein sollten — inklusive der Berechtigungen, die an ihnen hingen. Die Ereignis-IDs 1388 und 1988 melden erkannte Lingering Objects, 2042 meldet, dass ein Rechner zu lange nicht repliziert hat. Ein DC, der die Tombstone-Lifetime überschritten hat, gehört deshalb nicht wieder ans Netz, sondern neu aufgesetzt.

Die Werkzeuge: welche Frage beantwortet welcher Befehl

Replikationsprobleme haben eine unangenehme Eigenschaft: Sie fallen erst auf, wenn jemand eine Änderung vermisst — oft Tage später. Deshalb lohnt es sich, die vier Fragen und ihre Befehle zu kennen, bevor man sie braucht.

Steht irgendwo etwas still?
repadmin /replsummary — die Übersicht über alle Partner mit größtem Rückstand und Fehlerzahl. Der erste Befehl, immer.
Was genau scheitert an diesem DC?
repadmin /showrepl — eingehende Partner, letzter Erfolg, letzter Fehler je Partition.
Gibt es Lingering Objects?
repadmin /removelingeringobjects mit vorherigem Prüflauf gegen einen als sauber bekannten Referenz-DC.
Ist es breiter als Replikation?
dcdiag /test:replications prüft zusätzlich Zuständigkeiten und Verbindungen rund um die Replikation.
Der Unterschied zwischen Rückstand und Fehlerrepadmin /replsummary zeigt zwei Dinge, die gern verwechselt werden: die größte Verzögerung und die Zahl der Fehler. Ein Rückstand von zwei Stunden über eine Standortverbindung mit Zeitplan ist völlig normal und kein Befund. Ein Fehlerzähler über null ist immer einer — auch dann, wenn der Rückstand klein aussieht. Wer nur auf die Zeitspalte schaut, übersieht genau die Fälle, die eskalieren.
Und ein Wort zur Ungeduldrepadmin /syncall stößt eine sofortige Replikation an. Das ist zur Prüfung nützlich und als Dauerlösung ein Fehler: Wer nach jeder Änderung von Hand synchronisiert, verdeckt genau die Latenz, die man beobachten will — und merkt nicht, wenn der reguläre Weg längst nicht mehr funktioniert.

Durchgerechnet: „Der Zweigstellen-DC war drei Monate aus“

Eine Entscheidung, die man nicht rückgängig machen kann

Szenario

Nach einem Wasserschaden stand der DC einer Zweigstelle rund drei Monate abgeschaltet im Lager. Die Zweigstelle nimmt den Betrieb wieder auf, und ein Kollege will den Server einfach wieder anschließen — er sei schließlich unverändert.

Anforderungen

  • Vor dem Einschalten entscheiden, nicht danach
  • Die Entscheidung an einer nachprüfbaren Zahl festmachen

Schritte

  1. Die Zahl beschaffen: Welche Tombstone-Lifetime gilt in diesem Forest tatsächlich? Nicht den Standardwert annehmen — er hängt davon ab, wann der Forest angelegt wurde, und ein Upgrade hat ihn nicht verändert. Bei 60 Tagen ist die Frage bereits entschieden.
  2. Vergleichen: Drei Monate sind rund 90 Tage. Liegt die Tombstone-Lifetime bei 60, hat der DC das Fenster überschritten; bei 180 nicht.
  3. Bei Überschreitung: nicht anschließen. Der Server käme mit Objekten zurück, die überall sonst gelöscht sind. Je nach Einstellung hält er entweder die Replikation an oder führt die gelöschten Objekte samt ihrer Berechtigungen wieder ein — das zweite merkt zunächst niemand.
  4. Der saubere Weg: Metadaten des alten DCs im Verzeichnis bereinigen, den Server neu aufsetzen und regulär als Domain Controller aufnehmen. Die Erstbefüllung kann über ein Medium erfolgen, wenn die Leitung dünn ist.
  5. Danach prüfen: repadmin /replsummary auf Fehler null, und den neuen DC in beide Richtungen bestätigen.

Merksatz: Bei überschrittener Tombstone-Lifetime ist Neuaufsetzen nicht die vorsichtige, sondern die einzige Option. Der scheinbar teurere Weg ist hier der billigere — die Alternative kostet ein Verzeichnis, dem man nicht mehr ansieht, was gelöscht ist und was nicht.

Wer die Topologie eigentlich baut

Die Verbindungen zwischen Domain Controllern legt niemand von Hand an. Ein Dienst auf jedem DC berechnet sie selbst und passt sie an, wenn sich etwas ändert — ein neuer DC dazukommt, ein alter verschwindet oder eine Standortverbindung ausfällt.

KCC (Knowledge Consistency Checker) — Der Dienst auf jedem Domain Controller, der die Replikationstopologie innerhalb einer Site berechnet und die Verbindungsobjekte anlegt. Er läuft regelmäßig und baut die Topologie nach einer Störung selbsttätig neu.

ISTG (Inter-Site Topology Generator) — Genau ein DC je Site übernimmt zusätzlich die Berechnung der Verbindungen zwischen den Sites. Die Rolle wird automatisch vergeben und im Bedarfsfall automatisch neu besetzt.

Die Regel, die den Ring erklärtInnerhalb einer Site baut der KCC die DCs zu einem Ring und ergänzt Abkürzungen, sobald zwischen zwei beliebigen DCs mehr als drei Zwischenschritte lägen. Das ist der Grund, warum eine Site mit vier DCs anders verdrahtet aussieht als eine mit zwölf — und warum eine handgebaute Verbindung, die man „zur Sicherheit“ ergänzt, meist überflüssig ist: Der KCC hätte sie angelegt, wenn sie nötig wäre.
Warum Handarbeit teuer istEin von Hand angelegtes Verbindungsobjekt wird vom KCC nicht gepflegt. Es bleibt bestehen, wenn der Zielserver verschwindet, und es wird nicht ersetzt, wenn es ausfällt. Was als schnelle Abhilfe gedacht war, ist damit dauerhafte Wartungslast — und im Störungsfall die erste Stelle, an der eine Topologie nicht mehr das tut, was die Dokumentation beschreibt.

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

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →
Quellen & Aktualität22 Primärquellen · zuletzt geprüft:
  1. 01Microsoft Learn — Operations master roles (FSMO)
  2. 02Microsoft Learn — Transfer or seize FSMO roles in AD DS
  3. 03Microsoft Learn — Sites, subnets, and the DC Locator process
  4. 04Microsoft Learn — Planning Global Catalog Server Placement (Universal Group Membership Caching)
  5. 05Microsoft Learn — Active Directory Replication Concepts (KCC, ISTG, site links)
  6. 06Microsoft Learn — DNS aging and scavenging (No-refresh/Refresh interval, Scavenging Servers)
  7. 07learn.microsoft.com/en-us/previous-versions/wi…003/cc738018(v=ws.10
  8. 08learn.microsoft.com/en-us/troubleshoot/windows…directory/fsmo-roles
  9. 09learn.microsoft.com/en-us/windows-server/ident…ds/manage/dc-locator
  10. 10Microsoft Learn — Operations master roles (Schema Master)
  11. 11Microsoft Learn — Adprep and schema updates (forestprep runs against the Schema Master)
  12. 12Microsoft Learn — Sites, subnets and the DC Locator process
  13. 13Microsoft Learn — Managing sites and subnets in Active Directory
  14. 14Microsoft Learn — Configure Universal Group Membership Caching in Active Directory
  15. 15Microsoft Learn — Active Directory replication concepts
  16. 16Microsoft Learn — Design and configure Active Directory sites
  17. 17Microsoft Learn — Clean up server metadata after a failed DC / seize
  18. 18Microsoft Learn — Aging and scavenging in Windows DNS
  19. 19Microsoft Learn — Active Directory-integrated DNS zones
  20. 20learn.microsoft.com/en-us/troubleshoot/windows…aster-roles-in-ad-ds
  21. 21learn.microsoft.com/en-us/windows-server/ident…ge/manage-fsmo-roles
  22. 22learn.microsoft.com/en-us/windows-server/ident…-ds-metadata-cleanup