I have now received several emails regarding the migration of domain controllers that are still running an older operating system. Most of the emails are about retaining the IP address of the original domain controller.
The environments described in the emails were all similar, only the operating system on which the original domain controller runs varies. In most cases, there was only one domain controller running on Windows Server 2008, which is now to be replaced by Windows Server 2016. In one case, there was even a domain controller running on Server 2003.
Of course, it is not recommended to operate only one domain controller, but some small environments do not allow anything else.
This article is dedicated to the migration of an Active Directory with only one domain controller based on Server 2008 to Server 2016, including the retention of the original IP of the Server 2008 DC.
Server 2003 is excluded here, but can be migrated first to Server 2008 and then from Server 2008 to Server 2016 using the same method. A direct migration from Server 2003 to Server 2016 DCs is not possible.
The surroundings
For this article, I have created your test environment, which is structured as follows:
There is a Windows Server 2008 Domain Controller with the static IP 172.16.100.10 and the name DC2008. There are other clients in the network that use the domain controller as a DNS server. The name of the Active Directory is frankysweb.local.
A new Windows Server 2016 with the name DC2016 and the IP 172.16.100.20 has been installed. The server is currently only a member of the Active Directory and also uses DC2008 as a DNS server. Once the migration is complete, the new server is to be given the IP 172.16.100.10 again.
Install new domain controller
First, the "Active Directory Domain Services" role must be installed on DC2016 before DC2016 can be upgraded to Domain Controller:
This means that two domain controllers will be running during the migration from DC2008 to DC2016.
Once the role has been installed, DC2016 can be upgraded directly to DC:
The default settings can be left as they are:
In the next dialog, only the password for the recovery mode needs to be set; the checkboxes for "DNS server" and "Global catalog" remain checked:
Delegation is not required in most small environments, so the warning can be ignored:
The other dialogs can all be confirmed with "Next". In the last dialog, a summary with two warnings is displayed. In this case, the two warnings are to be regarded as notes:
- No delegation can be created for the parent DNS server -> not required here
- NT4 clients can no longer connect -> is also no longer required
After DC2016 was automatically restarted, there are now two domain controllers for the frankysweb.local domain:
The event logs should now be checked to see whether any errors have occurred during replication. A new user account can also be created as a test and then checked to see whether it is displayed on both DCs. If the replication works, you can continue.
FSMO Move rolls
The easiest way to move FSMO roles from DC2008 to DC2016 is to use the command line and the "ntdsutil" tool. The following commands can be used to move all FSMO roles from DC2008 to DC2016 (note: the connection is established to DC2016):
roles connection connect to server DC2016 quit transfer schema master transfer naming master transfer RID master transfer PDC transfer Infrastructure Master
The queries must then be confirmed with "OK".
The command "netdom query fsmo" can be used to check whether all FSMO roles have been moved:
Once this is done, you can move on to the next step.
Remove old domain controller
From now on, some downtime is necessary. The old domain controller will be removed and with it the old DNS server. All clients/servers that only have the IP 172.16.100.10 (from DC2008) configured as DNS server will not be able to find the new domain controller via DNS. This step should therefore be carried out in a maintenance window.
To avoid downtime, the new server can simply be set as the primary DNS server; if this is done on all clients, the IP address of the new domain controller does not need to be changed. However, this is exactly the case where the new server is to inherit the IP of the old server. Therefore continue in the text.
DC2008 is now downgraded, this works with the command "dcpromo":
The dialog for removing the domain controller opens. The "Delete domain, as this is the last domain controller in the domain" checkbox must NOT be ticked:
A new local administrator password must be entered in the following dialog:
The summary can be confirmed:
The domain controller role is now removed from DC2008 and the server can be restarted.
After DC2008 has been restarted, there is only the DC2016 computer account in the "Domain Controllers" OU:
DC2008 can be shut down after the restart, so the IP address is free and can be assigned to the new domain controller straight away. However, some tidying up work is necessary beforehand.
Cleanup work
The old DC2008 computer account can now be found in the "Computers" OU and can be deleted here:
The DNS setting of the network card on DC2016 can now be corrected, the IP of DC2008 is still entered here:
The DNS server 127.0.0.1 is now used here. Incidentally, it makes little sense to enter a router or public DNS server as the secondary DNS server here, as these cannot usually resolve the zones for the local Active Directory. In environments with only one DC, only 127.0.0.1 is used here:
In the DNS Manager, all zones and subzones must now be checked once, as corpses of the old domain controller often remain here. Corpses can be recognized and deleted here using the old IP / host names:
The delegated zone "_msdcs" also still has an old nameserver entry, which must also be corrected:
Here is an example of a corpse that was not deleted:
As I said, go through all zones and subzones once and check for old entries, there is always something left behind somewhere. Don't forget the reverse zone either.
Change the IP address of the DC
Changing the IP address is no longer rocket science. First, the IP is configured from DC2008 to DC2016:
This is followed by "ipconfig /registerdns":
The login service is then restarted:
Now clean up the DNS and delete the following three old entries:
Done. To be on the safe side, Exchange and SQL Server should be restarted once if available.
Hallo.
Kann mir jemand sagen, was vor/bei einer Migration zu beachten ist wenn es eine Vertrauensstellung zu einer anderen Domain gibt?
Wie sieht das nach der Migration mit den Gruppenrichtlinien aus?
Meine alte Windows 2008R2 Domäne hatte bereits Windows 10 Clients und dem entsprechend dann manuell eingespielte Administrative Vorlagen für Gruppenrichtlinien, die nicht immer korrekt angezogen wurden. Nachdem nun die alten Server durch Windows2016 ersetzt, die NTFRS Replizierung mit DFRSMIG aktualisiert und Replizierungsdurcheinander bereinigt wurde, frage ich mich, ob dabei nun die „alten“ verspuhlten Gruppenrichtlinien weiterhin verwendet werden, oder ob durch das Anheben der Domänenfunktionsebene auch die Gruppenrichtlinien von Windows 2016/Windows 10, die richtigen sind.
Ich hab dennoch das Gefühl das es nicht so passt. Weiss das jemand?
Kann dieses Tutorial auch noch für eine Migration 2008 auf 2019 genutzt werden, oder sind die Schritte dann anders?
Das umstellen auf Server 2019 DCs geht. Aber wenn du einen Exchange drin hast, welchen du noch upgraden musst, kann es sein dass du den alten AD Controller nicht gleich Nuken kannst. In manche Konstellationen brauchst du sogar Server 2012 R2 als Zwischen Domaincontroller mit dabei sein müssen damit die Upgrades tatsächlich 100% durchgehen.
Das hat meiner Meinung nach nur was mit der Gesamtstrukturfunktionsebene sowie der Exchange Version und der entsprechenden Kompatibilität zu tun (siehe Hinweis weiter oben von mir). Habe bereits einen „gewachsenen Exchange 2010“ mit 2019DCs und Funktionsebene 2012 erfolgreich auf Exchange 2016 migriert. Da sind die Publicfolder das größere Problem.
Hatte aber den Fall dass keine 2012 R2 DCs mehr in der 2012-Level Domain waren und wir den Exchange 2010 nicht loswerden konnten. Erst als wir temporär einen 2012 R2 DC wieder dazugenommen, und diesen im Exchange 2010 als einzigen DNS eingetragen, haben konnte der Exchange 2010 deinstalliert werden. Genau darauf zielt meine Warnung.
Das hat prinzipiell nun auch funktioniert. Auch der Exchange hat das alles gut verkraftet. Jedoch habe ich ein anderes Problem. Trotz des Bewegens der FSMO-Rollen auf den neuen DC kann ich den alten nicht herunterfahren, weil sich dann nichts mehr daran authentifizieren kann. Sogar der neue DC kennt sich dann selbst nicht. Völlig kurios. Daher wage ich es auch nicht, per dcpromo den alten herunterzustufen. Ich muss ihn aber aus der Domäne heraus bekommen, weil ich das AD-Schema anheben muss. Gibt es etwas, das ich machen muss, was nicht oben in der Anleitung steht?
Das ist die Grenze ab der man direkt schauen muss was Sache ist. Wenn der Server 2019 keine Update bekommt bevor er DC wurde gibt es Probleme, wenn irgendwelche Replikationen nicht so tun wie sie sollen gibt es Probleme. Hier gibt es zu viele Möglichkeiten wieso da was schief gegangen ist, und raten ist ab hier nicht mehr sinnvoll.
Der Tipp mit der Replikation war Gold! Tatsächlich hatte sich der Replikationsdienst verabschiedet, nachdem der alte Server nach einem Neustart nicht mehr sauber gestartet war. Ich konnte eben nach der Reparatur tatsächlich die Netzwerkverbindung temporär trennen und erkennen, dass nun der neue PDC genutzt wird. Auch lassen sich auf dem neuen Server nun endlich GPOs und sonstige AD-Daten wieder sauber bearbeiten.
Danke für die Ausführungen. Dann sollte alles passen – und wer seinen Exchange 2010 im Moment nicht mit dem aktuellsten Patch betreibt, dem ist ja eh nicht zu helfen (ich sag nur CVE-2020-0688).
Nein, wir haben auch von Exchange 2010 auf 2016 migriert und haben auch ADs mit Windows Server 2019 im Einsatz hängt ja auch von Deiner Domänenfunktionsebene ab und die ist bei uns auch noch auf 2008 R2. Was Du ja so noch lassen kannst.
Nachtrag Exchange 2010 ist ab SP3 RU22 oder höher kompatibel zur Gesamtstruktur Ebene 2016 (Windows Server 2016 auch). Siehe hier in der Matrix von Microsoft: https://docs.microsoft.com/de-de/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019
Danke erstmal für diese tolle Anleitung.
Bevor ich mich ans Umsetzen wage, wollte ich noch eins abklären:
Aktuell setzen wir Exchange 2010 auf Server 2008R2 ein (die Migration zu Exchange Online + Server 2019) wird im Anschluss an die DC/NS Migration als eigenes Projekt durchgeführt werden). Gibt es in dieser Konstellation Probleme, wenn ich den DC wie im Artikel beschrieben direkt auf 2019 hochziehe? Laut Microsoft ist Exchange 2010 ja nicht einmal mit einem DC 2016 kompatibel).
muss man den alten DC herunterstufen oder kann man nach dem Verschieben der Rollen den alten Rechner einfach herunterfahren und entsorgen?
Du solltest diesen auf jedenfall Depromoten, sonst hast Du später ev. Probleme und Leichen in Deinem AD. Du kannst in aber auch später zwingen den alten DC zu entfernen, falls Du das schon gemacht hast :-)
Jetzt bleibt noch einen Frage: Wie kann ich den Namen des neuen DC2016 zu dem alten Namen DC2008 umbennen. Somit wäre doch für diee Clients alles bei „Alten“…
Geht das problemlos über den Befehl netdom computername ALTER-COMPUTERNAME /add:NEUER-COMPUTERNAME?
Domänencontroller umbenennen ist nicht.
Alten Domänencontroller entfernen, und neuen mit dem Namen des alten aufsetzen. IP Ändern geht, aber Name nein.
DNS-Umstellung nicht ganz schlüssig.
Ich habe es so gelernt, dass man bei Installation der Rolle „Active Directory Domänendienste“ auch gleichzeitg die Rolle „DNS Server“ mitinstalliert. Durch das Heraufstufen des neuen Servers zum zweiten Domänencontroller wird das Active Directory dann auf den neuen Server repliziert, und da die Daten des DNS-Servers auch im Active Directory gespeichert sind ist direkt alles klar.
Nun stellt sich die Frage, ob die Clients ihre IP-Adressen von einem DHCP-Server erhalten, oder ob sie manuell eingetragen sind. Sofern auf dem alten Server auch ein DHCP-Server steckt, so muss auch dieser auf den neuen Server übertragen werden. In diesem Fall spielt es keine Rolle, ob der neue Server eine andere IP hat, als der alte Server. Der DHCP-Server regelt das schon – an den Clients genügt ein Neustart.
Sind die IP-Adressen (warum auch immer) an den Clients manuell eingetragen, empfiehlt sich natürlich dem neuen Server die IP-Adresse des alten Servers zu geben. In diesem Fall ist tatsächlich eine Downtime unumgänglich.
Hallo Frank,
super Anleitung Danke.
Wir haben zwei DC mit Windows 2008 R2 und einen Exchange Server 2010.
Ich möchte nächste Woche die beiden DC zu Windows 2016 Migrieren. Gibt es etwas zu beachten was den Exchange 2010 Server angeht?
Gruß
Michi
Hallo,
ich habe 3 DC, einen alten Win 2008, einen 2012 R2 und jetzt neu aufgesetzt einen Win 2016, der dann den 2008 ablösen soll. Das AD-Schema läuft aber noch auf Win 2000. Mein ehemaliger IT-Mann, der leider ausgewandert ist, hat auf dem DC 2008 auch noch die IP-Adresse des 1. DC Win 2000. Exchange ist 2010.
Frage: sollte ich zunächst AD anheben ? Oder erst den DC 2008 herausnehmen Oder ist diese Reihenfolge egal ?
Danke – Jörg
Du musst zuerst mindestens auf Domain Level 2008 anheben, bevor Du weitermachen kannst.
Was ist mit Adprep /Forestprep und Adprep /Domainprep /Gpprep, werden diese Schritte nicht mehr benötigt?
Hallo Fischle,
doch, die Strukturen müssen aktualisiert werden. Man kann das entweder mit den von Dir erwähnten Befehlen händisch machen. Alternativ werden die Strukturen automatisch von allein aktualisiert, sobald man auf dem neuen Server die Active Directory Domänendienste installiert.
Ich persönlich mag es jedoch lieber, wenn man es händisch macht. Geht bei dem Assistenten was schief, weiss man nicht, was im Hintergrund alles passiert ist – macht man es hingegen händisch step by step, kann ich bei Problemen immer an der Stelle eingreifen, wo was schiefgeht (aber eigentlich geht ja nichts schief).
Am Ende dann, wie im Artikel oben schon beschrieben, einmal mit „netdom query fsmo“ am besten am alten DC prüfen, ob der neue DC nun bei allen Rollen nun der neue Sheriff ist. ;-)
Anmerkung: es gibt tolle Bücher von Ulrich Boddenberg -leider keine aktuellen mehr. Aber ich persönlich habe im Buch „Windows Server 2012 R2“ nachgeschaut – dort ist alles Schritt für Schritt sauber erklärt. Passt auch für Win Server 2019 – da hat sich nichts geändert. Der Autor ist super gut, wenn es darum geht, Abläufe zu erlernen und allgemeines Verständnis zu bekommen. Im aktuellen Buch „Windows Server 2019“ von Peter Kloep findet man hingegen zu diesem Thema mal rein gar nichts.
Moin,
ich würde gerne einen SBS 2011 ablösen auf diese art und weise. Gibt es hier Erfahrungen?
Kann ich das einfach machen mit einem 2012 R2 oder gibt es was gesondertes zu beachten.
Ich lese nämlich das Kevin das problem fehlender SYSVOL und NETLOGON beklagt.
Liebe Grüße
René
Würde denn was dagegen sprechen einen CNAME im DNS von dem alten DC auf den neuen zu setzen, natürlich vorausgesetzt das sich der Namen ändert ?
Somit könnte man doch eventuell Fehler mit alten Einstellungen evtl. Bei Zugriff auf Freigaben o.ä umgehen.
Hallo Frank,
ich habe den Migration des Domaincontrollers von 2008 R2 zu Server 2016 dank der ausführlichen Anleitung erfolgreich vollzogen. Ich habe wie in der Anleitung die IP-Adresse vom alten DC auf den neuen DC übernommen. Bei mir erscheint im Netzwerksymbol ein gelbes Ausrufezeichen und das kein Internetzugriff besteht. Internet funktioniert, auch auf den Clients im Netzwerk. Hat jemand schonmal ein ähnliches Phänomen gehabt?
Viele Grüße
Marco
Hallo Frank,
wir haben vor kurzem ein SBS2011 auf einen neuen Domäncontroller 2016 migriert und hochgestuft.
Jedoch ist es so, dass auf dem neuen DC die Freigaben „SYSVOL“ und „NETLOGON“ fehlen.
Somit habe ich das Problem, dass die Rollen „PDC“ und „naming Master“ sich nicht übertragen lassen. Diese springen immer wieder auf den alten DC (SBS2011).
Gibt es hier eine Idee wie mann die Freigaben auf dem neuen DC wieder angezeigt bekommt oder hat jemand ein ähnliches Szenario schonmal gehabt und kann mir den ein oder anderen Tipp geben ?
Viele Grüße
Kevin
Moin!
Vielen Dank für den tollen Artikel!
Das mit der Migration des SYSVOL scheint jedoch ein essentieller Bestandteil im Rahmen einer solchen Migration zu sein. Könntest Du das eventuell ein wenig näher erläutern? Oder hat es einen guten Grund, dass Du das hier nicht erwähnst? Was hat es damit auf sich? Wann genau während der Migration sollte/muss das gemacht werden? Was sind die Voraussetzungen hierfür?
Herzlichen Dank und weiter so!
LG
Thorsten
Hallo Frank, soweit ich es verstanden habe, ist in Deinem Beispiel die Domain noch in der 2008 Domänenfunktionsebene. Wie sollte ich vorgehen, damit neuere Betriebssysteme auch berücksichtigt werden können?
Wie sieht es denn aus wenn ich den selber Computernamen (nicht nur IP) haben will wie der 2008/2012 ? Da sehr viele DNS Einträge auf diesen zeigen?
Hi, da ich das gleiche vor habe, würde ich auch gerne wissen, ob dies möglich ist den gleichen Namen, nachdem der alte DC heruntergefahren wurde, zu erteilen. Ich habe die Antwort von Pingback gelesen, aber das denke ich muss doch einfacher gehen, oder?
Besten Dank im voraus!
Hallo erstmal
Der Name sollte nach dem der alte DC aus der Domäne entfert wurde kein Problem sein, man kann mit Hilfe vom DNS-Server einen zusätzlichen Namen hinterlegen.
Hallo ,
in einigen Anleitungen wird empfohlen den alten DC vor dem Hochstufen des 2016er mittels
adprep /forestprep bzw. adprep /domainprep vorzubereiten… ist das nötig, bzw. was hat es für Folgen, das nicht zu tun?
grüße
Thomas
Es ist offiziell nicht unbedingt nötig, wenn die Domänen- und Forest-Funktionsebene mindestens 2003 ist. Allerdings fiel bei mir NTFRS auf die Nase, bis ich die Funktionsebenen auf dem alten DC auf 2008R2 aktualisiert hatte.
DFSRMIG wollte ich in dem Zustand nicht durchführen, da dafür explizit die einwandfreie Replikation zwischen allen DCs notwendig ist – und das war hier ja nicht gegeben.
Ich habe das gleiche Problem, der 2008R2 ist mir durch einen Stromausfall weggebrochen und auf dem
2016 war das AD nicht mehr erreichbar, nach dem der 2008R2 wieder hochgefahren ist ging es wieder.
Das heißt ich kann jetzt noch adprep /forestprep bzw. adprep /domainprep ausführen ?
Von alten Migrationen kenne ich es allerdings auch nicht anders und habe es immer vorher ausgeführt.
Hallo Frank,
bei mir läuft ein Exchange Server 2016 auf einem Windows Server 2012 und möchte jetzt den Server auf 2016 updaten. Der Server ist als zweiter Server in die Domäne eingebunden.
Würde es ausreichen wenn ich den Server 2016 mit gleichen Namen und IP Adresse neu installiere und den Exchange Server 2016 installiere und zum Schluss nur die Datenbank einbinde
Grüsse
Andy
Hallo Bernd,
Danke für deine Anleitung. Das hilft sehr. Ich habe ein Szenario bei dem ich 2 Server (Server und Backup) betreibe und beide sowohl HW als auch Windows ersetzen will. Ist mein Schluss richtig, dass ich einen Server einfach ausschalten kann, und den neuen direkt mit den Daten (Name und IP) des ausgeschalteten Rechners installieren und konfigurieren kann. Das ganze Spiel 2 mal mache, da ich ja zwei Rechner habe. Ich gehe davon aus, dass ich dazu auch FSMO ausführe, dann aber nicht transferiere sondern übernehme.
Danke für deine Antwort im Voraus!
Grüsse
Rolf
Hallo,
da ich auch nicht so oft den Server siedle, habe ich eine Frage:
In einer Anleitungen (https://docs.microsoft.com/en-us/windows-server-essentials/migrate/prepare-your-source-server-for-windows-server-essentials-migration#BKMK_MPT) steht, man soll das Migration Preparation Tool einsetzen.
Warum brauchst du das nicht?
Danke!
LG Bernd
Hallo Bernd,
im Artikel handelt es sich nicht um Windows Server Essentials. Daher wird auch kein Migration Preparation Tool benötigt.
Gruß,
Frank
Nachtrag: Beim Benutzernamen muss man die Domäne des alten Servers voranstellen [domäne]\[benutzer]
Jetzt komme ich erstmal weiter.
Hallo,
ich möchte nächstes Jahr den Server auch umziehen. Dafür habe ich zum testen eine VM mit Server 2008 R2 und eine VM mit Server 2019 Insider erstellt. Der neue Server findet zwar die Domäne des alten Servers aber Aufgrund falscher Anmeldeinfos oder dem Benutzerkontonamen komme ich nicht weiter. Welche müssen da rein? Der lokale Admin oder der Admin vom alten Server? Ich habe beides ohne Erfolg probiert.
Roger Schär:
Na klar geht das! Erst mal normale Migration auf 2016-DCs, quasi temporäre DCs, den alten DC sauber entfernen und den neuen DC mit genau dem Namen und der IP in die nun freie Lücke platzieren.
Ist halt Arbeit, ansonsten kein Problem. Und besser für die Zeit wenn niemand sonst arbeitet.
Einmal mehr, besten Dank für die tolle Anleitung.
Ich möchte in meinem Fall, dass nicht nur die IP Adresse von alten DC übernommen wird, sondern auch noch den Hostname. Am Ende der Migration soll also der neue DC gleich heisst wie der alte. Wie gehe ich da vor?
Tolle Anleitung! Danke!
Ich habe genau diesen Austausch in den nächsten Wochen vor.
In unserem kleinen Büro habe ich bisher den DC (Server 2008)und den Exchange 2010 auf einem PC laufen (ich weiß, das sollte man nicht machen, läuft aber seit 2012 problemlos). Muss ich noch zusätzlich etwas beachten, damit der Exchange auf dem alten DC weiterläuft wenn ich auf Server 2016 migriere wie beschrieben?
Der Exchange 2010 wird auf 2016 auf eigenem Server ebenfalls in den nächsten Wochen migriert, aber einen Schritt nach dem anderen :-)
@Bernd
Aufwand / Zeitabschätzung: Wie viel Aufwand ist es allen Geräten, Server und PCs mit festen IP Einstellungen mit dem neuen DNS zu konfigurieren gegen die Übernahme der IP des vorigen Domaincontrollers. Für die Domaincontroller alleine ist das vom Aufwand her egal ob man die IP übernimmt, da sehe ich keinen Unterschied.
Natürlich hat man immer zwei DNS Server eingetragen, aber Windows frägt erst nach einer Sekunde den zweiten eingetragenen. Je nach Dienst potenziert sich das schnell auf 10+ Sekunden da manche Dienste eben gleich 10+ DNS Anfragen gemacht werden. https://support.microsoft.com/en-us/help/2834226/net-dns-dns-client-resolution-timeouts
Andere OS-e bzw Geräte und deren Timing bezüglich DNS Timeouts sehen noch viel schlimmer aus, manche fragen nach 30 Sekunden den zweiten eingetragenen.
Hallo,
Motto: lieber einen Kaffee mehr trinken bevor ein Blödsinn passiert…
Aber wieso gleiche IP?
Am Hauptstandort hab ich eh 3 DCs, draußen 1-2, aber irgendeiner ist immer erreichbar.
FSMO rollen gehen eh nicht doppelt also wieso?
Hallo,
na zum Beispiel, weil der DHCP auf dem DC beim Provider für das MPLS-Netz gesetzt ist.
Bis der das aktualisiert hat dauert das Wochen!
Also entweder rechtzeitig vorher die neue IP mitteilen oder eben die IP mitnehmen.
Noch ein wichtiger Hinweis:
In einer Exchange 2010 Organisation werden offiziell keine Windows Server 2016 Domaincontroller unterstützt.
Hier die Exchange Kompatibilitätsmatrix beachten!
Sollte wieder funktionieren!
https://blogs.technet.microsoft.com/rmilne/2018/06/21/exchange-2010-support-for-windows-server-2016-domain-controllers/
Super Anleitung, vielen Dank für Deine Mühen!
Eine Sache mache ich anders:
Die DNS Einstellungen der LAN Karte vom 2016-er DC korrigiere ich sobald er mit-DC geworden ist, direkt nach dem Neustart. Dann noch DNS-Server und Client am 2016-er durchstarten und gut ist es.
Sobald der 2016-er mit DC geworden ist wird geprüft ob der DNS brav alles repliziert hat und ob NETLOGON sich brav repliziert (test via „Neues Textdokument.txt“ erstellen und in den anderen netlogons nachsehen ob es auftaucht).
RegisterDNS entfällt normalerweise, das macht er spätestens nach 15 Minuten selbst. Meist schneller, ich habe selten mehr als eine Minute gesehen bis die DNS Einträge automatisch angepasst werden, auf allen DCs.
Das manuelle transferieren der Rollen ist nicht zwingend nötig, aber ich mache diesen Schritt zur Sicherheit auch immer.
Wenn man das passend angeht kann der neue 2016-er DC die IP vom vorigen 2008-er oder 2012-er DC übernehmen, direkt nachdem der 2016-er DC geworden ist und die LAN Karte angepasst wurde. Aber dann muss man dem DNS und der AD zeit geben damit sie sich selbst sortieren. Selbst mit laufendem Exchange in der AD klappt dieses IP-tausch-Spielchen, man darf nur nicht ungeduldig oder Hektisch werden.