Remote Desktop mit Windows Server 2016/2019: Startmenü funktioniert nicht


    Tags: , ,

    Windows StartmenüEin bereits seit längerem be­kanntes Problem bei RD Session Hosts auf Windows Server 2016 und 2019 besteht darin, dass das Start­menü ohne ersicht­lichen Grund nicht mehr funk­tioniert. Die Ur­sache dafür ist ein unkon­trolliertes An­wachsen von Firewall-Richt­linien. 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 nahe­liegende 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.

    Parallel zum dysfunktionalen Startmenü häufen sich die Einträge in das Eventlog.

    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 Registrier­datenbank 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.

    Das Win-X-Menü funktioniert in der Regel noch, so dass man hier PowerShell starten kann.

    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 PowerShell-Script zum Bereinigen der Registry in Aktion. Der Vorgang kann lange dauern.

    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

    Registry-Schlüssel setzen, um künftig die Anhäufung von Firewall-Policies zu vermeiden.

    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

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Roland Eich

    Roland Eich ist gelernter Fach­infor­matiker für System­inte­gration und in der IT seit über 14 Jahren zu Hause. Roland deckt auf­grund seiner Erfah­rungen ein breites Spek­trum der Microsoft-Produkt­palette ab.
    Zudem besitzt er ver­schiedene Zertifi­zierungen (MCITP, MCSA und MCSE, ITIL, PRINCE2).

    // Kontakt: E-Mail //

    Ähnliche Beiträge

    Weitere Links

    4 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?