Cannot connect from RD Client app but can through web client

Brass Contributor

Up until today, 10-17-2022 we have had no issues connecting to our AVD host pools through the Remote Desktop app.  I have a couple pooled host pools with a handful of hosts configured to use FSLogix profiles to Azure Premium Files.  It's been working flawlessly for over 2 years now.  


Starting today, users have been getting authentication errors when connecting to their host through the Remote Desktop app.  The error message is stating their credentials are not correct; though, they are.  I tested this and experienced the same thing.  


Here is the kicker:  this only errors out when on prem or on VPN.  If I connect from home, it connects via the app or browser just fine.  If any user tries to connect from within our office, they get the error message stating their credentials are not correct.  The web client works, while in the office though.  


What in the heck is going on????  It's lunch time and I know what I'll be facing in about an hour when everyone tries to connect back to their host after coming back from lunch break.

18 Replies


We are also facing the same issue in our environment, we are using the Remote Desktop client from the Microsoft store as a workaround.

If you find any solution, please let me know.

@janakiram7  that is wild you could access through the Microsoft Store crossed my mind to test that; however, there is no way I could have gotten that installed on all of our endpoints quickly.  Fortunately, yesterday 10/17 after wasting nearly an entire day on this issue, it started to work around 3PM Central Time.... is it working for you today?

@ITSensei It's still not working for us, it seems to be some issue in the domain controller. Did you make any changes to resolve it?

We have 4 domain controllers....1 physical on prem, 2 virtual on prem and 1 virtual in Azure. All of our cloud compute resources have the Azure DC machine as the primary. That domain controller had several pending updates that needed installed. I installed all the updates, which required a couple reboots. I didn't think that is what fixed our issue, but now you mentioned it, it most likely could have.
I ran the "Required URL Check tool" on a couple different hosts and they all came back with positive results. I hadn't done that while we were experiencing issues though. That resource can be found here:

I am still convinced we have 'something weird' going on in our DNS/DC because while on my AVD resource, or even my Azure VM that is on the same VNet, I cannot get to URL's like the one I just provided errors out.

I'm going to try and manually set the preferred DNS server on my test machine to the on prem DC to see if that fixes any issues.

@Pernille-Eskebo One of the vendor user getting this issue he is able to connect via Web client but when he is trying to access it via RD client getting continuously prompted for credentials again and again.


Install the latest RD client version but it's not working.


Tried to check the logs on Logs Analytics Workspace and find the below error:-


KindSourceErrorMessage sampleActivities
DeploymentRDGatewayConnectionFailedClientDisconnect (-2147467259)The network connection between the Azure Virtual Desktop client and the service was unexpectedly interrupted.5
DeploymentClientConnectionBrokenMissedHeartbeatThresholdExceeded (64)The connection was closed as the client stopped receiving heartbeats from the session host.5
DeploymentRDStackConnectionInitiationSequenceTimeout (60)Connection failed due to a timeout waiting for the connection initiation sequence to complete. This may be because of pending credential prompt on the client.3
DeploymentClientOrchestrationFailedNetworkError (10018)Orchestration failed due to a client network error: cannot reach gateway2


We are able to fix the issue, I suspect it's caused by recent Windows updates on DCs. We have uninstalled all the recent updates. After that, we are not facing the issue anymore.
Do you have any details on the KB's you uninstalled so I can check our DC's?
One thing I've noticed aswell is if you unsubscribe, run ipconfig /flushdns subscribe again you can login successfully. Something has definitely changed.
I definitely had our help desk unsubscribe a user, and then resubscribe but I can't say with certainty if a ipconfig /flushdns was done. I agree, something changed outside of our network. Not saying something inside our network caused the disruption such as Server OS just 'started working' for us and I don't know what fixed it whether it was Microsoft or the updates to our DC.

@ITSensei So it looks like this issue seemed to have surfaced around the 12/10/2022 one day after the following security patch releases.


Windows 11 - KB5018418
Windows 10 - KB5018410



Very good info! Thank you for your contribution...i'm going some post incident investigating and I found that KB 5018410 was indeed installed on October 12, 2022.....wonder why it's working fine for us now and the out of band update (KB5020435) has not been installed on the AVD host. I'd have to do some reporting to see how many of our endpoints have gotten this update. I think I'll do that next.
So, it seems removing the October update from our domain controllers has resolved this issue for us.
AAD joined VMs or Classic/hybrid joined?
My environment is all hybrid Azure AD joined in the new Azure environment. I recently moved them from classic to the new environment.
Do you have Azure AD authentication enabled for the host pool under RDP properties? We found that removing that setting enables the Windows client to work properly again, with 5020435 left on the session hosts. If we remove KB5020435 from the session hosts, the Azure AD authentication works.
I do not have Azure AD authentication enabled for the host pools. Oddly enough mine just started working the day after posting this which made me think Microsoft had issues they didn't talk about publicly. For a solid week after having issues though, I could not get to any sites or several other relevant Microsoft sites. All others were fine. Just plain weird.
Ive seen the following OOB releases which came out yesterday. Will test to see if this resolves the issue from the October patches
Windows Server 2022: KB5021656
Windows Server 2019: KB5021655
Windows Server 2016: KB5021654