0lli

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

Schau mal mit net share auf dem neuen DC ob SYSVOL und NETLOGON da sind. Hört sich so an, als wäre die Erstsynchronisation des AD nicht gelaufen. Check auch mal ob der netlogon Dienst läuft und welches Netzwerkprofil in den Netzwerkeinstellungen angezeigt wird. Wenn das auf Privat oder Öffentlich steht, wird das nix. Dann also DNS Einstellungen in der TCP/IP überprüfen und ggf. mal NLASVC neu starten. EDIT: dcdiag durchlaufen lassen und gucken ob der PDC Emulator sauber ist, dann wäre w32time auf dem primären DC noch ein Kandidat. Liegen alle Betriebsmasterrollen auf dem primären DC und laufen? KCC ok?

Es wäre vielleicht auch noch die Frage im Raum, ob VLANs im Einsatz sind. Wenn der Hyper-V mit dem Netz sprechen kann und die VMs nicht, dann könnte das eine Rolle spielen. Erst recht wenn eine VM multi-homed ist. Mehrere VLANs in eine VM zu prügeln geht nur über Trunking, mit der Powershell. Nächste Fragen wären so Dinge wie IPSec, Taskabladung etc. siehe Mal: https://msdn.microsoft.com/de-de/library/jj679878%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396

Hast Du mal darauf geachtet, ob er beim Herunterfahren kurzzeitig eine Speicherfehlermeldung abwirft und dann gleicht wieder schließt? Check mal den Arbeitsspeicher und die Plattentreiber.

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

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: Gefreezte VMs stoppen, jeweils mit: xl destroy <Server> Volumegroup der jeweiligen VM finden und Datei kopieren mit: dd if=/dev/xenvg/<server-hdd> | bzip2 -9f > /pfad/zur-neuen/imagedatei.img.bz2 ​​Imagedateien der VMs zum neuen Windows Server 2016 mit Hyper-V kopieren, falls nicht schon passiert. Ubuntu auf den Windows Server 2016 herunterladen, falls nicht DVD Image zur Hand. 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. Ausreichend große VHDx für die jeweilgen Imagedateien erzeugen, vorzugsweise mit dynamischer Größe. VHDx Dateien für die zu kopierenden VMs als SCSI-Festplatten an die Ubuntu-VM anhängen. Mit diskmgmt.msc oder diskpart eine weitere VHD erzeugen, formatieren und einhängen. Die Imagedateien auf diese VHD kopieren, die VHD anschließend mit diskmgmt.msc oder diskpart wieder aushängen. Die VHD mit den Imagedateien als SCSI-Festplatte an die Ubuntu VM hängen. Die Ubuntu-VM starten und Ubuntu im Live-Modus starten. Ein Terminal öffnen und eine Root-Shell starten mit su --login oder sudo bash ​​Die VHD mit den Imagedateien einhängen mit: mount /dev/sdc1 /mnt Image vom ersten DC zurück kopieren mit: bunzip2 -dc /mnt/imagedatei-von-dc1.img.bz2 | dd of=/dev/sda Image vom zweiten DC zurück kopieren mit: bunzip2 -dc /mnt/imagedatei-von-dc2.img.bz2 | dd of=/dev/sdb Synchronisieren mit: sync Die VHD mit den Imagedateien aushängen mit: umount /mnt Die Ubuntu-Live VM herunterfahren und die SCSI-Festplatten aus den Einstellungen der VM entfernen. Für jeden DC eine neue Generation 1 VM erstellen und die jeweilige VHDx als IDE Festplatte zuordnen. In den Gastdiensten die Zeitsynchronisation deaktivieren (der DC wird der Zeitserver, nicht der Hyper-V Host). Das Windows Server 2016 Installations-DVD ISO-Image als DVD-Laufwerk in die VM einhängen. DIE VM DARF UNTER KEINEN UMSTÄNDEN ZUERST VON DER VHDX STARTEN!!! ​​Von der Windows Server 2016 DVD starten lassen und Computerreparaturoptionen öffnen. In den erweiterten Optionen die Eingabeaufforderung öffnen. Weiter geht's nach dem Weg mit der Windows Server Sicherung... Falls die Windows Server Sicherung doch funktioniert, klappt auch der einfachere Weg: Für jeden DC eine neue Generation 1 VM erstellen und eine VHDx mit ausreichender Größe erzeugen. Das Windows Server 2016 Installations-DVD ISO-Image als DVD-Laufwerk in die VM einhängen. Von der Windows Server 2016 DVD starten lassen und Computerreparaturoptionen öffnen. In den erweiterten Optionen die Eingabeaufforderung öffnen. 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 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 Wenn die Wiederherstellung erfolgreich abgeschlossen wurde, bcdboot G:\WINDOWS /S F: ausführen - wenn nicht, tja.... 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.