Windows Server Upgrade - eine Übersicht

Über diesen Beitrag

Alle Jahre wieder steht eine Aktualisierung für Windows an.
Und typischerweise verlaufen solche Aktualisierungen nie ganz ohne Schwierigkeiten oder Besonderheiten der neuen Version.

Dieser Beitrag nennt einige Dinge, auf die ich in meinen Projekten gestoßen bin. Dadurch müssen sich andere hoffentlich nicht mehr lange am Kopf kratzen, wenn sie einmal auf diese Themen stoßen.

Wichtig: nicht alle Themen stehen direkt mit Windows Server 2025 in Zusammenhang (d.h. Windows Server 2025 ist nicht immer die Ursache), sie können also durchaus auch mit anderen Versionen auftreten.

Automatisierte Installation und Partitionierung

Windows-Betriebssysteme können über mehrere Varianten automatisch bereitgestellt werden. Die Basis hierfür ist die Datei AutoUnattend.xml, mit der die Installationsparameter definiert werden (z.B. Anzahl der Partitionen, zu installierende Serverrollen, spezifische Einstellungen ,usw.).

Bisher konnten hierfür problemlos auch Dateien verwendet werden, die für frühere Versionen des Betriebssystems erstellt worden sind. Dies funktioniert für Windows Server 2025 zumindest im Kontext der Partitionierung jedoch nicht mehr - die Installation bleibt mit einer Fehlermeldung hängen:

Tests hierzu ergaben, dass Windows Server 2025 offensichtlich zwingend die Wiederherstellungspartition erstellen möchte. In früheren Versionen war dies optional. Leider ist es nicht ausreichend, der Konfiguration einfach eine weitere Partition hinzuzufügen, dieses Vorgehen schlägt ebenfalls fehl.

Die gefundene Lösung ist daher eher ein Umgehen des Standardvorgehens - die Partitionen werden nicht länger innerhalb des XML-Codes definiert, sondern mittels eines separaten Kommandozeilenskripts erstellt, welches diskpart verwendet. Es sieht zwar während der Installation ein wenig seltsam aus (es werden zahlreiche Kommandozeilenfenster schnell geöffnet und wieder geschlossen), aber es funktioniert!

Das Skript erstellt u.a. auch die Wiederherstellungspartition und konfiguriert diese so wie benötigt. Nach der Installation von Windows Server kann diese mithilfe eines weiteren Befehls wieder entfernt werden, falls diese nicht benötigt wird (in einer virtualisierten Umgebung wird die Partition normalerweise nicht benötigt, da hier auch die Installations-ISO für Reparaturen verwendet werden kann).

Gruppenrichtlinien für WSUS werden ignoriert

Auf dieses Problem bin ich zunächst über einen LinkedIn-Beitrag gestolpert. Unternehmen verwenden üblicherweise die Serverrolle Windows Server Update Services, um Aktualisierungen für Microsoft-Produkte zentral steuern zu können. Es scheint hierbei zunächst so zu sein, dass Windows Server 2025 die Einstellungen, die über Gruppenrichtlinien gesetzt werden, ignoriert und einfach eigene Standardeinstellungen verwendet. Dies ist daran erkennbar, dass trotz konfigurierter Einstellungen weiterhin alle Optionen verfügbar sind (normalerweise sind einzelne Funktionen ausgegraut).

Interessanterweise ist Windows Server 2025 auch nicht (mehr) in der Liste der Betriebssysteme aufgeführt, auf die der Artikel zur Einrichtung der Gruppenrichtlinien angewendet werden kann. Das könnte zu der Annahme führen, dass Windows Server 2025 WSUS nicht länger unterstützt, zumal die Serverrolle von Microsoft abgekündigt wurde. Dies passt jedoch nicht damit zusammen, dass der WSUS weiterhin auch Aktualisierungen für Windows Server 2025 anbietet (im WSUS wird die Version als "Microsoft Server Operating System-24H2" angegeben).

Der LinkedIn-Post verweist auf einen weiteren Artikel, der die Ursachen für dieses Verhalten im Detail beschreibt: https://www.borncity.com/blog/2025/09/11/wsus-erkennt-updates-fuer-windows-server-2025-nicht/#comment-229759

Demnach muss unter Windows 11 und Windows Server 2025 die folgende Richtlinie zusätzlich gesetzt werden, damit wieder Aktualisierungen vom WSUS bezogen werden:

Quelldienst für spezifische Windows Update-Klassen angeben

Wenn diese Richtlinie aktiviert ist und alle Einstellungen auf "Windows Server Update Services" konfiguriert sind, übernimmt Windows Server 2025 diese und alle anderen Einstellungen so wie zuvor. Dementsprechend scheint es sich hierbei eher um einen Bug als um einen stillen/erzwungenen Abschied von WSUS zu handeln.

Inplace-Upgrade und ReFS-formatierte Datenträger

Bei einem Upgrade bin ich einmal auf einen Server gestoßen, der einen zusätzlichen Datenträger für eine SQL Express-Instanz nutzte. Dieser Datenträger war mit ReFS formatiert, da ReFS insbesondere für Datenbanken eine höhere Resilienz im Vergleich zu NTFS aufweist.

Ein Inplace-Upgrade ist bei einem solchen Server jedoch eher eine schlechte Idee. Während andere Upgrades typischerweise nach 30-60 Minuten abgeschlosssen sind, lief das Upgrade in diesem Fall 3 Stunden. Nach dem Upgrade konnte außerdem die SQL-Instanz nicht mehr gestartet werden.

Ich habe mir den Server im Detail angeschaut und erst einmal keine Fehler feststellen können. Alles war noch da und auch alle Dateien waren sichtbar. Als ich jedoch versuchte, Dateien von diesem Datenträger zu kopieren, zeigte der Dateiexplorer den Fehler an: "Datei nicht gefunden". Dementsprechend hatte das Upgrade wohl die Daten zerstört. Nach ein wenig Recherche ist die Ursache hierfür wohl, dass jedes Betriebssystem seine eigene ReFS-Version verwendet und diese untereinander inkompatibel sind. Dies führt dann in so einem Fall zur Beschädigung der Dateien.

Wenn Du Server mit ReFS-Datenträgern verwendest, führe KEIN INPLACE-UPGRADE durch. Installiere stattdessen einen neuen Server oderr verschiebe die Daten auf einen neuen NTFS-Datenträger, falls möglich.

Netzwerkprobleme, Teil 1 - ältere virtuelle Netzwerkkarte

In manchen Kundenumgebungen wird innerhalb der VMware-Umgebung noch die ältere virtuelle Netzwerkkarte Intel E1000 genutzt - auch wenn generell empfohlen wird, VMXNET3 zu nutzen (bessere Leistung, höhere Bandbreite, etc.).

In diesen Umgebungen bin ich auf ein seltsames Phänomen gestoßen, als ich ältere Domänencontroller deinstalliert habe. Als Teil dieses Prozesses muss die virtuelle Maschine neu gestartet werden. Nach dem Neustart war die virtuelle Maschine nicht mehr erreichbar - keine Netzwerkkonnektivität mehr, obwohl nichts in der Netzwerkkonfiguration geändert wurde.

Daraufhin wurden die üblichen Problemlösungsschritte durchgeführt - Netzwerkadapter neu gestartet, NLA-Dienst neu gestartet (bekannter Bug seit Windows Server 2016, siehe auch das nächste Kapitel), aber alles ohne Erfolg. Es half nur, die ältere E1000-Netzwerkkarte durch eine neue VMXNET3-Netzwerkkarte zu ersetzen.

Wichtig: der Netzwerkadapter muss nicht nur in VMware, sondern auch innerhalb von Windows entfernt werden. Hierzu sind die folgenden Befehle in einer Kommandozeile (cmd) durchzuführen:

set devmgr_show_nonpresent_devices=1
devmgmt.msc

Im Gerätemanager sind dann die folgenden Schritte durchzuführen:

• "Ausgeblendete Geräte anzeigen" unter Ansicht aktivieren
• Alten Netzwerkadapter unter "Netzwerkadapter" entfernen
• Neuen Netzwerkadapter gemäß bisheriger Konfiguration einrichten

Der Server war anschließend wieder problemlos erreichbar und der Deinstallationsprozess konnte fortgesetzt werden.

Netzwerkprobleme, Teil 2 - der gute alte NLA-Bug

Der Windows-Dienst "Network Location Awareness" (NLA) wird zur Ermittlung des Netzwerks genutzt, in dem sich der Server befindet. Auf dieser Basis können individuelle Firewall-Regeln auf Basis von Netzwerkprofilen greifen. Auf Domänencontrollern weist dieser Dienst jedoch einen Fehler auf, der mindestens seit Windows Server 2016 bekannt und auch in Windows Server 2025 immer noch nicht behoben ist (wobei mir das Problem dort bislang noch nicht begegnet ist).

Nach einem Neustart erkennt der NLA-Dienst das Netzwerk nicht richtig, so dass der Domänencontroller einen falschen Regelsatz in der Firewall aktiviert und nicht mehr erreichbar ist. Es gibt mehrere Wege, dieses Problem zu beheben:

• Netzwerkadapter deaktivieren und wieder aktivieren (nur, wenn auf den Server mittels virtueller Konsole zugegriffen wird und funktioniert typischerweise nicht immer)
• Neustart des Netzwerkadapters mittels PowerShell (funktioniert auch bei einer Remoteverbindung):

Get-NetworkAdapter | Restart-NetworkAdapter -Confirm:$False

Get-NetworkAdapter | Restart-NetworkAdapter -Confirm:$False

Diese Maßnahmen sind jedoch nur temporär hilfreich, da das Problem beim nächsten Neustart wieder auftreten kann. Die folgenden Ansätze können dazu beitragen, das Problem zu "lösen" (eventuell auch in Kombination):

• Starttyp des NLA-Dienstes auf "Verzögert" einstellen
• Zusätzliche Startabhängigkeiten für den NLA-Dienst einstellen (z.B. DNS)
• Geplante Aufgabe mit einem lokal abgelegten Skript erstellen, welches den Netzwerkadapter nach jedem Neustart zurücksetzt/neu startet

Netzwerkprobleme, Teil 3 - DFS-Replikation für Active Directory

Bei der Bereitstellung neuer Domänencontroller bin ich auf ein weiteres seltsames Phänomen in Verbindung mit der DFS-Replikation für Active Directory gestoßen. Dieses hat dazu geführt, dass alte Domänencontroller nicht deinstalliert werden konnten, da sie keinen Replikationspartner ermitteln konnten.

Bei der Analyse des Problems bin ich auf das folgende Ereignis in der Ereignisanzeige gestoßen (Ereignis 4012, DFSR):

The DFS Replication service stopped replication on the folder with the following local path: C:\Windows\SYSVOL\domain. This server has been disconnected from other partners for ... days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected.

Es gibt einen langen und einen kurzen Weg, um das Problem zu lösen:

• Lang: eine autoritative DFS-Synchronisierung durchführen
• Kurz: den im Ereignis erwähnten Wert in der Registrierung hinzufügen, einen höheren Wert als angegeben eintragen und den Dienst DFS-Replikation neu starten

In der Ereignisanzeige sollten nach Durchführung einer der oben beschriebenen Maßnahmen weitere Einträge erzeugt werden, die zeigen, dass die Replikation wieder initiiert wird. Abhängig von der Konfiguration der AD-Sites und Replikationsintervalle sollte die Deinstallation dann wieder funktionieren.

Dies kann jedoch auch auf ein größeres Problem in der Umgebung hindeuten. Bevor diese Maßnahmen durchgeführt werden, sollte daher sichergestellt sein, dass die Domänencontroller an sich sauber funktionieren und die Replikation nur auf dem/den zu deinstallierenden Domänencontrollern betroffen ist.

NPS und Azure MFA-Erweiterung

Einige Kunden verwenden die Serverrolle Netzwerkrichtlinienserver (Network Policy Server, NPS), um Azure MFA für VPN- und WLAN-Verbindungen einsetzen zu können. Hierfür wird die Azure MFA NPS-Erweiterung benötigt, die kostenlos aus dem Microsoft Download Center heruntergeladen werden kann. Diese wird über ein PowerShell-Skript eingerichtet und verbindet den NPS mit Entra ID.

Das Upgrade für solch einen Server läuft an sich problemlos durch. Allerdings kommuniziert der Server nach dem Upgrade nicht mehr mit Entra ID. Deshalb muss die Erweiterung mithilfe des Skripts erneut eingerichtet werden.

Hinweis 1: wenn der Kunde noch eine ältere Version der Erweiterung verwendet, so wird eventuell noch das mittlerweile abgekündigte PowerShell-Modul MSOnline anstatt von Microsoft Graph verwendet. In diesem Fall sollte zunächst die Erweiterung selbst VOR dem Upgrade des Servers aktualisiert werden, da die Installation des Graph-Moduls einige Zeit in Anspruch nimmt und währenddessen keine Authentifizierung über den NSP möglich ist.

Hinweis 2: wenn der NPS-Server nicht in englischer Sprache installiert ist, so muss das Konfigurationsskript manuell angepasst werden. Aus unbekannten Gründen wird im Skript das Dienstprinzipal "NETWORK SERVICE" hart vorgegeben und nicht dynamisch ermittelt. Die deutsche Entsprechung lautet "NETZWERKDIENST". Andernfalls kann das Skript einen wichtigen Schritt nicht ausführen und der NPS ist nicht funktionstüchtig.

(Das Skript erteilt dem Dienstprinzipal einen Lesezugriff auf den privaten Schlüssel des Zertifikats, welches für die Authentifizierung an Entra ID genutzt wird. Ohne dieses Recht funktioniert die Authentifizierung nicht. Diess kann jedoch auch manuell über die Zertifikatskonsole eingerichtet werden, ohne das Skript anzupassen.)

Nicht-englischsprachige ADFS-Server

Einige Kunden verwenden die Active Directory-Verbunddienste (ADFS), um externe Systeme und Benutzer an ihr Active Directory anzubinden. In Verbindung mit Entra ID wird der Einsatz von ADFS nicht mehr empfohlen. Es mag jedoch noch andere Einsatzzenarien für ADFS geben.

Die beobachteten Probleme sind spezifisch für Kunden, die ihre Server nicht wie empfohlen in englischer Sprache installieren. Zumindest für ADFS ist dringend angeraten, zumindest das englische Sprachpaket zu installieren und das System auf Englisch umzustellen. Andernfalls können im täglichen Betrieb merkwürdige Phänomene auftreten (der Dienst startet auf einmal nicht mehr, es gibt keine aussagekräftige Fehlermeldung, die Verbindung zur Datenbank schlägt unvermittelt fehl, usw.).

Beim Upgrade eines solchen Servers wird die Systemsprache wieder auf die Installationssprache zurückgesetzt (z.B. Deutsch). Dementsprechend muss das Sprachpaket erneut installiert werden. Dies klappt mittlerweile nativ in den Sprachoptionen, allerdings mag die Installation an einem fehlenden Internetzugriff scheitern. Daher wird empfohlen, die offizielle ISO-Datei mit allen Sprachpaketen lokal vorzuhalten.

Des Weiteren sollte geprüft werden, ob das für ADFS verwendete Dienstkonto innerhalb der SQL Server-Instanz auf die ursprüngliche Sprache zurückgesetzt wurde. Dies sollte eigentlich nicht passieren, bei einem Kunden wurde jedoch auch das Dienstkonto wieder auf Deutsch eingestellt, was dazu führte, dass der ADFS-Dienst nicht mehr gestartet werden konnte.

Außerdem wichtig; nach dem Upgrade der ADFS-Server auch die ADFS-Farm entsprechend aktualisieren:

Invoke-AdfsFarmBehaviorLevelRaise -Confirm:$False

Invoke-AdfsFarmBehaviorLevelRaise -Confirm:$False

Wird fortgesetzt...

Hat Dir der Beitrag gefallen? Lass es andere wissen!

• Share on LinkedIn
• Share on Bluesky
• Share on Facebook
• Email this Page
• Share on Reddit