Domain Controller Update
Alle Jahre wieder müssen auch Domain Controller ersetzt werden. Selbst wer diese Funktion "virtualisiert" hat und damit die VM einfach vom alten Host auf einen neuen Host umziehen kann, muss ab und an das Betriebssystem aktualisieren.
In vielen Fälle ist ein Inplace-Update eines Domain Controllers zwar möglich, aber auch nicht ganz unkritisch. Das würde sich aber eh nur für virtuelle DCs eigenen, denn wen die Hardware getauscht wird, ziehen fast alle Firmen eine frische risikolose Neuinstallation einem "Cloning" o.ä. vor. Ein Inplace Update scheidet auch aus, wenn die Sprache des Servers gewechselt werden soll, ein Wechsel von 32bit auf 64bit ansteht, ein Update von Server Core oder ein Wechsel der Version nach unten (Enterprise nach Standard) erforderlich ist. Die möglichen Wege zeigt folgendes Diagramm für Domain Controller.
Dieses Bild geht nicht auf die Betriebsarten des Active Directory ein !! Für bestimmte Inplace Updates sind Servicepacks auf der Quelle eine Voraussetzung.
Wenn dann speziell größere Firmen, die sowieso mehrere DCs betreiben, ein Wechsel anstreben, dann werden die alten Server erst sauber deinstalliert und dann die neuen Server mit installiert. So kann der neue Server den gleichen Namen und die gleiche IP-Adresse des alten Servers einnehmen
Denken Sie daran, dass beim Wechsel der Sprache z.B. die Namen der Domänengruppen nicht geändert wird. (Administratoren statt Administrators). Windows nutzt intern an den meisten Stellen zwar die SIDs, welche für diese vordefinierten Konten immer gleich sind, aber an einigen Stellen werden auch die Namen als Strings verwendet (z.B. Profile, Home-Verzeichnis aber auch Gruppenrichtlinien). Dies wird hier nicht berücksichtigt
Bei all den Umzugsarbeiten sollten natürlich nicht nur alle Informationen weiter erhalten bleiben, sondern auch der Einfluss auf den laufenden Betrieb muss minimiert werden.
Kurzfassung
Die im folgenden betrachtete Migration lässt sich kurz beschreiben.
- Der Wechsel der Hardware erfolgt über eine „Neuinstallation“ von Windows auf den neuen Server.
- Die neuen Server werden später den gleichen Namen und die gleiche IP-Adresse der bisherigen Server sein.
- Die Betriebssysteminstallation wird nicht als Image übertragen, sondern über ein Rolling Update“.
- Ein alter DC wird dabei sauber entfernt und die neue Hardware sauber installiert.
Risiken
Wer genau einen Domain Controller hat, kann nicht erst den bestehenden DC deinstallieren um dann einen neuen DC mit gleichem Namen zu installieren. Hier könnten Sie also zuerst einen temporären DC installieren, um dann ihre primäre Maschine umzuziehen.
Wir gehen davon aus, dass Sie also mindestens zwei Domaincontroller in ihrem Netzwerk (und Standort) haben, so dass ein Wegfall eines DC für vielleicht 30-180 Minuten keine Überlastung oder Aussetzer bedeutet. Technisch könnten Sie natürlich mit einem DCPROMO einen DC herunterstufen, aus der Domäne entfernen und einen vorbereiteten neuen Server mit dem gleichen Namen und der gleichen IP-Adresse wieder hochstufen. Aber das würde nicht ohne ein blaues Auge abgehen, denn es gibt einige Dinge, die sie prüfen sollten. Hier eine Auswahl und deren Bedeutung bzw. Problempotential.
- Betrieb mit einem DC
Wenn Sie nur zwei DCs im Standort haben, dann trägt der verbliebene DC während der Umstellung des zweiten DCs die komplette Last für Anmeldungen etc. Auch wenn die Umstellung nur eine Stunde dauert, ist dies eine "kritische" Phase. Sie können Sie aber entschärfen, indem einen temporären DC mit installieren. Der sollte dann aber auch nicht nur mit DCPROMO hochgestuft werden, sondern auch andere Dienste wie DNS etc. müssen beachtet werden. - FSMO-Rollen
Ein komplettes Update aller DCs betrifft natürlich auch die DCs mit den FSMO-Rollen. Das ist an sich kein Problem, da DCPROMO beim Herunterstufen dies erkennt, Sie warnt und so nichts passieren kann. Man muss eben nur dran denken. - Globaler Katalog
Diese Rolle ist schon kniffliger, da per Default nur der erste DC eines Forests auch automatisch GC wird. Zur Ausfallsicherheit sollten sie aber mehrere GC haben. Vor Änderungen mit DCPROMO sollten Sie also immer sicherstellen, dass genug GCs an den jeweiligen Standorten sind - SiteLinks/MultiSitereplikation/KCC
Wenn mehrere Standorte im Spiel sind, dann ist Replikation ein wichtiges Thema. Zum einen ist das Standardintervall von 180 Minuten sehr lange und zudem kann es ja sein, dass ihr gerade deinstallierter DC früher der Replikationspartner eines DCs eines anderen Standorts war. Auch der KCC braucht dann etwas Zeit, um die Replikationstopologie neu zu ermitteln und auf einen anderen DC umzuschwenken und dann die Änderungen der Konfiguration zu ziehen und anzuwenden. Tipp: REPLMON und temporär statisch eingetragene Links auf dem entfernten DC beschleunigen den Prozess. - Kerberos und SPN und TicketSize
In die gleiche Kerbe fällt die Anmeldung mit Tickets, welcher per Default 6h gültig sind. Wenn sie einen DC herunterstufen und kurz darauf einen neuen Server mit gleichem Namen wieder hochstufen, dann haben andere Kommunikationspartner eventuell noch ein Ticket, welches aus deren Sicht wieder gültig scheint, aber nicht ist. KERBTRAY oder ein Reboot des anderen DC hilft hier ebenfalls. - NTFRS und DFS: NETLOGON und SYSVOL
Natürlich muss ein DC auch Anmeldeskripte und Gruppenrichtlinien vorhalten und ehe der File Replication Service (FRS) sein OK nicht gibt, offeriert der DC seine Dienste nicht im DNS. FRSDIAG und das Eventlog helfen ihnen dabei, Fehler bei der Replikation zu erkennen. Wenn Sie sehr viele Richtlinien haben oder sogar Softwarepakete (MSI) darin bereitstellen, dann kann das etwas dauern. Warten Sie also nach dem Hochstufen den Abschluss ab, - TS-Licensing Service
Windows Terminal Server benötigen einen "Terminal Server Licensing Service", welcher die ganzen Clientlizenzen verwaltet. Mir ist kein Weg bekannt, diesen Dienst auf einen anderen Server zu übertragen oder auf einem gleichnamigen Server wieder ohne Kontakt zu Microsoft zu aktivieren. Stellen Sie sich hier also schon mal wieder darauf ein, dass Sie die Lizenznummern eintragen und den Server aktivieren müssen. - DHCP Rechte und Authentifizierung
Oft wird übersehen, dass Client vom DHCP-Server eine IP-Adresse erhalten und dieser Server den Client stellvertretend in der DNS-Zone einträgt. Wenn die DNS-Zonen auf "Nur sichere Updates" stehen, dann trägt der DHCP-Server die Daten nicht nur ein, sondern wird auch Besitzer des Eintrags. Verschieben Sie nun DHCP auf einen anderen Server, dann muss der neue DHCP-Server nicht nur autorisiert werden. Er kann erst einmal nicht die DNS-Einträge des anderen Servers ändern. Ich kenne keinen einfachen Weg, wie man die ACLs der betroffenen Einträge ändert (Subinacl ?). Sie können aber dem DHCP-Server Computerkonto ja entsprechende Berechtigungen auf den Zonen geben. Das ist aber immer noch besser als die Zonen für "unsichere Updates" zu öffnen. Der "Scavening"-Prozess hilft nur, wenn er aktiv ist und die Verfallszeiten auch abgelaufen ist (meist sind das aber 24h und mehr) - WINS und DNS Server
Die meisten DCs sind "Infrastrukturserver", die nicht nur Anmeldedienste bereit stellen, sondern häufig auch die Namensauflösung sicherstellen. Hier sind je nach Dienst besondere Dinge zu betrachten. WINS-Server replizieren sich und merken sich die höchste Sequenznummer des Partners. Wir der andere WINS-Server ohne Vorkehrungen einfach neu gemacht, dann fängt dieser wieder bei "0" an wird nimmt erst mal nicht an der Replikation teil.
DNS-Server haben eventuell lokalen Zonen und meist separat konfigurierte "Weiterleitungen". AD-integrierte Zonen stehen den Client immer nur dann zur Verfügung, wenn der DNS-Server auch ein funktionierendes AD betreibt. Gerade wenn sie aber mit DCPROMO den Status ändern, ist genau dies nicht der Fall. Der DNS-Server auf diesem System sollte in der Zeit also "gestoppt" sein, damit die Clients keine falschen Antworten bekommen. - NIS und RADIUS (IAS)
Wer seine DCs zusätzlich auch anderen Diensten zur Anmeldeverifizierung über Radius oder als NIS-Server bereit stellt, muss zusätzliche Vorkehrungen treffen, dass diese Dienste während der Umstellung weiter funktionieren - Exchange auf DC
Besondere Aufmerksamkeit ist für Exchange zu verwenden. Exchange auf einem DC ist eine schlechte Idee und nur für kleine Firmen eine Option. Bei der Migration kommen Sie nun an das Problem, dass ein DCPROMO auf einem Exchange Server nicht von Microsoft unterstützt wird. Fakt ist aber, dass es auch nicht sauber funktioniert, da das Exchange Setup auf einem DC andere Routinen anspricht. Hier funktioniert diese "Herunterstufen/Hochstufen-Migration" leider nicht. - Exchange RUS, ADC und andere
Die andere Komponente von Exchange 2000/2003 ist z.B. der RUS, welcher auf einen DC gebunden ist. Beim DC Update wird die USN ungültig, die der RUS sich als "last processed" gespeichert hat, so dass hier zusätzliche Schritte erforderlich sind, die auf ein "Rebuild" hinaus laufe. Das kann aber auch bislang verdeckte Änderungen an bereits bestehenden Postfächern bezüglich der primären Mailadresse hinauslaufen
Das gleiche gilt natürlich auch für andere Dienste wie den ADC, MIIS und eventuell FAX-Connectoren, die per LDAP arbeiten - DNS Cache
Das Herunterstufen eines DCs wird im DNS sehr schnell bekannt gegeben, aber kann besonders bei mehreren Standorten etwas dauern, bis alle Sites die neuen Daten haben. Verzögerungen bei der Installation eines neuen DC sind weniger kritisch als beim Entfernen. Und hier kann der DNS-Cache ihnen einen Streich spielen, wenn ein DC seinen neuen Partner nicht findet oder akzeptiert. Manchmal hilft hier ein "IPCONFIG /FLUSHDNS", damit der jeweilige Server die aktuellen Daten aus dem DNS bezieht. Manchmal hilft es auch, wenn alle DCs zumindest temporär den gleichen zentralen DNS-Server befragen, um Replikationslatenzzeiten zu umgehen. - "Unbekannte"
Es gibt immer wieder Anwendungen, die immer einen bestimmten DC ansprechen (kein redundantes Design). Diese werden in dieser zeit Zeit nicht funktionieren. Die Risiken können durch die manuelle Umkonfiguration der statischen Programme auf den anderen DC reduziert oder ausgeschlossen werden, würden aber die Migration selbst stark in die Länge ziehen und letztlich nur aufzeigen, dass auch ein Ausfall eines DC im „Normalbetrieb“ von diesen Anwendungen nicht korrekt behandelt werden kann. Insofern bietet sich diese Migration auch dazu an, eben solche Programme zu erkennen, die mit dem Ausfall eines DCs sichtlich Probleme haben bzw. kein Failover unterstützen.
Sie sehen also, dass es durchaus einer Vorbereitung und einer umsichtigen Analyse der vorhandenen DCs auf Dienste und Funktionen bedarf. Am wichtigsten ist die Überwachung der Veränderungen z.B. mit REPLMON und anderen Tools um Fehler und Verzögerungen zu erkennen. Sie erleichtern sich viel, wenn Sie nach jedem DCPROMO einige Zeit vergehen lassen oder vorher z.B.: die Replikation zwischen Standorten (Sitelinks) auf z.B. 15 Minuten herunter stellen. Solche Änderungen müssen aber auch erst wieder repliziert werden. Also sollte dies einige Tage vorher durchgeführt werden.
Wer es es eilig hat, sollte wissen, wie er bestimmte Prozesse forciert anstößt, z.B. den KCC, die Replikation zwischen Standorten, das erneuern von Kerberos-Tickets und DNS-Updates.
Migrationsweg
Folgende kurze Beschreibung können Sie als Ausgangssituation für ihre eigene Umstellung heranziehen und ihren Bedürfnissen entsprechend anpassen. Besonders sollten Sie die Zeiten auf ihre Hardware und Umgebung abschätzen.
Die Liste ist nur als Anhaltspunkt zu verstehen. Sie ist vermutlich nicht vollständig, da es bei den meisten Firmen weitere Anwendungen gibt, die das Active Directory nutzen, z.B. Spamfilter, Disclaimer etc.
Unterstützung durch
Net at
Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach an.
Vorarbeiten
Die neuen DCs werden als normale Windows Server mit temporärem Namen/IP-Adresse installiert
- Der WINS/DNS-Dienst ist installiert aber nicht gestartet.
- DNS: Forwarder und sekundäre Zonen sind bereits eingerichtet
- Zertifikatsdienste sind nicht installiert
- Domain „Gesundheit“ prüfen
Eventlog, RELPMON - Backup
Letzte Sicherung der bestehenden DCs. Optional „ziehen“ einer Festplatte
Beginn der kritischen Phase
- DC1: (ca. 15 Min)
- Eintragen des DC2 als DNS-Server
- Stoppen/deaktivieren des DNS-Servers
Mit dem DCPROMO werden die Zonen entfernt und der DNS-Server hat keine Zonen mehr und darf nicht mehr antworten. Client sollten dann einen Failover auf einen anderen DNS machen. - Optional vorhandene CA sichern
- DCPROMO und herunterstufen (10min)
Damit werden alle Checks vor dem Denote durchgeführt und auf Probleme hingewiesen - Abschalten und gegen Wiedereinschalten sichern
- Nach dem Herunterstufen wird der Server deaktiviert.
Der Server darf mit dem Namen nicht mehr gestartet werden, damit der neue DC nicht gestört wird
Daher wird der Server vom LAN abgetrennt und ausgeschaltet - IP-Adresse weitergeben
Es ist denkbar, während der Downtime einem anderen aktiven DC zusätzlich die IP-Adresse des gerade herunter gestuften Servers zu geben, so dass DNS, WINS und einfache LDAP-Anfragen beantwortet werden.
- Das Computerkonto DC1 in der Domäne wird gelöscht
- DC1NEU einbinden (15 Min)
- Der neue Server wird in DC1 umbenannt und in die Domäne aufgenommen und durchgestartet.
- IP-Adresse kann noch die
temporäre Adresse bleiben.
Damit kann man relativ gefahrlos DCPROMO etc. machen, ohne dass Client durch DNS-Cache etc. den Server schon als gültig ansehen. - Hochstufen (15 Min)
Der neue Server wird mit DCPROMO zum neuen Server
NEUSTART - DNS/WINS konfigurieren ( 5min)
Der DNS-Server ist nun zu starten, WINS einzurichten. - Test: Replikation der DC
Prüfen, ob die Funktion gegeben ist. Kontrolle von DNS, WINS, SYSVOL-Replikation, Eventlog - Einrichtung/Anpassung Datensicherung, Antivirus, Monitoring
- Weitere Produkte konfigurieren
z.B. Zertifikatsstelle, Radius-Zertifikat, NIS etc.)
- DC1NEU produktiv nehmen
Geben Sie nach erfolgreicher Replikation dem Server nun die gleiche Adresse, wie dem vorher abgeschalteten Server. Wurde die Adresse temporär anderweitig vergeben, dann muss der andere Server die Adresse natürlich vorher wieder abgeben.
Nacharbeiten
Der neue Server heißt nun gleich, sollte die gleichen Informationen haben und hat auch die passende IP-Adresse. Für die Clients sollte er wieder ein normal funktionierender Server sein.
Allerdings sollten Sie noch abhängige Anwendungen kontrollieren, wenn dies nicht schon eine Monitoring-Software für sie macht:
- AD-Replikation
Prüfen Sie die Replikation des Active Directory anhand Eventlog und Replmon. Sie können auch gerne mal einen Benutzer anlegen und kontrollieren, ob dieser nach einiger Zeit auf allen DCs vorhanden ist. - Exchange 2000/2003 RUS
Legen Sie temporär einen Benutzer mit einer Mailbox an und schauen sie, ob der RUS in wenigen Minuten wirklich eine Mailadresse vergibt.
Weitere Links
- Den ersten Windows Server 2008 R2 DC zur
Gesamtstruktur hinzufügen
http://blog.dikmenoglu.de/PermaLink,guid,735ae625-042f-4144-b926-de761db9a205.aspx
