Tags: RDS, Windows Server 2019, Troubleshooting
Ein bereits seit längerem bekanntes Problem bei RD Session Hosts auf Windows Server 2016 und 2019 besteht darin, dass das Startmenü ohne ersichtlichen Grund nicht mehr funktioniert. Die Ursache dafür ist ein unkontrolliertes Anwachsen von Firewall-Richtlinien. Diese muss man aus der Registry entfernen.
Beim Klick mit der linken Maustaste auf das Startmenü reagierte dieses nicht mehr, und auch die Suchfunktion (Lupe neben dem Startmenü) war ohne Funktion. Die naheliegende Maßnahme, das System auf den aktuellen Patch-Stand zu bringen und es neu zu starten, brachte keine Besserung.
Im Eventlog waren zahlreiche DCOM- und AppReadIness-Fehler zu sehen.
Beim Recherchieren im Web stößt man auf diverse Diskussionen in Foren (etwa in Microsofts TechNet-Forum), wo betroffene User eine Erklärung für dieses Phänomen gefunden haben.
Anhäufung von Firewall-Regeln in der Registry
Beim Anmelden eines Benutzers an einen Terminal-Server wird jedes Mal ein neuer Satz an Firewall-Richtlinien in der Registry erstellt, aber danach nicht wieder entfernt. Dies bläht die Datenbank immer weiter auf und beeinträchtigt so die Reaktion des Systems.
Zu finden sind diese Einträge bei Server 2016 unter
HKLM:\System\CurrentControlSet\Services\
SharedAccess\Parameters\FirewallPolicy\
RestrictedServices\Configurable\System
und in der Version 2019 zusätzlich unter
HKLM:\System\CurrentControlSet\Services\
SharedAccess\Parameters\FirewallPolicy\
RestrictedServices\AppIso\FirewallRules
Beim Inspizieren dieses Abschnitts in der Registrierdatenbank mit regedit.exe friert der Registry Editor für einige Minuten ein.
Das Startmenü funktioniert zwar nicht mehr, aber das Win+X-Menü, das man über die rechte Maustaste öffnet, hingegen schon. Darüber kann man PowerShell starten und die Registry damit aufräumen.
Dies manuell zu erledigen, macht keinen Sinn, da sich mehr als 40.000 Datensätze in diesem Verzeichnis befinden können.
Einfacher lässt sich die Registry mit diesem PowerShell-Script bereinigen. Dabei können die Benutzer ohne weiteres auf dem Server weiterarbeiten, und es ist kein Neustart erforderlich. Das Script eignet sich sowohl für Server 2016 als auch für 2019. Einzig der Pfad muss für die jeweilige Version angepasst werden.
Das Löschen kann je nach Zahl der Einträge mehr als einen Tag brauchen. Sollte das Script etwa durch einen nächtlichen Neustart unterbrochen worden sein, kann man es am nächsten Tag einfach erneut starten.
Unter dem oben genannten Link findet sich eine weitere Version des Scripts, die zum Löschen der Richtlinien nicht Remove-NetFirewallRule verwendet, sondern mit Remove-ItemProperty direkt auf die Registry zugreift und so den Prozess deutlich beschleunigt.
Registry-Problem vorbeugen
Um ein Akkumulieren der Firewall-Regeln künftig zu vermeiden, installiert man erst die Updates KB4490481 für Server 2019 bzw. KB4467684 für Server 2016. Danach wechselt man nach
HKLM:\SYSTEM\CurrentControlSet\Services\
SharedAccess\Parameters\FirewallPolicy
und legt dort folgenden Wert an:
New-ItemProperty -Type DWord -Path . `
-Name DeleteUserAppContainersOnLogoff -Value 1
Diese Maßnahme soll dafür sorgen, dass die Firewall-Richtlinien nach dem Ende einer User-Session automatisch entfernt werden.
Dennoch sollte man diesen Teil der Registry im Auge behalten, und eventuell eine automatisierte Lösung dafür erwägen. Ob auch Server 2022 davon betroffen ist, steht aktuell noch nicht fest.
Täglich Know-how für IT-Pros mit unserem Newsletter
Roland Eich ist gelernter Fachinformatiker für Systemintegration und in der IT seit über 14 Jahren zu Hause. Roland deckt aufgrund seiner Erfahrungen ein breites Spektrum der Microsoft-Produktpalette ab.Zudem besitzt er verschiedene Zertifizierungen (MCITP, MCSA und MCSE, ITIL, PRINCE2).
// Kontakt: E-Mail //
Verwandte Beiträge
- Diagnosedaten eines Azure Stack HCI-Clusters automatisch erfassen
- Fehler beim Ändern der Zeitzone in Windows Server: Kommandozeile als Alternative
- Fehler: Netzwerkeinstellungen von Windows Server 2019 können nicht editiert werden
- Anzeige von RDP-Sitzungen für hochauflösende Monitore anpassen
- RDS in Windows Server 2019: HTML5-Client, HA für Lizenz-Server, Aus für vGPU
Weitere Links
8 Kommentare
Guten Tag,
muss das für jeden User gemacht werden oder kann ich das einmal durchlaufen lassen und dann ist das für alle bereinigt?
Mit freundlichen Grüßen
Torben Andresen
Hallo Herr Andresen,
vielen Dank für Ihren Post.
Also die Arbeiten pro User durchzuführen, wäre wohl etwas zu heftig, dann könnte man ja gleich einen neuen Terminalserver hochziehen, wenn man das so machen müsste.
Die beschriebenen Arbeiten können Sie pro Terminalserver z.B. mit Ihrem Adminuser 1x durchführen und dann sollte das für alle User auf dem jeweiligen TS funktionieren.
Beste Grüße
Roland Eich
Moin,
das hat geklappt, allerdings nicht sofort. Wir mussten den TS aber eh einmal neu starten und ich habe das dann nochmal laufen lassen. Jetzt ist wieder alles gut.
Das beruhigt mich das ich das als Admin 1x laufen lassen kann und nicht pro Benutzer.
Guten Tag,
eine Frage habe ich noch. Die angegebenen Patches sind ja bereits älter. Sind die Inhalte des Patches inzwischen in andere Patches mit eingefloßen, also z. B in kumulativen Patches oder muss ich dir weiterhin auf jedem betroffenen System installieren?
Bei mir hat der Fix nicht funktioniert. Startmenü lässt sich leider immernoch nicht öffnen. Irgenwelche Tipps?
Der Fix scheint nach anfänglichen Erfolgen nicht mehr zu funktionieren. Ist das Script noch aktuell?
Ich hatte vor einiger Zeit ca. 40 Tausend von offensichtlich unsinnigen Regeln manuell gelöscht (ca. 20 min). Daraufhin liefen einige Abläufe (Starten des Servers, Anmeldung etc) wieder wesentlich schneller.
Die unsinnigen Firewalleinträge sind nicht wieder erschienen, obwohl ich keine Registry-Änderungen vorgenommen hatte. Allerdings habe ich jetzt auch das Problem mit dem Start-, Such- und Einstellungsbutton. Offensichtlich scheint das nichts mit den Firewall-Einträgen zu tun zu haben, sondern ist ein separates Problem beim TS 2016.
Hat da noch jemand etwas in Erfahrung bringen können?
Wir haben unsere Terminalserver neu gemacht, weil wir das Problem nicht lösen konnten. Es war schneller die Server neu zu machen, als das Problem zu beheben.