I wasn’t going to write a blog today, but after troubleshooting a weird issue, I still needed to.
This blog will be about the Remote Desktop Client and Windows 11 Insider Preview. Normally I am not blogging about Remote desktops… but this time I needed to.
I will divide this blog into multiple parts
1. The Issue
When migrating to full cloud, sometimes you are still stuck with some old legacy apps. Like I told you in this blog, sometimes publishing an old legacy app as a Remote App for the time being could be a great option.
But today we noticed something weird.
A customer called us about a problem he experienced, so we wanted to be sure our test user was also experiencing the same issue. So we wanted to log in with our test user to check it out four ourselves.
But after logging in with our credentials, we ended up with this nice remote desktop screen. It hanged on the famous “Configuring Remote Session”
That’s weird because that wasn’t what the customer called us for. That’s weird. So the first place we looked was the Remote Desktop Gateway services, and they were running without any issues, people were still logged on and could still do their job.
The first thing I wanted to know was if it was an issue at the customer server-side or our own devices. So we did the same tests on some other environments. Almost all of them just worked!…
Luckily we also had a second Remote Desktop Gateway at the customer to test with. When googling on the “configuring remote session” you will end up in some advice creating the EnforceChannelbinding
Value: 0 (Decimal)
Or creating the registry value RDGClientTransport on the client (Use RDG-RPC instead of RDG-HTTP)
But none of them worked of course. So let’s move further. We also tested the connection from a separate Windows 11 device, that wasn’t enrolled in Azure Ad/Intune.
You can guess what happened. It worked instantly! No problems whatsoever! So it had to be a setting from Intune, maybe a security baseline went rogue? Luckily there were still 20 new Autopilot enrolled notebooks that needed to be shipped to the client.
So we also tested to log in from one of those devices. As we are almost using the exact same security baselines as our customers, we could rule out the Security Baseline. Again, you can guess what happened! It worked wonderfully!
Okay? So we needed to troubleshoot our own devices, this time … isn’t that a nice Christmas present?
So the first thing we checked was the mstsc.exe version itself because I can still remember some issues with a KB update a long time ago that really messed up the Remote desktop client.
Mmm.. this version was recently updated? I guess that could be the problem here? But still, the question remains why?
So, when you need to troubleshoot the Remote Desktop client, the Terminalservices-ClientActivexCore event log would be the first place to start.
So we opened the event log on our devices and on all devices we noticed these nice 1033 errors
Onderdeelnaam:CClientProxyTransport, :: ‘Gateway Error’ in CClientProxyTransport::SetErrorStatus at 2853 err=[0x800759ec], Foutcode:0x800759EC
Onderdeelnaam:CAAUDPClientChannel, :: ‘SecureTunnel’ in CAAUDPClientChannel::HandleChannelConnect at 958 err=[0x8007274c], Foutcode:0x8007274C
Having errors in that event log doesn’t mean anything good!
3. Solving it
I guess you deserve some background information first. Some time ago we decided to put our devices into the Insider Preview ring of Windows Update for Business, so we would know what would come. Why? So we can be prepared!
So I guess with this Windows 11 Build (22523.1000) we also got the new Remote Desktop Client 10.0.22523.1000 But why was it breaking? After ruling out everything else possible, it suddenly hit me. CAAUDPClientChannel, mmm sounds like UDP…. 🙂
It looks like a UDP issue to me indeed, luckily I can still remember some stuff from the “good old days”. You can define UDP transport settings in the Remote Desktop Gateway configuration like shown below
This setting was already enabled for a long time. We decided to turn it off to check out if there was any difference.
Yes, there was… When we turned it off the Remote desktop client could log in immediately. We decided to look further into why suddenly UDP wasn’t working.
After checking out the Firewall and NAT table, we noticed something weird. The NAT rule to forward the UDP traffic was disabled?
When turning it on and enabling the UDP on the rd gateway again it also worked!
So to give a summary: It looks like the latest Remote Desktop Client version 10.0.22523.1000 has some issues determining if the UDP port is enabled and AVAILABLE, maybe it doesn’t check it, and just assumes it works?. It also looks like the old version does checks if UDP is available, if not it doesn’t use it.
Troubleshooting our own devices and an old remote desktop gateway, was a nice Christmas present indeed!