Bei der nutzungsbasierten Erstellung des IaaS Active Directory Domänencontrollers können wir einen großen taktischen Fehler begehen. Ich zeige euch, wie ihr diesen vermeidet.
Die nutzungsbasierte Zahlung für IaaS Projekte in der Azure Cloud ermöglicht uns, in den Zeiten der „Nicht-Nutzung“ Kosten einzusparen. Dabei wird die IaaS VM zeitweise real vom Hyper-V getrennt und verursacht so keine weiteren CPU Kosten. Ich möchte daran erinnern, dass alle Datenträger weiterhin voll bezahlt werden müssen.
So weit so gut …
Aber bei einem IaaS Domänencontroller werden wir hier eine Überraschung erleben. Durch das Trennen der Hyper-V Hardware und der IaaS DC-VM wird eine neue VM-Generation-ID erstellt. Dadurch wird unser SYSVOL die Replikation und der RID-Master seinen Dienst einstellen.
Die Reparatur der Umgebung scheint nun erstmal ausgeschlossen und faktisch ist die Replikation der Gruppenrichtlinien und Scripte beendet. Die reine AD Datenbank läuft aber erst einmal normal weiter. Allerdings droht hier durch die Beschädigung des RID Master neuer Ärger.
Das Ende vom IaaS-Lied
IaaS DC-VM´s müssen durchlaufen und dürfen nicht über einen längeren Zeitraum von der Azure-Hardware getrennt werden. Einen Neustart der VM innerhalb der VM oder ein Verschieben der VM von Azure, auf einen anderen Hyper-V-Container, ist ohne Probleme möglich.
Technisch gesehen gibt es, bei der Hyper-V-Containertrennung, einen zeitlichen Faktor, der nicht überschritten werden darf. Erst dann wird eine neue VM-Generation-ID erzeugt.
Links
Zitat:
Do not shut down a domain controller VM using Azure portal. Instead, shut down and restart from the guest operating system. Shutting down through the portal causes the VM to be deallocated, which resets both the VM-GenerationID and the invocationID of the Active Directory repository. This discards the AD DS relative identifier (RID) pool and marks SYSVOL as nonauthoritative, and may require reconfiguration of the domain controller.
Schritt für Schritt – so erstellt ihr den IaaS Domänencontroller erfolgreich:
- VM nicht in Azure Beenden
- Burstmodus als VM Size kann Kosten sparen
- SYSVOL und AD Datenbank nicht auf dem Systemlaufwerk sondern auf einen zusätzlichen Datenträger ohne Azure Cache speichern
- Small VM Size (OS Volume 32-64 GB) und kleine zusätzliche Datenträger kann Kosten sparen
Schöne Grüße
Andre Büddemann
ADN MCT