In Gesprächen über die Datensicherung und Wiederherstellung von Active Directory kommt immer wieder die Frage auf: Was mache ich denn, wenn einer der Betriebsmaster ausgefallen ist? Oft gefolgt von der Frage: Sollte ich mein AD-Backup auf dem Rolleninhaber ausführen?
Dahinter steht oft eine ungenaue Vorstellung von den Betriebsmastern. Im Folgenden daher ein paar Hinweise dazu.
Was sind Betriebsmaster?
In der Multi-Master-Replikation von Active Directory ist grundsätzlich jeder Domänencontroller (DC) einer Domäne vollständig schreibberechtigt für die AD-Datenbank. Dabei gibt es gar nicht “eine” Datenbank, sondern jeder DC hat seine eigene, unabhängige Kopie. Diese gleichen alle DCs über ein sehr leistungsfähiges Replikationssystem ab.
Selbstverständlich kann es dabei zu Replikationskonflikten kommen. Im einfachsten Fall haben zwei DCs dasselbe Objekt (z.B. einen User) geändert. Welche Änderung greift nun? Einen Überblick über die Replikation und die Konfliktbehandlung hat Philipp Föckeler vor Kurzem hier gegeben:
[faq-o-matic.net » Active-Directory-Replikation im Detail]
http://www.faq-o-matic.net/2010/08/31/active-directory-replikation-im-detail/
Nun ist diese Form der Konfliktauflösung für “normale” Daten und Vorgänge völlig ausreichend. Es gibt aber ein paar Dinge, die man besser nicht dem “Zufall” überlassen sollte, weil sie zu kritisch für Active Directory sind. Dazu zählen etwa Änderungen am AD-Schema (also der Datenbank-Definition, die festlegt, welche Objekte man überhaupt speichern kann und wie diese beschaffen sein müssen) oder das Erzeugen neuer Domänen. In solchen Fällen entstünde ein undefinierter Zustand, wenn zwei DCs unabhängig voneinander z.B. dieselbe Datenfeld-Definition ändern oder eine neue Domäne mit demselben Namen erzeugten.
Daher sind einige solcher Funktionen nur auf jeweils einem DC in der Domäne bzw. sogar im Forest möglich. Man nennt diese Funktionen “Flexible Single-Master Operations” (FSMO). Der DC, der eine solche Funktion ausübt, ist der “FSMO Role Owner” oder im Deutschen “Betriebsmaster”.
Hier (nochmal) eine kurze Übersicht:
Rolle | Bereich | Funktion |
PDC-Emulator | Domäne | Zentraler Zeitserver, Steuerung kritischer Replikationsprozesse, einiges Weitere. Früher war diese Rolle deshalb wichtig, weil sie Clients unter NT 4.0 vorgaukelte, der PDC zu sein. |
RID-Master | Domäne | Verteilen von RID-Pools (Relative Identifier), mit denen die anderen DCs eindeutige SIDs (Security Identifier) erzeugen können (für User, Gruppen, Computer). |
Infrastruktur-Master | Domäne | Abgleich der Domänen-Daten mit denen des Global Catalog. In Einzeldomänen praktisch funktionslos. |
Domain Naming Master | Forest | Erzeugen neuer Domänen im Forest. Der DNS-Master stellt eindeutige Domänennamen sicher. |
Schema-Master | Forest | Verwaltet die Master-Kopie des Schema. Nur auf diesem DC kann man das Schema ändern. |
Wie wichtig sind Betriebsmaster?
Die Betriebsmaster sind für den ordnungsgemäßen Betrieb des Active Directory zwingend notwendig. Allerdings ranken sich aus diesem Grund auch einige Mythen um diese Funktionen. Daher hier ein paar nähere Hinweise.
- Wenn eine oder mehrere der Betriebsmaster-Funktionen nicht erreichbar sind, wird AD auf Dauer nicht richtig funktionieren. Wichtig ist dabei der Aspekt “auf Dauer”: Wenn eine solche Funktion nur kurze Zeit offline ist, stellt das in fast keiner Situation ein Problem dar.
- Der Ausfall eines Betriebsmaster-DC stellt also keinen Grund zur Hektik dar! Man hat ausreichend Zeit, die Situation zu bewerten und die nächsten Schritte festzulegen.
- Die Betriebsmaster-Funktionen erzeugen auch in großen Umgebungen keine nennenswerte zusätzliche Last auf den Servern. Es ist nicht nötig, dafür “größere” Serverhardware vorzusehen.
- Aus diesem Grund gibt es auch in fast keiner Umgebung einen Grund, die Betriebsmasterrollen auf mehrere DCs zu verteilen. Es hat sich die Empfehlung eingebürgert, die FSMO-Rollen auf dem DC zu belassen, auf dem sie ursprünglich sind, solange dieser Server nicht außer Betrieb geht.
Aus Windows-2000-Zeiten gibt es noch Empfehlungen, wie man die Rollen verteilen soll. Diese Empfehlungen sind heute nicht mehr adäquat (sie waren schon unter Windows 2000 für fast alle Umgebungen zu hoch gegriffen). - Es ist allerdings wichtig, den administrativen Zugang zu Betriebsmaster-Funktionen einzugrenzen. Das gilt aber eigentlich für alle administrativen Funktionen, insbesondere wenn sie AD betreffen.
Wie verwalte ich Betriebsmaster?
Dazu haben wir ein paar ältere Artikel, die immer noch zutreffen:
[faq-o-matic.net » Wie verwalte ich die speziellen Domänencontroller-Rollen?]
http://www.faq-o-matic.net/2005/03/22/wie-verwalte-ich-die-speziellen-domaenencontroller-rollen/
[faq-o-matic.net » Wie kann ich Betriebsmasterrollen offline übertragen?]
http://www.faq-o-matic.net/2004/11/12/wie-kann-ich-betriebsmasterrollen-offlineuebertragen/
Was tun, wenn ein Betriebsmaster ausfällt?
Sollte der DC, der eine (oder besser: mehrere) Betriebsmaster-Rollen hält, ausfallen, so ist das Wichtigste: Ruhe bewahren. Im Wesentlichen gilt es zwei Situationen zu unterscheiden.
- Handelt es sich um ein vorübergehendes Problem?
Falls das Problem absehbar innerhalb weniger Tage zu beheben ist, so braucht man einfach gar nichts zu tun außer den ausgefallenen Server zu reparieren. Alle normalen Vorgänge innerhalb der AD-Administration laufen unbeeindruckt weiter: Anmelden, Zugriffsrechte verwalten, neue Objekte erzeugen. Das Wesentliche, das nicht mehr geht: Neue Domänen anlegen (aber wie oft tut man das schon?) und das Schema bearbeiten (was auch nicht häufiger geschieht). In Ausnahmefällen kann es sein, dass man keine neuen Sicherheitsobjekte (User, Gruppen, Computer) mehr erzeugen kann (weil keine neuen RIDs mehr frei sind), aber das tritt erst nach mehreren 100 neuen Objekten auf – auch das dürfte in den meisten Umgebungen nicht innerhalb von wenigen Tagen der Fall sein.
Sobald der FSMO-Rolleninhaber wieder online ist, funktionieren alle Vorgänge wieder. - Handelt es sich um ein bleibendes Problem?
Ist absehbar, dass der ausgefallene Server nicht wieder online gehen kann – etwa wegen eines kompletten Hardwareschadens –, so plant man in Ruhe die Übertragung der FSMO-Rollen auf einen der anderen DCs. Der eigentliche Vorgang ist in dem oben verlinkten Artikel beschrieben.
Nach der Rollen-Übertragung auf einen anderen DC entfernt man den “gestorbenen” alten DC aus dem AD (seit Windows 2008 reicht es aus, das Computerobjekt in “Active Directory-Benutzer und –Computer” zu löschen).
Wichtig: Nun muss man sicherstellen, dass der ausgefallene DC auch nach einer möglichen Reparatur nie wieder online ans Netz geht. Muss man die Maschine doch noch einmal hochfahren, um etwa Daten zu retten, so tut man dies ohne Netzwerkverbindung zum AD. Ist die Hardware repariert, so löscht man die Festplatte und installiert Windows neu – erst dann darf der Server wieder Kontakt zum AD bekommen.
Sollte ich die AD-Datensicherung auf einem Betriebsmaster ausführen?
Nach den obigen Ausführungen dürfte klar sein, dass der Ausfall eines Betriebsmasters keine kritische Situation darstellt. Es entstehen also keine Vorteile daraus, das AD-Backup auf einem Betriebsmaster auszuführen. Man sollte sich einfach an die Grundlinie halten, das AD auf mindestens zwei DCs pro Domäne regelmäßig zu sichern.
In großen Umgebungen mit mehr als zwei DCs ist es sogar empfehlenswert, das AD-Backup gerade nicht auf einem Betriebsmaster zu machen. Dahinter steht folgende Überlegung: Wenn man die Betriebsmasterrolle mal auf einen anderen DC verschiebt und dann ein AD-Backup zurückspielen muss, in dem der Rolleninhaber noch der vorherige Server ist, dann kann es dazu kommen, dass nach dem Restore plötzlich zwei DCs sich für den Betriebsmaster halten. Auch das ist keine unbehebbare Situation, aber man kann sie einfach vermeiden, wenn man die Wahl hat, das Backup auf einem Nicht-FSMO-DC zu machen.
http://faq-o-matic.net/?p=2588