This blog will be about the Remote Desktop Client and Windows 11 Insider Previews. Normally, I do not blog about Remote Desktop, but the weird 0xc000035b error that was haunting us changed my mind.
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.
https://call4cloud.nl/2021/03/deliver-us-from-hybrid
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 logged in with our test user to check it out ourselves.
But after logging in with our credentials, we ended up with this nice remote desktop screen. It hung 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.
2. Troubleshooting
The first thing I wanted to know was if it was an issue on 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 for the customer to test with. When googling “configuring remote session” you will end up with some advice on creating the EnforceChannelbinding
HKLM\Software\Microsoft\Windows NT\CurrentVersion\TerminalServerGateway\Config\Core
Type: REG_DWORD
Name: 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 logging in from one of those devices. As we are using almost the 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?
The first thing we checked was the mstsc.exe version itself because I can still remember some issues with a KB update from 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 shown below
This setting had been enabled for a long time. We decided to turn it off to see 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 UDP suddenly wasn’t working.
After checking out the Firewall and NAT table, we noticed something weird. Was the NAT rule to forward the UDP traffic 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 checks if UDP is available, if not it doesn’t use it
4. 0xc000035b and 0x3000008 Errors
I guess Remote Desktop issues and Windows Insider Previews are still occurring. This time we will get a nice 0x3000008 error thrown at us with the latest Windows 11 Insider Preview build: 25295.1000
When looking at the Remote Desktop Gateway, the only thing that we will notice is an event 4625 in the security log mentioning the status: 0xc000035b error
Again, we are looking at the EnforceChannelBinding / LmCompatibility error
0xC000035B when you use LmCompatibility – Windows Server | Microsoft Learn
It’s funny that this error started to occur with the same customer so that enforcechannelbinding was still configured. After some more tests, I decided to just create the RDGClientTransport key with the value 1
Yes!! After closing the mstsc.exe and reopening mstsc.exe again, I could log in without any issue!
Conclusion
Troubleshooting our own devices and an old remote desktop gateway was a nice Christmas present indeed!
Thank you! Year later from your post, but just had this with 1 home user computer that updated. The rest of the business computers haven’t updated yet. Disabling in Gateway fixed.
We’re facing a similar issue and determined that it does in fact have to do with security baselines. The MDM security baselines don’t cause the issue, but the GPO version does. I still haven’t figured out what the difference is between the two that results in the GPO version being problematic.
Thanks, you save my sunday.. In my case the error “There was a problem connecting to the remote resource. Ask your network administrator for help.” start to occur after a certificate change in RD Farm. UDP transport was enabled but not allowed in firewall rules. Also there was no block in firewall. We have a segment for every RD Farm server (one segment for RD Gateway, one for Session Broker/Licensing and another for Session Host). We have firewall rules allowing only required ports.
After disabling UDP transport, RD Gateway start to work.
Again Thank you!