Zum Inhalt wechseln


Foto

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

Windows Server 2012 R2 Windows Server vNext

  • Bitte melde dich an um zu Antworten
10 Antworten in diesem Thema

#1 0lli

0lli

    Newbie

  • 6 Beiträge

 

Geschrieben 13. Dezember 2016 - 18:28

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.

 

 

 

 



#2 Doso

Doso

    Board Veteran

  • 2.456 Beiträge

 

Geschrieben 13. Dezember 2016 - 18:36

Das beweist mal wieder warum man bei einem DC kein Inplace Upgrade machen sollte.



#3 testperson

testperson

    Board Veteran

  • 4.511 Beiträge

 

Geschrieben 13. Dezember 2016 - 18:57

Hi,

 

wie kommt man denn auf so eine Idee bzw. was sollte denn da erreicht / getestet werden?

Wäre es nicht um Längen einfacher gewesen:

 

Neue(n) Hyper-V Host(s) installieren, 2 VMs installieren und promoten, alte DCs demoten, fertig.

 

Gruß

Jan


Good morning, that's a nice TNETENNBA!

#4 NorbertFe

NorbertFe

    Expert Member

  • 30.605 Beiträge

 

Geschrieben 13. Dezember 2016 - 19:36

Das wär dann nicht so ein langer Beitrag? :)

Make something i***-proof and they will build a better i***.


#5 0lli

0lli

    Newbie

  • 6 Beiträge

 

Geschrieben 13. Dezember 2016 - 19:48

@NorbertFe: vollkommen, richtig ;)

 

@testperson: Weil es Menschen gibt, die auf die tollsten Ideen kommen und ich einem Kunden ungern sage: "Hab ich noch nie gemacht.", also bot sich dieser Test an. Allerdings war ich von den Ergebnissen erstaunt, wenn ich mir andere Inplace-Upgrades anschaue. Vor allem von der noch ungelösten Frage.



#6 NorbertFe

NorbertFe

    Expert Member

  • 30.605 Beiträge

 

Geschrieben 13. Dezember 2016 - 20:30

Naja es gibt Dinge, da sag ich Kunden gern: Hab ich noch nie gemacht (PAUSE), weils nicht notwendig ist und besser anders geht. ;)

Make something i***-proof and they will build a better i***.


#7 DocData

DocData

    Board Veteran

  • 1.273 Beiträge

 

Geschrieben 13. Dezember 2016 - 21:08

Oder ein ungläubiges "Es gibt Leute die sowas ernsthaft planen?"... kurze Pause... Laptop zuklappen... "Dann bin ich leider der falsche Mann dafür"... aufstehen, verabschieden, gehen.

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#8 0lli

0lli

    Newbie

  • 6 Beiträge

 

Geschrieben 13. Dezember 2016 - 21:30

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).



#9 NorbertFe

NorbertFe

    Expert Member

  • 30.605 Beiträge

 

Geschrieben 13. Dezember 2016 - 23:05

Hat aber genau nix mit VMs zu tun und für fehlerhafte Sysvol und AD Replikation gibt's eigentlich genügend KB Artikel. ;) Nix für ungut, aber für mich ist das da oben halt ne Machbarkeitsstudie, deren Praxisgehalt ich nicht besonders hoch einschätze. Insofern abgeheftet unter Kuriosität. ;)

Bye
Norbert

Make something i***-proof and they will build a better i***.


#10 NilsK

NilsK

    Expert Member

  • 12.334 Beiträge

 

Geschrieben 14. Dezember 2016 - 08:08

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#11 zahni

zahni

    Expert Member

  • 16.390 Beiträge

 

Geschrieben 14. Dezember 2016 - 14:23

Und dann noch die VMs irgendwie  schräg von XEN nach Hyper-V verschoben. Das ist so vermutlich nicht  supported.

Zumal bei DCs auch überflüssig.


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!