This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
All of our Remote Desktop Users using Windows 11 are having problems connecting to Remote Desktop after installing this update. It just hangs at connecting.
We have found that there is a bug in the Remote Desktop client so that it is only trying the UDP connection and not trying TCP connection. We only allow the port 443 connection through on our firewall.
The only workaround we have found is to make the following change on the Windows 11 computer.
Have to set this value to 1 in the registry for Windows 11 client to work outside the network
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client
KEY VALUE - fClientDisableUDP SET TO 1
Otherwise the Remote client just keeps trying to connect via UDP.
This issue did not start until the Windows 11 update was installed over the last couple days.
Jeff
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
Thanks VERY much Jeff, as the Reg kill of the UDP absolutely fixed my issues. Like you, I had multiple W7, W10 machines with no issues RDP'ing. After the W11 machines updated, failed, hung, and had to task manager out. Thank you for sharing this, and I will be RE-sharing this post, to help others as well.
Thank you.
same here - except 204 error
My error turned into a 204 error eventually.
Not sure if you've fixed it yet, but I was able to find a fix that worked for my machine:
I also did the fClientDisableUDP trick, but this didn't seem to work until after I did the above steps.
It seemed like the default 3389 wasn't working for me, and neither was 3390, but someone somewhere else suggested port 3391 was working. I gave it a shot and it worked.
The 2282 issue with the update is this, fixed or do I have to go around the work around, thank you.
Hello -
I also hope to stay in the loop about when there's an update that resolves this issue. Thanks to everyone who's contributed here.
Hi Jeff, hi Microsoft,
Switching off UDP with one of the solutions mentioned at least means that a connection can be established again. We run an enterprise solution for our customers and are severely impacted by the issue. Excessive use of virtual channels is possible without UDP, but this means that drawing operations, for example when copying files through the channel, freeze. So far so good... The only solution from my point of view is to roll back the files (mstsc.exe and mstscax.dll) to the status before the 22H2 update. It is important that the permissions on the files are not modified, so that Microsoft can then cleanly update them again with the next update. Our solution is: - Stop all instances of mstsc.exe - Elevate to local administrator - Start Trusted Installer Service - Start a copy application (exchange files) in the context of the Trusted Installer (similar to here: https://github.com/rara64/GetTrustedInstaller/blob/master/BerlinDefence.cs) At least the functionalities used in our scenario are restored and customers can use our services without restrictions. I am not aware of any side effects. Unfortunately, the application used cannot share, as it was specially developed for our customers. However, if anyone needs help, he/she is welcome to get in touch on the subject.
