Domain Rename

Inhaltsverzeichnis

Der richtige Domänenname
Voraussetzungen
Umstellungsschritte
Oder doch ADMT?
Weitere Links

Wer gut geplant hat, wird keine Domäne oder Forest umbenennen müssen. Aber es gibt immer noch "alte Forests", die einen DNS-Namen nutzen, der ungeeignet ist und diesen ändern wollen oder müssen. Diese Seite beschreibt das Vorgehen eines Rename der Domäne und verwandte Themen. Prüfen Sie insbesondere die Voraussetzungen des Rename und ob ein paralleler Neuaufbau mit Migration der Benutze, Gruppen, Clients, Server und Dienste nicht der sicherere oder einzige Weg ist.

Der richtige Domänenname

Wenn Sie schon über einen Rename nachdenken, dann haben Sie hoffentlich auch verstanden, warum der bestehende Name unpassend ist und wie der neue Name aussehen muss. Zumindest wenn technische Gründe vorliegen, ist der Rename oft auch ein Blocker für den Projektfortschritt. Wenn organisatorische Gründe, z.B. Firmenumbenennung, der Auslöser sind, dann sollten Sie trotzdem noch mal kontrollieren, dass der neue Name auch dauerhaft bestand hat. Ein Rename ist nämlich keineswegs eine "Routinetätigkeit" und hat umfangreiche Abhängigkeiten auch wenn es letztlich nur um einen Namen geht.

Der Name des Forest und der Domain steckt an vielen Stellen, z.B. im FQDN der Server und Client über den auch Dienste angesprochen werden aber auch intern als Teil des LDAP-Pfads verwendet. Schon allein diese beiden stellen wirken sich auf URLs und Hostnamen aus. LDAP-Pfade erscheinen in Skripten, Zertifikaten u.a.. Daher sollte ein Neuaufbau oder Rename zumindest beim Ziel dann "sauber" sein.

Beim Namen empfiehlt es sich einen DNS-Namen zu nutzen, der auch öffentlich blockiert ist. Drei Optionen sehe ich:

Split-DNS
Es kann der gleiche DNS-Name sein, den sie auch im Internet nutzen. Einige Besonderheiten bei DNS sind zu beachten
Subdomain
Auch eine Unterdomäne wie z.B. ad.uclabor.de ist möglich. Diese Domäne muss gar nicht im Internet sichtbar sein.
öffentliche (hidden) Domain
Denkbar ist auch eine gesonderte Domain, die sie natürlich im Internet "gekauft" haben aber extern nicht aktiv nutzen.

Ungeeignet sind natürlich Domänen, die anderen Firmen gehören (Sicherheitsrisiko) oder Domänen, die es (noch) nicht gibt. Ich habe schon Domänen wie "firma.ads" gesehen die solange funktioniert haben bis Google die Top Level Domain ".ads" bereitgestellt hat und VPN-Clients plötzlich gemeint haben, sie wären intern

Denken Sie dabei auch an die Möglichkeit einer Ausstellung von öffentlichen Zertifikaten, die eindeutige Erreichbarkeit bei Partnerverbindungen zwischen Firmen und die Einstufung der Adressen im Browser als "Trusted Intranet".

Voraussetzungen

Gleich vorneweg: Ein Rename einer Active Directory Domäne ist kein "Routinetask", da umfangreiche Änderungen an der Infrastruktur nicht immer sicher abzuschätzen sind. Am einfachsten ist es wenn ihre Umgebung nur aus ein paar Domaincontrollern mit Windows Servern und Clients besteht. Jedes zusätzliche Programm, welches das Active Directory nutzt und per DNS nach Servernamen fragt, wird vor dem Rename betrachtet werden müssen. Ein Risiko bleibt, da Sie es nicht vorab testen können und der Rückweg in der Regel nicht gegangen wird.

Ein Neuaufbau ist natürlich ein Stück Arbeit. Das AD ist schnell installiert aber die Migration zieht sich auch über Tage, Wochen oder sogar Jahre hin. Bei einem Rename ist man viel schneller aber mit einem deutlich höheren Risiko fertig.

Es gibt aber einige Dinge, die ich vorab zu bedenken geben möchte:

Kein Exchange
Sobald sie Exchange 2007 oder höher installiert haben, ist ein Rename nicht mehr möglich. Exchange ist so eng mit dem AD integriert, da alle Konfigurationseinstellungen (Server, Connectoren, Datenbanken etc.) in der Konfiguration-Partition liegen. Eine Rename würde den DN ändern. Hier bleibt nur die Migration in einen neuen Forest.
Sonderfall AD-Integrierte PKI
Wenn sie heute schon eine Zertifizierungsstelle betreiben, dann müssen Sie einige Voraussetzungen beachten. Insbesondere wenn die CRLs als LDAP-Pfad angegeben sind oder CAs auf Domain Controller installiert sind. Ein Wechsel ist hier vielleicht auch der Anlass die PKI neu zu machen.
Siehe auch "Prepare Certification Authorities" https://technet.microsoft.com/en-us/library/cc816587
Achtung Domain-DFS
Der Rename ändert die DFS-Einstellungen für SYSVOL und NETLOGON aber nicht für andere "Domain-DFS"-Einstellungen.
Memberserver und Client brauchen zwei Reboots
Nach dem Rename der Umgebung müssen alle Domainmitglieder diese Änderung bekommen. Das passiert eigentlich automatisch während der nächsten zwei Reboots. Das muss natürlich eingeplant werden, dass möglichst viele Endgeräte online sind. Es gibt aber auch sicher Geräte, die nicht "online" sind. Hier ist eine Downtime für Clients aber vor allem auch Server einzuplanen Auch die Domaincontroller booten natürlich zweimal durch.
DNS-FQDN ändert sich
Durch den Rename ändern sich natürlich die FQDNs der Server und Clients. Das hat Auswirkungen auf Netzwerk-Verknüpfungen, ggfls. Computerzertifikate und Konfigurationseinstellungen in Applikationen. Alte Namen könnten im DNS per CNAME weiter bereitgestellt werden und besondere Namen wie z.B. "autodiscover.<maildomain>" müssen auf den richtigen FQDN umgestellt werden
Weitere unbekannte Abhängigkeiten
Der LDAP-DN ändert sich und könnte in verschiedenen Konfigurationseinstellungen hinterlegt sein. Ich denke an Powershell-Skripte, Scanner2Mail-Lösungen mit LDAP-Suchen, Spamfilter, VPN-Systeme, 802.1x. Auch die Änderung des NT4-Domäne wird überall aufstoßen, wo der NT4-Domänenname in der Konfiguration hinterlegt ist, z.B. bei Diensten, die sich so anmelden anstelle den UPN zu nutzen.

Die Liste ist sicher nicht vollständig.

Umstellungsschritte

Wenn Sie sich dann dennoch dazu entschlossen haben, die Domäne im Rahmen eines "Rename" zu ändern, dann durchlaufen Sie im wesentlichen folgende Checkliste.

Bitte beachten sie die jeweils aktuelle Dokumentation von Microsoft.

Schritt	Erledigt
Neuen Domänennamen als Zone anlegen. Beim DCPromo mit DNS-Installation legt der Assistent eine DNS-Zone an. Das müssen Sie hier von manuell machen und eine Zone für die neue Domäne AD-Integrierte Zone mit „Secure Updates“ DNS-Zone ggfls. in anderen Systemen delegieren/forwarder) Als AD-Integrierte Zone warten, bis alle andere DNS-Server die Zone haben
Umbenennung vorbereiten Die nächsten Schritte starten den Rename. Zuerst generieren wir eine Domainlist.xml rendom /list Diese Datei muss editiert werden und der alte Domänenname durch den Zielnamen ersetz werden Notepad.exe Domainlist.xml Kontrolle der Änderungen rendom /showforest Änderungen auf dem Domain Naming Master anstoßen. Das friert auch alle weiteren Änderungen im AD ein rendom /upload Kontrolle, dass diese Änderung bei allen DCs angekommen ist rendom /prepare
Umbenennung aktivieren Nach all den Vorarbeiten starten wir die Änderung auf allen DCs rendom /execute Jeder DCs macht nun den Change und bootet neu. Denken Sie bei der ersten Anmeldung nach dem Reboot an die neue Domäne beim Benutzernamen.
Group Policy updaten Auch wenn die Domäne umgestellt ist, sind in den Gruppenrichtlinien noch die alten DNS-Namen und NT4-Namen enthalten. Dazu gibt es folgende beiden Befehle, die auf einem DC nach dem Rename ausgeführt werden. gpfixup /olddns:<alterDNSName> /newdns: <NeuerDNSName> gpfixup /oldnb:<AlterNT4Name> /newnb: <NeuerNT4Name>
FQDN der DNS prüfen Prüfen Sie den FQDN der Domain Controller. Wenn der FQDN noch nicht stimmt, sollten Sie die Konfiguration anpassen: netdom computername <alterFQDN> /add:<neuerFQDN> netdom computername <alterFQDN> /makeprimary:<neuerFQDN> Danach ist ein Reboot ratsam.
Clients Reboot Die DCs bieten nun die neue Domäne an aber scheinen auch noch auf den alten Namen zu reagieren und in Windows scheint auch Code vorhanden zu sein, der diesen Rename erkennt. Sie müssen die Domänenmitglieder (Server und Clients) zweimal booten, damit diese die neue Domäne direkt übernehmen. Vor dem nächsten Schritt sollten natürlich viele Clients den automatischen Prozess übernehmen. Nach dem nächsten Schritt müssen Sie noch nicht umgestellte Client manuell umstellen.
Cleanup Diese Kompatibilitätsfunktion zur Umstellung der Clients wird mit dem finalen Cleanup ebenfalls mit abgeschaltet. Entfernt Verweise auf den alten Namen. Alle Clients, die bis dahin nicht gebootet wurden, wechseln nicht mehr automatisch die Domäne rendom /clean Löst die Änderungssperre vom rendom /upload rendom /end
Checks Eigentlich sollte die Umbenennung damit schon abgeschlossen sein. Ein paar Tests zur Verifikation sollten sie aber doch durchführen, z.B. Kontrolle DNS Ist die neue Zone mit passenden Daten gefüllt? Die alte Zone kann danach zurück gebaut werden, wenn Sie nicht mit CNAME auf die die neuen Namen weiter leiten. Können neue Clients in Domain aufgenommen werden? Funktionieren die vorhandenen Trusts eventuell sollten sie die Trusts dann neu einrichten

Oder doch ADMT?

Wenn eine Umbenennung der Domäne nicht möglich ist oder zu kritisch erscheint, dann bleibt letztlich nur die Migration der Benutzer, Gruppen, Computer und Dienste ein einen "richtig benannten Forest".