Jump to content

Windows Server 2012 R2 DC Upgrade auf 2016 - Erfahrung und Probleme


0lli
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo Community,

 

ich möchte hier kurz meine kürzlichen Erfahrungen mit einem Domain Controller Upgrade von Windows Server 2012 R2 zu Windows Server 2016 mit euch teilen.

 

Zunächst einmal vorab:

​Wer dies in einer Produktivumgebung vor hat sollte wissen, dass es zum aktuellen Zeitpunkt zu Anmelde- und Replikationsproblemen nach dem Inplace Upgrade kommen kann. Außerdem übernehme ich keine Gewähr für die Richtigkeit meiner Angaben und keine Haftung für Beschädigungen aller Art - die Nutzung meiner kleinen Info's hier geschieht auf eigene Gefahr.

 

 

Die Ausgangsumgebung:

  • Debian Linux mit XEN als Host für Windows Server VMs
  • Windows Server 2012 R2 VM als primärer DC auf dem XEN Host
  • Windows Server 2012 R2 VM als sekundärer DC auf dem XEN Host

 

Die Zielumgebung:

  • Windows Server 2016 mit Hyper-V als Host für Windows Server VMs
  • Windows Server 2016 VM als primärer DC (Inplace Upgrade)
  • Windows Server 2016 VM als sekundärer DC (Inplace Upgrade)
  • eine weitere Windows Server 2016 VM als sekundärer DC (neu zu installieren)

 

Als Erstes möchte ich noch erwähnen, dass der Gedanke auf einen Hyper-V Host zu wechseln erst nach dem Inplace Upgrade aufkam und zwar weil es zu seltsamen Verhalten einiger Clients kam - ich vermutete zuerst einen Zusammenhang mit den GPLPV Treibern und Windows Server 2016.

 

Zunächst einmal lässt sich das Inplace Upgrade sehr einfach durch starten der Setup Routine und der Wahl des richtigen Upgradepfades durchführen. Das Upgrade lief auf beiden Windows Server 2012 R2 VMs problemlos durch und nach dem Neustart standen, nach ein wenig Wartezeit, zwei Windows Server 2016 DCs zur Verfügung. Da die Anmeldung als Domain-Admin problemlos verlief, blieben zunächst zwei schwerwiegende Probleme unentdeckt, nämlich der zu diesem Zeitpunkt bereits tote Anmeldedienst (Netlogon), der Ausfall der PDC Betriebsmaster Rolle und das Versagen der DFS-Replikation.

 

Nachdem sich vereinzelte Clients über Anmeldeprobleme an den DCs beklagten, diverse Authentifizierungs- und LDAP-Tests allerdings keine Probleme zeigten, es zudem noch zu Performanceeinbrüchen und Paketverlusten in der Netzwerkkommunikation kam (Ursache unklar), vermutete ich ein Treiberproblem mit den für XEN installierten GPLPV Treibern. Um dem Problem (und evtl. neuen Problemen im Zusammenhang mit Windows Server 2016 und XEN) gänzlich aus dem Weg zu gehen, entschied ich die VMs zu sichern und von XEN zu Hyper-V zu migrieren.

 

Für diejenigen, die wissen wollen wie man das machen kann - Migration von XEN zu Hyper-V.

 

Zunächst wollte ich die Windows Server Sicherung einsetzen, um die DCs zu sichern und dann auf einer VHD wiederherzustellen, doch leider freezten die VMs während der Sicherung und ich musste den Linux-Way mit DD gehen:

 

  1. Gefreezte VMs stoppen, jeweils mit: xl destroy <Server>
  2. Volumegroup der jeweiligen VM finden und Datei kopieren mit: dd if=/dev/xenvg/<server-hdd> | bzip2 -9f > /pfad/zur-neuen/imagedatei.img.bz2
  3. ​Imagedateien der VMs zum neuen Windows Server 2016 mit Hyper-V kopieren, falls nicht schon passiert.
  4. Ubuntu auf den Windows Server 2016 herunterladen, falls nicht DVD Image zur Hand.
  5. Eine Generation 1 VM für Ubuntu erstellen, Ubuntu DVD als DVD-Image hinzufügen und der VM 2 GB Ram oder besser mehr geben.
  6. Ausreichend große VHDx für die jeweilgen Imagedateien erzeugen, vorzugsweise mit dynamischer Größe.
  7. VHDx Dateien für die zu kopierenden VMs als SCSI-Festplatten an die Ubuntu-VM anhängen.
  8. Mit diskmgmt.msc oder diskpart eine weitere VHD erzeugen, formatieren und einhängen.
  9. Die Imagedateien auf diese VHD kopieren, die VHD anschließend mit diskmgmt.msc oder diskpart wieder aushängen.
  10. Die VHD mit den Imagedateien als SCSI-Festplatte an die Ubuntu VM hängen.
  11. Die Ubuntu-VM starten und Ubuntu im Live-Modus starten.
  12. Ein Terminal öffnen und eine Root-Shell starten mit su --login oder sudo bash
  13. ​Die VHD mit den Imagedateien einhängen mit: mount /dev/sdc1 /mnt
  14. Image vom ersten DC zurück kopieren mit: bunzip2 -dc /mnt/imagedatei-von-dc1.img.bz2 | dd of=/dev/sda
  15. Image vom zweiten DC zurück kopieren mit: bunzip2 -dc /mnt/imagedatei-von-dc2.img.bz2 | dd of=/dev/sdb
  16. Synchronisieren mit: sync
  17. Die VHD mit den Imagedateien aushängen mit: umount /mnt
  18. Die Ubuntu-Live VM herunterfahren und die SCSI-Festplatten aus den Einstellungen der VM entfernen.
  19. Für jeden DC eine neue Generation 1 VM erstellen und die jeweilige VHDx als IDE Festplatte zuordnen.
  20. In den Gastdiensten die Zeitsynchronisation deaktivieren (der DC wird der Zeitserver, nicht der Hyper-V Host).
  21. Das Windows Server 2016 Installations-DVD ISO-Image als DVD-Laufwerk in die VM einhängen.
  22. DIE VM DARF UNTER KEINEN UMSTÄNDEN ZUERST VON DER VHDX STARTEN!!!
  23. ​Von der Windows Server 2016 DVD starten lassen und Computerreparaturoptionen öffnen.
  24. In den erweiterten Optionen die Eingabeaufforderung öffnen.
  25. Weiter geht's nach dem Weg mit der Windows Server Sicherung...

 

Falls die Windows Server Sicherung doch funktioniert, klappt auch der einfachere Weg:

  1. Für jeden DC eine neue Generation 1 VM erstellen und eine VHDx mit ausreichender Größe erzeugen.
  2. Das Windows Server 2016 Installations-DVD ISO-Image als DVD-Laufwerk in die VM einhängen.
  3. Von der Windows Server 2016 DVD starten lassen und Computerreparaturoptionen öffnen.
  4. In den erweiterten Optionen die Eingabeaufforderung öffnen.
  5. diskpart eingeben und starten, dann folgende Befehle ausführen (ACHTUNG: VHD WIRD GELÖSCHT):
    • select disk 0
    • create part pri size=128
    • format fs=fat quick
    • assign letter=f
    • active
    • create part pri
    • format fs=ntfs quick
    • assign letter=g
    • exit
  6. C: aus der Datensicherung auf die neue VHD wiederherstellen (in der Annahme, dass wir nur C: brauchen), mit:
    wbadmin start recovery -itemtype:volume -items:c: -recoverytarget:g: -machine:dc01 -backuptarget:e: -version:mm/dd/YYYY-HH:MM
  7. Wenn die Wiederherstellung erfolgreich abgeschlossen wurde, bcdboot G:\WINDOWS /S F: ausführen - wenn nicht, tja....
  8. Jetzt sind wir quasi an der selben Stelle, an welcher die Ubuntu-Lösung - oben beschrieben - aufhört.

Nun kommt der nicht so witzige Teil. Denn wenn wir nun die VM starten würden, crashed sie mit einem BSOD und verweist auf den XENPCI Treiber oder meckert über ein INACCESSIBLE BOOT DEVICE. Ursache hierfür ist die Verwendung von Hyper-V im Zusammenhang mit den noch existenten GPLPV Treibern auf den VMs. Da wir die Treiber nicht einfach so bereits auf dem XEN System herauswerfen können - Resultat wäre vermutlich ebenfalls ein INACCESSIBLE BOOT DEVICE - außerdem funktioniert die reibungslose Deinstallation der GPLPV Treiber aktuell genauso wie folgend beschrieben - verwenden wir nun die folgende Methode. Sowohl bei dem Ubuntu-DD-Weg, als auch bei der Windows Recovery Methode mit wbadmin stehen wir nun an der gleichen Stelle, nämlich einer Eingabeaufforderung im Windows-PE.

 

Folgendes kann man tun, damit die VMs unter Hyper-V starten können:

  • Auf das Laufwerk mit der Windows Server 2016 Installation des DCs wechseln, ich nenne es mal nachfolgend J:
  • rmdir /s /q "J:\Program Files (x86)\XEN PV Drivers\"
  • del /q J:\WINDOWS\SYSTEM32\DRIVERS\*XEN*
  • del /q J:\WINDOWS\INF\OEM*.?NF
  • Im Anschluß regedit starten und auf HKLM wechseln.
  • Auf Datei und Struktur laden klicken, dann J:\WINDOWS\SYSTEM32\CONFIG\SYSTEM wählen
  • Im nachfolgenden Fenster temp eingeben.
  • HKLM\temp\SYSTEM erweitern
  • in HKLM\temp\SYSTEM\ControlSet001\Services und HKLM\temp\SYSTEM\ControlSet002\Services die Unterstrukturen XENPCI, XENVBD und XENNET löschen.
  • Zurück gehen zu HKLM\temp und nach UPPERFILTERS suchen
  • Jedes Vorkommen des Wertes mit XENPCI aus der UPPERFILTERS Suche löschen (nur den Wert mit seinem Schlüssel, nicht die Struktur!)
  • Zurück gehen zu HKLM\temp, auf Datei und Struktur entladen klicken, danach regedit schließen.
  • In der Eingabeaufforderung wpeutil reboot eingeben und die VM starten lassen.

Nach einer kurzen Hardwareerkennung sollten wir nun die "fertig" migrierten 2016er VMs auf dem Hyper-V haben.

 

 

 

Nun aber zum Wesentlichen, nämlich der Tatsache, dass wir zwar nun "funktionierende" Windows Server 2016 VMs als DCs haben sollten, diese aber immer noch über ein paar heimliche Probleme verfügen. Zum Beispiel können sich Clients noch immer nicht anmelden und spätestens jetzt war auch mir klar, es hat nichts mit einem Treiberproblem zu tun. Nach einem fehlerüberhäuften dcdiag warf ich einen Blick auf die Dienste und stellte fest, dass der Anmeldedienst, erstens: nicht läuft und zweitens: auf manuell eingestellt war. Ein kurzes, ungläubiges googeln brachte dann die Gewissheit: MS wies freundlich in einem KB Artikel darauf hin, dass dies nun einmal passiert, wenn man ein Inplace Upgrade von 2012 R2 auf 2016 macht. Dumm gelaufen, aber ein Umstellen des Anmeldedienstes von manuell auf Automatik und ein Start des netlogon Dienstes brachte dann den gewünschten Erfolg und nach einem Neustart der Network Location Awareness mit net stop nlasvc ​(ja, es startet von selbst neu) wandelte dann auch das Netzwerkprofil von ÖFFENTLICHES NETZWERK bzw. PRIVATES NETZWERK in Domäne um.

 

DCDIAG zeigte aber am Ende seines Berichtes noch an, dass der PDC Emulator nicht laufen würde, weil es ein Problem mit dem Zeitgeber geben würde. Ein Blick in die regedit, HKLM\SYSTEM\CurrentControlSet\Services\W32Time brachte mir dann die Erkenntnis, dass das Upgrade zudem den Zeitgeberdienst auf seine Ausgangswerte zurücksetzte - was für DCs keine gute Idee ist.

 

Gelöst habe ich das Problem mit folgenden Änderungen:

  • HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config - AnnounceFlags auf Wert 5
  • HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters - Type auf Wert NTP
  • HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters - NtpServer auf Wert 0.de.pool.ntp.org,0x1

Nun noch ein net stop w32time und net start w32time und schon zeigte dcdiag, dass wieder alles im Lot sei....außer.... DFS-R würde auf die Replikation warten...

 

Ich dachte eigentlich ich hätte das Problem mit einem repadmin /syncall <dcname> /APed gelöst, was auch erfolgreich quittiert wurde und sodann keine Fehler mehr im DFS-Replikationslog angezeigt wurden. Aber nun tat ich folgendes: Ich setzte eine neue VM der Generation 2 auf und führte eine frische Windows Server 2016 Installation durch. Ich hob die neue VM in die Domäne, was problemlos klappte, installierte ADDS und stufte die Box zu einem Domänencontroller hoch. Dummerweise fiel mir eher zufällig auf (nach dem Shutdown der ersten beiden DCs gingen die Anmeldungen nicht mehr, obwohl netlogon lief), dass der neue DC noch immer auf die Erstreplikation wartet und zudem SYSVOL und NETLOGON Freigabe fehlten und HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\SysVolReady noch immer auf 0 stand. Eine manuelle Replikation wurde zwar mit einem freundlich - OK - quittiert, nur wurde weder NETLOGON noch SYSVOL Daten repliziert.

 

Nach der Installation der DFS-Verwaltung und einem Integritätsbericht wurde dann klar, dass alle 3 Domänencontroller auf die Erstsynchronisation warten und somit überhaupt nichts passieren würde. Da ich nun bereits auch über den ADSIEDIT.MSC in den NTDS-Settings der einzelnen Domänencontroller versuchte msDFSR-Enabled und msDFSR-Options anzupassen und sowohl authoritative als auch non-authoritative restore nicht zu einer funktionierenden Replikation führten (auch eine Änderung von HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\SysVolReady brachte nichts), bin ich nun an der "ICH BIN RATLOS"-Stelle angekommen.

 

Falls jemand Rat weiß oder eine Idee hat, wäre dies nicht schlecht.

 

PS: Die DCs sind übrigens keine Produktivmaschinen, aber eine Lösung des seltsamen Problems wüsste ich schon gern ;)

Frohes Fest und guten Rutsch!

 

 

---

 

Sorry, for my bad Deutsch, aber schnell denken und tippen heißt auch mal Buchstaben, Wörter und ganze Sätze vergessen/verdrehen/verwechseln.

 

VMs wurden erfunden, damit die problemverantwortlichen, kopfschmerzverursachenden Computer nicht mehr so ohne Weiteres von ihren Administratoren verprügelt werden können.

 

 

 

 

Link zu diesem Kommentar

Nun, ich finde es dennoch nicht ganz uninteressant zu wissen, warum die Replikation auf allen DCs nun auf die Erstsynchronisation wartet und wie man dieses Problem löst. Unabhängig davon ist es keine Seltenheit, VMs von einem Hypervisor zu einem Anderen zu migrieren. Klar ist das Szenario..... speziell... aber ich habe den selben Spaß nun mal ohne Inplace-Upgrade, nur mit den 2012ern probiert, klappt erwartungskonform problemlos.

 

Ich halte es deshalb für sinnvoll zu wissen, weil es einige dieser migrierten VMs gibt und wenn jemand dann auf die wahnwitzige Idee kommt auf eben dieser VMs ein Inplace Upgrade durchzuführen sollte man schon irgendwo finden können, warum Dinge plötzlich kaputt sind (und evtl. wie man sie fixt).

Link zu diesem Kommentar

Moin,

 

also ... wenn ich dich richtig verstehe, hast du beide DCs gleichzeitig aktualisiert? Dann ist es nicht verwunderlich, dass es zu Replikationsproblemen kommt, sondern zu erwarten. Sowas ist doch völlig praxisfern.

 

Abgesehen davon, dass es auch genau keinen Vorteil gibt, ausgerechnet einen DC per In-place zu aktualisieren.

 

Gruß, Nils

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...