AD Domain Rename - Es gibt sie noch: Single Label Domains

Ich habe vor 12 Jahren bei Nils Kaczinski auf faq-o-matic eine Anleitung hinterlegt. Ich durfte es mal wieder in Real Live durchspielen, weswegen ich ein paar Sätze dazu sagen möchte.
Umbenennen einer AD-Domäne | faq-o-matic.net (faq-o-matic.net)

Die Grundlagen/Vorraussetzungen sind immer noch dieselben:
Das AD muss mindestens DFL und FFL 2003 haben und es gibt am Besten keinen Exchange im AD. Es gab ein kleines Zeitfenster, wo es mit Exchange 2003 SP1 möglich war die Domäne umzubenennen, aber das Fenster ist sicherlich mittlerweile geschlossen. Jede neuere Version vom Exchange erlaubt keinen Rename. Das ist wohl der Grund, warum es die letzten 10 Jahre kaum Anfragen zu dem Thema gab, der Exchange 2003SP1 ist längst ersetzt worden. Im Fall des Kunden, gab es nie einen Exchange im AD.

Wenn der Exchange immer in einer anderen Domäne, einem anderen Forest oder nur gehostet/gemietet in der Cloud betrieben wird, dann kann ein Rename durchgeführt werden, da der Exchange nicht im eigenen AD eingetragen ist. 
Wie angedeutet, vor 10-12 Jahren wurde es öfter gemacht und der 2003 Server benötigte noch ein paar Updates, ab 2012 R2 aufwärts sollte es keine weiteren Dateien mehr erfordern, die nicht schon integriert sind.

Warum sollte man seine Domäne überhaupt umbenennen?
Da gibt gute Gründe, der wichtigste ist, es wurde vor langer Zeit eine Single Label Domain eingerichet. Die DNS Domäne besteht nur aus der TLD. Der FQDN nur aus einem Namen ohne Punkt und Endung. Der DNS Name war identisch zum NetBIOS, es gibt nur ".firma" anstelle ".firma.ende". Es gibt Anleitungen, um dieses Konzept am Leben zu halten, aber ein Server 2016 kann eine Single Label Domain nicht mehr als neues AD erzeugen. Server 2019 kann noch beitreten und DC werden, wenn sie vorhanden ist. Das Konstrukt wackelt gewaltig, Die Frage ist, wann es nicht mehr unterstützt wird.

Jede andere Umbennung hat politische Gründe, zb eine Umfirmierung, aber keine technische Notwendigkeit. Es ist egal wie das AD heisst, solange es einen FQDN hat. Die Cloud geht immer, falls das ein Argument sein sollte. Cloud funktioniert mit jeder beliebigen Endung. Microsoft will die Cloud verkaufen, das können sie nur, wenn sie alles erlauben und ermöglichen, was sie jemals supported haben. Sie können kein Produkt verkaufen, das Firmen zu einem AD Rename oder einer AD Migration zwingt, Es würde keiner machen und das Produkt Cloud liesse sich nicht verkaufen.

Wichtig! Ihr möchtet den NetBIOS Namen der Domäne nicht ändern. Wenn es geht behaltet ihn. Das Umbenennen verursacht viel mehr Arbeit, als der DNS. Denkt an jeden Server im AD auf dem Service Konten eingetragen sind. Diese sind alle auf "NETBIOS\account" konfiguriert. Diverse Benutzeranmeldungen sind mit "NETBIOS\account" hinterlegt. Programme die den Benutzerprofilepfad als String verwenden, statt Variablen, wenn die Endung ".NETBIOS" integriert ist. Diese müssten alle angepasst werden, wenn sich der Anmelde Trustee ändert. In dem Single Label Thema ist idR nur der DNS das Problem. Keine der Domänen Umbenennungen die ich gemacht habe, hat den NetBIOS Name angefasst.

Den Streit über "Was ist der beste Name für ein AD" werde ich hier nicht führen. Den darf jeder selber führen. Simples Fazit: Jeder FQDN Name ist erlaubt. Jeder hat Vor- und Nachteile. Für jeden gibt es ein Argument aus "Best Practice" Gedanken. Dummerweise hat sich Best Practise in 20 Jahren AD mindestens 6mal geändert und es wird es wieder tun. Ihr müsst damit Arbeiten. Ihr müsst es verwalten. Es ist euer AD, der Chef muss sich nicht darin wiederfinden. Ich persönlich mag es eine "int.externexistieren.de" OnPremise zu betreiben. Es ist ein FQDN mit 2 Punkten. Die interne Domäne ist eine SubZone, der externen Mail/Firnemdomäne. Das Konzept stirbt, wenn es mehr als eine externe Zone gibt ... macht was ihr wollt :-)

Zu erwartende Probleme, bzw, Baustellen:
Überall, wo der alte LDAP Pfad eingetragen ist. Überall wo der Distinghuished Name der DCs oder des AD eingetragen wurde. Überall wo der FQDN als String eingebaut wurde. Eure AD PKI wird migriert werden müssen, die RemoteDesktopServer Farm im Servermanager agiert mit dem alten FQDN, die wird wohl neu werden, eure Telefon/Kontakte Software auf dem Linux System, eurer Virenscanner, der direkt eine bestimmte OU auf Clients untersucht, alles was das das AD abfragt kann Fehler zeigen.
Aber, alle diese Produkte wurden einmal eingerichtet, sie können also erneut konfiguriert und angepasst werden.

Wer mehr wissen möchte, darf mich gerne kontaktieren, ich diene und leiste beruflich: Kontakt - Gruppenrichtlinien

1. Strategische Vorbereitung

1.1 Sicherung aller DCs! (oder wenigstens des FSMO Holders)

• ihr macht ein Backup mit eurer Backupsoftware
• ihr macht noch ein Backup mit wbadmin
• ihr macht einen Snapshot
• ihr macht eine Offline Kopie der Festplatte
• Diese Punkte sind nicht entweder/oder, sondern additiv sowohl, als auch!
  Wer keinen Rettungsanker in Reserve hat und noch nie sein AD mit den Werkzeugen recovered, denen er nur vertraut, weil das Backup jeden Tag erfolgreich ist, der macht zur Strafe noch 2 Backups.

1.2 Test in virtueller Umgebung mit eigenem Netzwerkadapter/Switch
Macht Restore Tests, die ihr schon seit jahren nicht mehr gemacht habt

• ihr baut eine virtuelle Maschine und stellt das Backup eurer Backupsoftware wieder her
• ihr baut eine virtuelle Maschine und stellt das Backup von wbadmin wieder her
• ihr baut eine virtuelle Maschine und hängt die Kopie der Disk ein

Wenn ihr euch sicher seit, das ihr ein Desaster Recovery beherrscht, dann dürft ihr es in den wiederhergestellten Systemem 1 bis 2 mal durchspielen, damit ihr Sicherheit bekommt. Das Desaster Recovery ist der einzige Weg, die Änderungen rückgängig zu machen, oder zu reparieren, wenn etwas schief geht. Hört sich schlimm an, ist aber trivial, wenn man sich sicher ist. Wenn ihr Angst davor habt, gebe ich gerne den Hinweis erneut auf meinen Beruf als Dienstleister.

1.3 Control Station

ihr benötigt einen MemberServer im AD. Auf diesem werden alle Befehle gegen die DCs abgesetzt. Die Control Station darf selber kein DC sein. Ein Server OS ist meinerseits empfohlen, da auf diesen die RSAT Tools leichter zu installieren sind als auf einem Windows Client. Technisch ist es aber egal.

1.4 ALLE! Systeme bis auf die DCs und die Control Station werden heruntergefahren.

Es sollte in der Umstellungszeit keine Kennwortänderung von Usern/Computern mehr geschehen. Falls es zu einem Desaster Recovery kommt, wären diese Änderungen verloren. Ebenfalls würde es zur Laufzeit der Umbenennung zu Verbindungsproblemen der Clients kommen, da der Client im IP Cache die alten Namen hat. Ergo, nicht diskutieren, Rechner ausschalten. 60.000 Clients ausschalten geht nicht? Dann seit ihr ein Kandidat für ADMT, nicht Domain Rename. Aber: Der Zeit und Kostenrahmen bei ADMT liegt weit über dem Kostenrahmen, die Clients für 1-2 Stunde auszuschalten, da alle SIDs und damit alle vergebenen Berechtigungen auf jedem System erhalten bleiben. Im KMU mit x-hundert Rechnern und 2 DCs ist der eigentliche Prozess in 10 Minuten erledigt.

1.5 Ihr habt jetzt eine Testumgebung mit all euren DCs und der Control Station.

In diesem System solltet ihr es 2mal durchspielen, bevor es ans Eingemachte geht.

1.6 Download der notwendigen Tools

Windows Server 2003 Active Directory Domain Rename Tools
Installieren und rendom.exe, bzw. gpfixup.exe aus dem Ordner in der Commandline aufrufen

1.7 Die AD Mitglieder müssen am Ende jeweils 2mal durchgestartet werden.

Das erste mal bekommen sie die Info, das das AD umbenannt wurde und sich das DNS Suffix verändert hat. Nach den 2ten Neustart sind sie sauber im "neuen" AD inkl. Anpassung des DNS Suffixes und Registrierung im DNS in der neuen Zone.

2. Start - Active Directory für neue DNS Zone vorbereiten

Ausführung auf der Control Station

2.1 Es werden die MMC Konsolen: Active Directory Benutzer und Computer, AD Domänen und Vertrauensstellungen, DNS und die Gruppenrichtlinienverwaltungskonsole benötigt. 

Install-WindowsFeature -Name GPMC,RSAT-AD-Tools,RSAT-AD-PowerShell,RSAT-DNS-Server

2.2 Die DNS Zonen für den neuen Namen müssen erstellt werden. Ad integriert, auf allen DCs, nur sichere Updates.
NeuerDom.name
_msdcs.NeuerDom.name

2.3 Domain Function Level (DFL) und Forest Function Level (FFL) kontrollieren und auf die höchste Stufe setzen, wenn es noch nicht geschehen ist. 

2.4 Die neue Zone muss als zusätzlich erlaubter UPN eingetragen werden
Siehe Email Adresse als UPN festlegen - UPN Suffixe für interne Anmeldung erlauben - Gruppenrichtlinien

2.5 ALLE RECHNER HERUNTERFAHREN, die nicht beteiligt sind. Es bleiben nur die Control-Station und die Domänen Controller eingeschaltet

2.6 der zu verwendende ausführende Account ist Mitglied Domänen- und Schema-Admins.

3. Start Rename Domain - Active Directory umbenennen

3.1 Mit dem rendom Befehl wird die aktuelle Konfiguration des AD in einer XML Datei dokumentiert (domainlist.xml)

rendom.exe /list

Das XML wird editiert und geändert, ein Backup ist schnell erstellt:

copy domainlist.xml domainlist-save.xml

3.2 Editieren der domainlist.xml

notepad domainlist.xml

Suchen + Ersetzen: Name der alten Domäne suchen und gegen den neuen austauschen. In einem Single Forest AD mit einer Single Domain sind es 3 DNS Einträge und 1x NetBIOS (falls dieser getauscht wird).

3.3 Kontrolle der getätigten Änderungen, Achtet auf Tippfehler etc 

rendom /showforest

NeuerDom.Name [ForestRoot Domain, FlatName:ALTERNAME]
        DomainDnsZones.NeuerDom.Name [PartitionType:Application]
        ForestDnsZones.NeuerDom.Name [PartitionType:Application]

The operation completed successfully.

3.4 Der nachfolgende Step ist eine "Bremse". Es wird das AD Attribut msDS-updateScript,cn=Partitions,cn=configuration,cn=altername gefüllt. Dieser Eintrag verhindert u.A. das neue DCs während der Umbenennungsphase hinzugefügt werden können. Das heisst auch, das das Rename beendet und abgeschlossen werden muss, damit der Eintrag entfernt wird und man wieder neue DCs installieren kann, wenn sie benötigt werden.

rendom /upload

Es wird eine DcList.xml erzeugt in der die DCs aufgeführt werden und der Status steht auf "Initial"

type DcList.xml

3.5 Bei 2 DCs, die im selben Subnetz stehen ist die Replikation wahrscheinlich schon längst erfolgt, während ihr das hier lest, aber für das gute Gefühl und weil DCs machmal verteilt stehen, triggern wir die Replikation und schubsen sie an.

Ermittlung des Domain Naming Masters:

dsquery server -forest -hasfsmo name

Anschubsen, Name des ermittelten Naming Master verwenden.

repadmin /syncall /d /e /P /q DC01

3.6 Den DCs wird mitgeteilt, das es zu einer Änderung kommen wird

rendom /prepare
    Waiting for DCs to reply.
    Waiting for DCs to reply.    
    DC01.Altername.derdom was prepared successfully
    1 server contacted, 0 servers returned Errors
    
    The operation completed successfully.

Der Status der DcList.xml wechselt auf Prepared

Type DcList.xml

    <?xml version ="1.0"?>
    <DcList>
        <Hash>876YUDYSdXnktHCWUZ7Dr1Bqotw=</Hash>
        <Signature>7TK3o0vevq/B2ftife9oICi+bOU=</Signature>
        <DC>
                <Name>DC01.Altername.derdom</Name>
                <State>Prepared</State>
                <Password>Tu+9ue7YgCk=</Password>
                <LastError>0</LastError>
                <LastErrorMsg></LastErrorMsg>
                <FatalErrorMsg></FatalErrorMsg>
                <Retry></Retry>
        </DC>
    </DcList>

3.7 Letzte Chance zur Umkehr. Jetzt findet der eigentliche Rename statt. Bis hierher könnt ihr immer noch abbrechen und es beenden. Jetzt ist der Moment, in dem es kein zurück mehr gibt.

rendom /execute
    Waiting for DCs to reply.
    Waiting for DCs to reply.
    The script was executed successfully on DC01.Altername.derdom
    1 server contacted, 0 servers returned Errors

    The operation completed successfully.

Die DcList.xml wechselt auf "Done"

Der Rename ist vollzogen, aber noch nicht vollständig umgesetzt.

3.8  Die Control-Station muss jetzt als erste 2mal neugestartet werden. Ein ipconfig /all oder auch die Erweiterten Systemeinstellungen müssen euch nach dem 2ten Reboot neuen Namen als Suffix anzeigen.

3.9 Das eigentliche Rename wird nun abgeschlossen, die Bremse wird gelöst, das msDS-UpdateScript Attribut wird entfernt.

rendom.exe /end

Wenn ihr mehr als einen DC habt, dann kann es zu einer Fehlermeldung kommen:

Failed to delete rename script on the DN: CN=Partitions,CN=Configuration,DC=XXXX
on host XXXX.XXXX.
00002077: SvcErr: DSID-030F0B0E, problem 5003 (WILL_NOT_PERFORM), data 0
: Cannot complete this function. :1003

Lösung: ntdsutil aufrufen und den Domain Naming Master kurzfristig vom FSMO Holder auf einen anderen verlegen, replizieren und direkt wieder retour zum ersten FSMO Holder.

    ntdsutil
    roles
    connections
    connect to server DCxx
    quit
    transfer domain naming master 
(repadmin /syncall /d /e /P /q DCxx in einer 2ten CMD aufrufen)
    connections
    connect to server DC01
    quit
    transfer domain naming master 
    quit
    quit
(repadmin /syncall /d /e /P /q DCxx in einer 2ten CMD aufrufen) 

3.10 Im Gegensatz zu den selbsterstellten Gruppenrichtlinienobjekten ist die Default Domain Policy und die Default Domain Controllers Policy sowohl in ihrer GUID, als auch der Verlinkungen hardcodiert. Diese beiden Verlinkungen müssen korrigiert werden.

gpfixup /olddns:Altername.derdom /newdns:NeuerDom.Name /oldnb:ALTERNAME /newnb:ALTERNAME  /dc:DC01.Altername.derdom

Sollte das Fehlschlagen hilft entweder ein ipconfig /flushdns, gefolgt von nbtstat -RR und arp -d oder wir führen den Befehl nach dem Reboot der DCs noch einmal aus. Nachteil ist nur, das die DCs einmal ohne Richtlinien starten würden. Das überleben diese aber ohne Probleme.

3.11 Die DCs werden nun der Reihe nach durchgebootet. Es empfiehlt sich bei 2 DCs, die DNS Einträge kreuzweise zu setzen und zuerst den ersten 2mal zu starten, anschliessend den zweiten 2mal booten, bzw. weitere. Wichtig, immer 2mal durchstarten!

shutdown -r -t 0 -m \\DC01

3.12 Die beiden DCs müssen umbenannt werden. Im Gegensatz zu den Membern ändert sich das DNS Suffix nicht von alleine. Der neue Name muss als zusätzlicher Name hinzugefügt werden. Dieser wird primärer festgelegt und dann kann nach einem Reboot kann der alte Name entfernt werden.

netdom computername DC01.Altername.derdom /add:DC01.NeuerDom.Name
    DC01.NeuerDom.Name
    wurde als alternativer Name für den Computer hinzugefügt.

    Der Befehl wurde ausgeführt.
    
netdom computername DC01.Altername.derdom /makeprimary:DC01.NeuerDom.Name
    DC01.NeuerDom.Name wurde als primärer Name für den Computer festgelegt. Der Computer muss neu
    gestartet werden, damit diese Namensänderung wirksam wird. Der Computer ist
    andernfalls möglicherweise nicht in der Lage, Benutzer und andere Computer zu
    authentifizieren und kann von anderen Computern in der Gesamtstruktur
    möglicherweise nicht authentifiziert werden. Der angegebene neue Name wurde von
    der Liste der alternativen Computernamen entfernt. Der primäre Computername wird
    nach dem Neustart in den angegebenen neuen Namen geändert.
    
    Der Befehl wurde ausgeführt.

shutdown -r -t 0 -m \\DC01

3.13 Um den alten Namen zu entfernen, mussen wir den IP Cach an der Control-Station wieder leeren.

ipconfig /flushdns &  nbtstat -RR & arp -d

netdom computername DC01.NeuerDom.Name /remove: DC01.Altername.derdom
    DC01.Altername.derdom wurde als alternativer
    Name für den Computer entfernt.

    Der Befehl wurde ausgeführt.    

3.14 Jetzt werden alle Mitglieder der Domäne 2mal durchgestartet. Die Rechner sollten sich stressfrei verhalten.
Simple Fix, wenn ein Rechner die Vertrausnstellung zur Domäne verloren hat: JoinWorkgroup -> JoinDomain

4. Abschlussarbeiten - Cleanup und Aufräumen

4.2 Wir können nun den DNS aufräumen, soweit wie möglich. Theoretisch benötigen wir die alte Zone nicht mehr, aber die Praxis zeigt, das in vielen Scripten, Werkzeugen, Drittanbieter Tools, Linux Systemen, Druckern. wasauchimmer, der Pfad auf den alten Namen definiert ist. Der Quickfix ist, den "SRVxx.Altername.derdom" weiterhin im DNS zu behalten, bis die Konfiguration des Dienstes oder der Software erfolgt ist.

Die beiden alten Zonen können gelöscht werden und "auf Zuruf" neuerstellt werden, wenn obiger Fall eintritt.

Altername.derdom
_msdcs.Altername.derdom

4.3 UPN Anmeldung aufräumen, 
Wer den Rename wegen der Cloud vollzogen hat und möchte, das alle User ihre Mailaddresse als UPN verwenden können, der kann ein Script über die User laufen lassen, die überhaupt eine Mailaddresse haben.
Email Adresse als UPN festlegen - UPN Suffixe für interne Anmeldung erlauben - Gruppenrichtlinien

4.4, eigentlich 4.1 Wir beenden das rename der Domäne endgültig. Dadurch geht aber auch die Information verloren, daß das AD umbenannt wurde. Clients die bisher nicht gestartet wurden müssen leider über JoinWorkgroup -> JoinDomain wieder in das AD gebracht werden. Ich würde mit diesem Befehl 1-x Wochen warten. Je weniger Rechner angefasst werden müssen desto besser. Aussendienst Rechner, allgemein Rechner die unterwegs sind und nicht verfügbar sind, müssen sonst per Hand wieder integriert werden.

rendom /clean

Das ist der erste Punkt um aufzuräumen, aber der letze den ich ausführen würde. Erst wenn alle Rechner im Netzwerk waren und 2mal durchgestartet sind, besteht keine Gefahr mehr, daß ein Rechner aufgrund der Umbenennung aus dem AD fällt. Ich empfehle das Problem durch Einsatz von Zeit zu verringern.