Server 2022 Update mit Fehlschlag

« | 03 Oct 2021 | »

Seit August steht der Windows Server 2022 zur Installation bereit. Basierend auf dem Kernel 21/H2 sollte er eigentlich Server 2021 heißen, aber das war ja bei Server 2019 mit 18/09 damals auch nicht anders.

Und ich möchte nun meinen Domain Controller von Server 2016 auf den “letzten Stand” bringen. Na mal sehen, ob Microsoft das hinbekommt.

---

Server 2016 Zustand

Ich bin mit meinem inzwischen 3 Jahre durchlaufenden Server 2016 grundsätzlich zufrieden. Die Performance ist eben so, wie man es von einem Intel Atom erwarten kann: Bescheiden. Er würde zwar im “Extended Support” noch weitere 5 Jahre “OK” sein, aber es gibt ein paar Dinge, die mir trotzdem nicht so ganz gefallen.

• Updates dauern ewig.
  Das melden auch andere Seiten, dass Windows Updates in Server 2016 viel länger brauchen (beim Suchen angefangen), als z.B. im Server 2019. Hier erhoffe ich mir Verbesserungen
• Defekter Grafiktreiber.
  Tja, seit 3 Jahren habe ich den Intel-Treiber explizit deaktivieren müssen, damit ihn Windows-Update nicht erneuert und muss mit der Krücke von VGA-Kompatibilitätsteil leben. Zum Glück braucht ein Server keine Grafik, denn der “empfohlene” Treiber generiert sofort Bluescreens.
• Docker Support.
  Unter 2016 war das noch ein mühsames Unterfangen und die Images waren riesig. Mit 2022 soll alles nochmals viel kleiner und performanter werden … Na ich bin gespannt.

Upgrade Fehlschlag

Ein Domain Controller Update bereitet mir stets Sorgen. Zwar ist mir bisher noch keines misslungen, aber wenn was Schlimmes passiert, darf ich die Domäne entweder mühsam wiederherstellen oder neu aufsetzen … mit allen PCs dazu.

Die Setup-ISO-Datei als DVD Laufwerk eingebunden, startet man wie üblich setup.exe und die Zustandsanalyse beginnt.
Bei mir kamen dann gleich drei Problempunkte:

• Empfehlung: Server 2008 Schema ist veraltet.
  Lösung: Ich habe die Domäne und den Forest auf den Server 2008 R2 AD Standard gehoben.
• Info: Active Directory Federation Services müssen nach dem Upgrade neu installiert werden.
  Gut, wer weiß, ob ich die überhaupt noch brauche…
• Notwendig: adprep muss das AD-Schema vorher aktualisieren.

Active Directory on this domain controller does not contain Windows Server 2022 ADPREP /FORESTPREP updates.

Dazu geht man ins DVD-Verzeichnis d:\support\adprep und führt dort adprep /forestprep mit Admin-Rechten aus.
Dort muss man das Update als “unumkehrbar” abnicken und eine Minute warten, bis das Active Directory die Änderungen eingespielt hat.

Wenn man nun den Windows-Setup Dialog mit der Info Meldung “Refresh”-t, kommt fast die gleiche Meldung nochmal:

Active Directory on this domain controller does not contain Windows Server 2022 ADPREP /DOMAINPREP updates.

Jetzt wird also mit adprep /domainprep die eigene Domäne auf Stand gebracht.

Tja und dann läuft Windows Setup … außer natürlich, man hat ein Mainboard, dessen Grafikkarten-Treiber das System einfrieren lässt …

Dann versucht das System nämlich sich zurückzusetzen, scheitert dabei und die ganze Installation ist beim Teufel.
Jetzt weiß ich also, wie man ein Upgrade versemmeln kann.

FAIL !

Neuinstallation und manuelles AD-Reset

Mit dem ISO per Rufus auf dem USB Stick startete ich also ein neues Server Setup mit neuer SSD für eine gänzlich jungfräuliche Installation. Das funktionierte auch alles problemlos, bis es dann (so wie auch beim Server 2016) zum Windows Update des Grafik-Treibers kam und wie damals löste ich das Problem per manueller Deaktivierung des Treibers im “abgesicherten Startmodus”.

Ärgerlich! Das Problem wurde also nicht behoben.

Jetzt kam der ungute Teil. Mein zweiter Domain-Controller hielt keine der FSMO-Rollen und mein primäres System war ja tot.

Was für ein Glück, dass ich vor vielen Jahren ADSI studiert hatte und die Attribute am verbliebenen DC selbst per ADSI-Edit Tool anpassen konnte:

Angenommen, die eigene Domäne heißt mydomain.net, dann findet man die 4 Objekte mit den FSMO-Attributen unter folgenden Namen:

• Domain Master: DC=mydomain,DC=net
• RID Master: CN=RID Manager$,CN=System,DC=mydomain,DC=net
• Infrastructure Master: CN=Infrastructure,DC=mydomain,DC=net
• PDC Emulator Master: CN=Partitions,CN=Configuration,DC=carbis,DC=mydomain,DC=net
• Schema Master: CN=Schema,CN=Configuration,DC=mydomain,DC=net
  (dazu muss man sich zur separaten Schema-Partition verbinden)

Diese Objekte enthalten stets ein Attribut mit Namen fSMORoleOwner und dieses hält dann Namen des früheren Domain Controllers, z.B.: CN=NTDS Settings,CN=Old-DC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=mydomain,DC=net

Hier tauscht man den Old-DC Eintrag durch den Namen des neuen gewünschten Servers und startet neu. Jetzt ist der alte “sekundäre” Server zum primären aufgestiegen.
Diese Schritte kann man zwar nicht in der GUI, jedoch aber mit ein paar Kommandozeilen-Tools hinbekommen, die ich mir aber nie gemerkt habe, weil ich ja schon den “nativen Weg” kannte.
Am Ende kann man nun den alten Server in allen AD-GUIs entfernen.

So konnte ich dann meinen neu aufgesetzten neuen DC in die Domäne aufnehmen, ihn wieder zum DC “promoten” und am Ende die Rollen wieder zurückübertragen (diesmal per GUI wie es sich gehört).

Fazit

Ich bin total angepisst wegen dem Grafikkarten-Crash … und gleichzeitig mit mir selbst zufrieden, dass der manuelle AD-Restore so problemlos ablief.

Nun wissen wir also, dass Windows Setup ein großes Problem hat, wenn die letzten Einrichtungsschritte fehlschlagen, denn zu diesem Zeitpunkt funktioniert das Zurückrollen offenbar nicht.
Ich vermute mal, es liegt daran, dass auch die UEFI Partition aktualisiert wurde und nicht mehr zurückgesetzt werden konnte, und so landet man in einem nicht-boot-baren Zustand.

Aber, in Sachen Performance hat sich das Update voll und ganz ausgezahlt. Das System regiert nun wesentlich schneller und auch Updates sind im Gegensatz zu früher zügig eingespielt.

Ich hoffe, das bleibt auch so …