Win 2019 RDP Session Host Start Menu Stops Working

Just a brief post today to discuss an issue we recently experienced with a client on one of their Win 2019 RDP Session host servers.

Before we discuss the problem, I'd like to outline the environment and experience the client was having prior to this issue becoming apparent. The server was working fine the previous day and all users were accessing the system without issue. They weren't experiencing performance issues either and connectivity was optimal. All user profiles are stored in UPDs (User Profile Disks).

One of the users called the help desk and said that Teams and Outlook weren't opening in their RDP session. We joined their session to take look and thought we'd just log the users out of their RDP session and asked them to log back on. They logged back on, but Teams and Outlook still refused to play nice. While on the users session I tried to access the Start Menu and use the Search field in the Start Bar and neither worked.

Upon checking with other users on the same server, they were experiencing the same issue, no Start Menu or Search field functionality.

I checked the server System Event Log and discovered a lot of DistributedDCOM Event ID 10001 errors. Looking into this a little further it seems that the server couldn't start the Cortana SearchUI.exe. Here is an excerpt from the event log:

Unable to start a DCOM Server: Microsoft.Windows.Cortana_1.11.6.17763_neutral_neutral_cw5n1h2txyewy!CortanaUI as Unavailable/Unavailable. The error:
"0"
Happened while starting this command:
"C:\Windows\SystemApps\Microsoft.Windows.Cortana_cw5n1h2txyewy\SearchUI.exe" -ServerName:CortanaUI.AppXa50dqqa5gqv4a428c9y1jjw7m3btvepj.mca

Here is a screenshot of the event:

So how do you fix it?

We tried the usual remediation tricks like forcefully logging off the users, checking that the UPDs weren't locked by another session host server and even rebooting the server to see if we could get Cortana operational again.

The issue is apparently tied to oversized registry keys linked to the server Firewall rules that are created as each user logs on daily. Windows doesn't trim these and eventually the registry keys become bloated. I found this post... on Reddit that helped solve the issue for us. Many thanks to the user liquidkristal for providing the remediation process.

Before running the batch file outlined below, I'd encourage you to create a GPO for your RDP server(s) to re-apply the necessary Firewall settings to allow connections back onto the server(s) after the registry keys be low are deleted.

You can either check the Firewall settings in your current setup and export and save them or alternatively I've shared a link with the necessary RDP Firewall settings for RDP Servers that you can download here... and apply them to your RDP GPO on your domain controller or via the local GPOs of your session host server(s).

Simply create a batch file and save the following registry commands into it:

reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules /va /f
reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System /va /f
reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\AppIso\FirewallRules /va /f

gpupdate /force

Now run the batch file as an Administrator and allow it to complete. It will take quite a few minutes to carry out the task so please be patient. Once complete, you don't need to reboot the server, just ask your users to log off their sessions and their Start Menu and Search functionality will immediately become operational again.

As outlined in the Reddit post by liquidkrystal, they had setup a Scheduled Task that runs the batch file once a month to automatically clean up these registry keys. I haven't done that as yet as I want to monitor the affects over the coming months. I always think it's better to be conservative when it come to these things than applying set and forget fixes.

****Update:**** This has been successfully working now for 4 or so months so can be safely applied to your RDP servers

If you've found this useful, you may want to sign up to our newsletter where you'll receive notices on when we post new articles and helpful "how tos". Just fill out your details below and we'll do the rest...

No Comments Yet.

Leave a comment


Sign up to our newsletter where you’ll receive notices on when we post new articles and helpful “how tos” to make your IT life easier.