Auch mit Windows Server 2025 hat Microsoft das Problem nicht in den Griff bekommen, dass sich Windows Server mit RDS-Rollen nicht zuverlässig auf eine neue Version aktualisieren lassen.
Windows Server 2019/2016 und 2022 erzeugen bei einem InPlace-Upgrade gerne nach dem „beinahe“ fertigen Durchlauf des Setups (ohne Warnungen) die altbekannte „Ihr Computer wird in den alten Stand zurückgesetzt“ Setup-Meldung. Nach dem Start der alten Version wird man dann von dieser Fehlermeldung begrüßt:
C1900101 – 0x30018 Die Installation war nicht erfolgreich. In der Phase FIRST_BOOT ist wahrend des Vorgangs SYSPREP_SPECIALIZE ein Fehler aufgetreten.
Lösung
Der geheime Insider-Trick, die RDS-Rollen vorübergehend zu entfernen, funktioniert seit nun fast 10 Jahren immer noch. Es geht aber auch viel schneller.
Man lege auf dem betroffene Server einfach vor dem Setup-Start diesen Registry-Eintrag (REG_SZ) an:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MASCHINE\SOFTWARE\Microsoft\Terminal Server Web Access\IsInstalled]
"Version"="6.0"
Danach läuft das Setup trotz installierter RDS-Rollen fehlerfrei durch. Wer Änderungen am RDWEB vorgenommen hat, muss dieses allerdings zurückspielen – die neue Windows-Version ersetzt den Inhalt des RD-Web-Access Verzeichnisses.
Wir hatten einen spannenden AADConnect (Entra ID Connect) Fehler zu suchen. Manche Microsoft 365 Gruppen wurden nicht (mehr) korrekt in das lokale AD zurückgeschrieben. Der Fehler lautete, natürlich ohne weitere Details, „Zugriff verweigert“ (permission-issue). Der Hinweis der „Connected data source error code: 5“ ist zwar ein Indiz, aber keine Lösung.
Lösung
Was die Ursache dazu war, ist nicht bekannt. Aber es sind die AD-Berechtigungen für das Synchronisationskonto auf den betroffenen Objekten. In diesem Fall „Generisches Lesen/Schreiben“ von allen Attributen einer Objekttypgruppe (und von deren Unterobjekten).
Auf dem AADConnect-Server in einer PowerShell (als Administrator) ist der Fehler schnell behoben:
Seit Windows Server 2025 häufen sich „hängende“ RDS (RDP-) in erneuten Anmeldungen. Die Anmeldung hängt im „Willkommen“ Bildschirm fest. Das gilt ganz besonders für getrennte Sitzungen. Wenn der Administrator eine solche Session zurücksetzt, ist die Neuanmeldung aber sofort wieder möglich.
Meldet sich ein Benutzer an und trennt seine Sitzung, ist diese Sitzung (scheinbar) nicht mehr nutzbar. Die Anmeldung funktioniert fehlerfrei, aber das RDP-Fenster hängt im „Willkommen“ Bildschirm fest. Der Throbber rotiert nicht, die Sitzung ist „tot“. Das gab es früher schon, aber seit Windows Server 2025 tritt das Phänomen deutlich gehäufter auf.
Lösung
Es haben sich offensichtlich (schon wieder) neue Fehler in der „Verbindungszeiterkennung“ oder der „kontinuierlichen Netzwerkerkennung“ eingeschlichen. Schaltet man diese ab, verschwindet das Problem sofort und Sitzungen sind auch nach einer Trennung wieder zugänglich.
Registry Quick-Fix
Der DWORD-Wert SelectNetworkDetect sollte auf 2 gesetzt werden („Turn off Continuous Network Detect“)
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]
"SelectNetworkDetect"=dword:00000002
Gruppen- oder lokale Richtlinie
Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Remotedesktopdienste > Remotedesktopsitzungs-Host > Verbindungen > „Netzwerkerkennung auf dem Server auswählen“ aktivieren und auf „Fortlaufende Netzwerkerkennung deaktivieren“ stellen.
Akute Abhilfe am Client
Wenn das Problem gerade akut auftritt und man sich aber dringend verbinden möchte, hilft es auch in den Client-Einstellungen (mstsc.exe) die Verbindungsgeschwindigkeit auf dem Reiter Leistung fest einzustellen (z.B. auf LAN oder WAN):
Viele Admins öffnen praktisch beliebige Dateien direkt mit VS Code. Dank der zahlreichen flexiblen Extensions (und der hohen Geschwindigkeit) ist VS Code mittlerweile auch das Tool für verschiedenste Dateitypen. VS Code scheint sich zu dem neuen Notepad++ zu entwickeln.
Manchmal fehlt aber der Eintrag „Öffnen mit VS Code“ im Explorer-Kontextmenü. Das kann passieren, weil man den Haken bei der Installation vergessen hat, oder weil es einen neuen Benutzer auf der Maschine gibt.
Lösung
Am schnellsten kann man das via Registry hinzufügen. Diese *.reg kann man an die eigenen Wünsche anpassen.
Den Pfad zu code.exe muss entsprechend angepasst werden.
Windows Registry Editor Version 5.00
; Icon fuer den Eintrag (wenn gewollt)
[HKEY_CLASSES_ROOT\*\shell\Open with VS Code]
@="VSCode"
"Icon"="C:\\Users\\EXAMPLE\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe,0"
; "VSCode: als Project öffnen" bei einam Klick auf Ordner hinzufügen
[HKEY_CLASSES_ROOT\*\shell\Open with VS Code\command]
@="\"C:\\Users\\EXAMPLE\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\" \"%1\""
[HKEY_CLASSES_ROOT\Directory\shell\vscode]
@="VSCode: als Project öffnen"
"Icon"="\"C:\\Users\\EXAMPLE\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\",0"
; "VSCode: als Project öffnen" bei einam Klick *in* einem Ordner hinzufügen
[HKEY_CLASSES_ROOT\Directory\Background\shell\vscode]
@="VSCode: als Project öffnen"
"Icon"="\"C:\\Users\\EXAMPLE\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\",0"
[HKEY_CLASSES_ROOT\Directory\Background\shell\vscode\command]
@="\"C:\\Users\\EXAMPLE\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\" \"%V\""
; "VSCode" bei einam Klick auf Dateien hinzufügen
[HKEY_CLASSES_ROOT\Directory\shell\vscode\command]
@="\"C:\\Users\\EXAMPLE\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\" \"%1\""