Aus aktuellem Anlass schreibe ich heute ausnahmsweise einen Artikel zum Thema Active Directory. Als Client Architekt habe ich das AD seit NT 4.0 sehr lieb gewonnen, das Bloggen überlasse ich aber lieber den echten Cracks wie Nils K., Yusuf D. oder Mark H....
Aber ich kann nicht umhin diesen Fall hier mal mit ein paar Bilder zu dokumentieren.....passt ganz gut in die Virtualisierungsabt. hier im Blog...die in letzter Zeit sowieso etwas zu kurz kam.
Ein gutes Beispiel wie man aus den Fehlern anderer etwas lernen kann.
Der Problemfall
Ich war vor ein paar Wochen bei einem Kunden, eigentlich ging es um eine Remote Desktop Server Upgrade zu besprechen, da sagt der Systemverantwortliche das sie ein massives Problem im AD haben und ob ich mal etwas Unterstützung leisten könnte.
Klar, warum nicht...ist ja ein Kunden !
Der Kunde betreibt in Eigenregie seit neustem eine virtuelle Serverfarm (Hyper-V Server 2012) mit 13 Servern auf 2 Maschinen verteilt.
Es laufen 2 virtuelle DCs, einer davon aber auf einem virtuellen Server in einer Niederlassung, wo es ab und an mal Probleme mit der WAN Strecke gibt. Es gibt, seit dem die Farm aktiv ist, sehr oft massive Probleme mit der Anmeldung an der Domain.
Meine Frage war direkt ob es nur virtuelle und keinen physischen DC gibt...die Antwort vom inhouse Admin war nein, sie wollten alles virtuell haben....
Sie betreiben 2 Hyper-V Hosts und der Admin und der Azubi hatten diese sogar in die Domain gewurschtelt bekommen (welche ja auf einer dort gehosteten VM betrieben werden) und fand das ganz normale das die Domaincontroller VMs die einzigen DCs im Netz sind und auch die Hyper-V Hosts sich über diese VMs anmelden.
Ich hab ihn mal gefragt, was passiert wenn der Strom mal weg ist und die Server wieder hochfahren -wie er gedenkt sich an einen angehaltenen DC auf dem Host anzumelden....da hat es dann geklingelt und der Kopf wurde rot.
Also haben wir ganz schnell einen alten DL360 G5 aus dem Lager geholt und Server 2008R2 installiert und den zum DC gemacht, DCPROMO, alles repliziert und das war es dann...
WIRKLICH ?
Jetzt wäre es ja ganz praktisch, wenn dieser physische DC auch alle FSMO (Flexible Single Master Operations) Rollen inne hätte, welche auf den DCs einfach so aufgeteilt waren. Das kann schon mal passieren wenn man mit DCPROMO /forceremoval den DC aus der Domain reißt und der keinen der anderen DC erreichen kann um seine Rollen an den zu übergeben. Also ist eine Konsolidierung der FSMOs angesagt um wieder Ordnung ins Chaos zu bringen.
Es macht da mehr Sinn das der physische DC das ist, was man zu NT 4.0 Zeiten den PDC genannt hat, der primäre Domain Controller. Der DC in der Hauptgeschäftsstelle ist ja schließlich der wo sich 85% der Leute anmelden.
Dazu kommt noch das die DNS Server in einem chaotischen Zustand waren, Domain DNS Zonen und die Forest DNS Zonen waren unvollständig, dies passiert wenn man die DNS Zonen nicht nach dem runterstufen des DCs manuell verschiebt.
FSMO Rollen übertragen
Eine echt gute Anleitung wie man die FSMO Rollen von einem auf den anderen DC verschiebt beschreibt Yusuf Dikmenoglu wie immer sehr gut in seinem Blog, ich schreibe jetzt nicht nochmal das was Yusuf schon so gut beschrieben hat in meinen Worten, lest seinen Artikel 😉
hier ist ein kurzer Überblick über die 5 FSMO Rollen die ein DC haben kann. Er beschreibt dort auch wie man die FSMO mit Powershell und auch mit DCPROMO verschiebt.
Diese Anleitung ist einfach nur noch mal von mir ergänzend als eine step by step Anleitung in Bildern für den Server 2008R2 über die verschiedenen MMCs.
Hier mal die FSMOs im Überblick:
- Schema Master
- Domain Naming Master
- Infrastructure Master (Betriebsmaster in dt)
- Relative ID (RID) Pool Manager
- PDC Emulator
Und in diesem Fall geistern die Rollen auf verschiedenen DCs herum ohne das ein Sinn hinter steckt, ich vermute mal das es ursprünglich mal mehrere DCs gegeben hat die ohne ADPREP aus der Domain rein und raus gerissen wurden....ist aber letztlich egal !
Um das zu bebildern stelle ich das mal in einer anderen Umgebung nach, in unserem Fall verschieben wir vom DC02 die FSMOs auf den DC01 der auch tatsächlich ein physikalischer DC ist.
Zunächst einmal schauen wir uns mit dem Befehle "netdom query fsmo" (cmd IMMER als Admin öffnen !) wie die FSMO Rollen verteilt sind.
Soweit so gut !
Als nächstes tragen wir in diesem cmd Fenster den Befehl "regsvr32 schmmgmt.dll" ein und sollten dann diese Meldung erhalten
Wenn wir diese Meldung erhalten, dann sind wir nicht als Admin angemeldet und die UAC sperrt uns aus....
Als nächstes müssen wir an die MMC ran und ein verstecktes Feature, welches nicht in der Verwaltung auftaucht installieren, das Active Directory Schema. Dazu erstmal die MMC aufrufen....
...und dann das Active Directory Schema hinzufügen
Jetzt diese Funktion auswählen....
.....einfach den entsprechenden DC auswählen.....
....und dummerweise dann in diese Meldung laufen weil wir unseren Windows Server 2008R2 domain controller noch nicht die Schema Master Rolle zugeteilt haben, also switch auf den neuen DC (quasi den Ziel DC) und den zum Betriebsmaster machen, in dem man sich bei DCs in die MMC läd....
So, das war es, der neue DC ist schon mal Schemenmaster....4 more FSMO to go....
Jetzt kommt der Domänennamen-Master dran, dazu müssen wir in Verwaltung/Active Directory-Domänen und -Vertrauensstellungen
den DC auf den Ziel DC01 ändern....
dann auch hier wieder den Betriebsmaster auswählen
und wieder einfach von DC02 auf DC01 umstellen...
und auch der Domainanmen-Master fertig....CHECK !
Jetzt werden wir uns den letzten 3 FSMOs zuwenden, dem RID Master, PDC Emulator, und Infrastructure Master, dazu gehen wir in Verwaltung/Active Directory-Benutzer und -Computer zum ändern des DC auf DC01
und dann wieder das alte Betriebsmaster Spiel 😉
nur diesmal ist es hier viel besser gelöst, weil wir nämlich RID, PDC und Infrastruktur Master zusammen in einem Fenster habe, deshalb mache ich das auch immer zuletzt
Alle 3 jeweils ändern und sich dann mit dem netdom query fsmo Befehl überzeugen, dass alles da ist wo man es haben will 🙂
Jetzt läuft alles sauber auf dem physikalischen DC ! Habe ich schnell so bei Kunden erledigt und so muss keine Dienst mehr über die WAN Strecke funken, wenn er z.B. auf den Schemamaster oder den Domainname Master zugreifen will 🙂
Zum Schluss noch die DNS Server aufgeräumt und die Zonen manuell verschoben wo sie hingehören und siehe da....die Anmeldungen klappen wieder ganz problemlos 🙂
Fazit
Wenn man eine virtuelle Umgebung plant, dann auf JEDEN FALL (!!!!!) mit einem getrennten physischen DC, inkl. DNS Server und DHCP Server. Dann kann man auch bequem die Hypervisor Hosts in die Domain einbinden ohne das es Stress gibt. Wenn man mehrere Standorte hat, so gilt dasselbe, egal wie dick die WAN Leitung dazwischen ist !
Nachtrag:
Da der Blog leider gehackt wurde und die Bilder in dem Beitrag nicht wieder herzustellen sind noch eine andere Möglichkeit die FSMO Rollen zu übertragen....
Move-ADDirectoryServerOperationMasterRole -Identity <Name des Ziel DC> -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator
So einfach geht das mit Powershell 😀
1 Antwort