Forum Discussion
Consistent Thin Client Disconnection from WVD Pool
Hello we have been experiencing some random but consistent disconnects from our WVD Pool. We have roughly 10 users and have been getting different event viewer logs for when they disconnect. We have Thin Clients on Windows 10 version 1607. When the users disconnect it will happen multiple times per day, however some days they do not disconnect. Attached are the event viewer logs
148 Replies
- Update from our case. We had only ONE set of random session host disconnects every morning at 08:06 or 08:33 where the users could reconnect straight away after.
In the end this was fixed after a technician did some cleanup of private dns zones in the vnet. The zones where not related to AVD traffic at all.
Our theory is that updating/saving config in the vnet refreshed the config and fixed some backend error.
We did not see any disconnects after this was done. We are still seeing disconnects at every morning at 08:06 CET time for Azure Virtual Desktop.
- 1,5 years after first reported.
- Multiple RDAgent + RD Client updates, none has fixed it
- Troubleshooted all Intune clients and AVD Session hosts
- Troubleshooted firewall and URL check, no specific denies
- Tried new images, clean marketplace images
- Tried clean OUs with GPO inheritance disabled
- RDP Shortpath enabled
- Accelerated Networking enabled
- Works fine throughout the day except these static disconnects in morning, so shouldn't be firewall.
- The whole nature of the disconnects is very "scheduled task"-ish. We just cannot find any tasks at these times. Either that or network packets are dropped at this time for some reason. I really wish there was more documentation explaining the EventViewer logs for Azure Virtual Desktop session hosts.
Around 4 MS Support cases.
Currently we are awaiting MS support saying network is analyzing traces etc.
This is the log we see in event viewer when it happens:
https://i.imgur.com/vnz98G5.png
Our AVD is behind a Azure Firewall
https://learn.microsoft.com/en-us/azure/firewall/protect-azure-virtual-desktop?tabs=azureBest Regards
AT
- Kathryn_Jakubek
Microsoft
Hi - I'm sorry you are seeing these issues. Would you be able to share a subscription id or ActivityId?- Sent you a PM
- Hi,
Where are you located? We also see disconnects from time to time. And sometimes for a large amount of users within the same minute. It is not consistently at the same time in the morning as you report, but more random during the day.
We see that some of our session hosts report event id 3703: "RDGateway Url is not accessible." at the same time of a disconnect.
We also have an open support case with MS. We have gone through the same list as you with troubleshooting except for RDP Shortpath. This has been suggested as a possible workaround as it doesn't rely on gateways to be accessible at all times. It is interestingly that you still see this error with shortpath enabled. Have you verified that RDP shortpath is actually effective for those sessions that disconnect?- We are located in Norway. Our users are spread all across home-office and office locations in Norway. No location specific disconnects.
Session hosts and AVD service is in West Europe Azure region.
We have verified that UDP is being used, there is some fallback to TCP sometimes. I can verify this some more. Would be useful to know if it happens ONLY with TCP and not UDP connected sessions.
We have been having consistent disconnects from AVD for over one year. Where MS support is not able to figure out the problem. We have had support cases (multiple) for a year. They have thrown their support case from AVD team to Network team to AVD team to Network team etc. and never seem to want to dig into the technical side of things on their MS-hosted AVD broker service or their backend network.
Every day at 08:05 or 12:07 (sometimes 08:27) a bulk of users disconnect. Around 15-20 users. Totally random set of users. Not location specific, notend client specific, newest updated Remote Desktop Client so that "update issue" should not apply. Very hard to replicate with test users and testing.
There almost seems to be something going on with the RD Agent at that time aswell, maybe a user session refresh or a heartbeat check or something. We have queried MS support if this could be a bug with refreshing of sessions where duplicate ID's create some sort of overwriting of the same session.Our experience with MS support on AVD service has been really bad on this issue. We are losing hope and looking at alternatives.
- Kathryn_JakubekHello ATWVD,
Can you provide me with your case # for this issue? I want to have someone look at it. Thank you.- I sent you a message with the case numbers
- Hi ATWVD,
Have you tried RDP Shortpath (https://docs.microsoft.com/en-us/azure/virtual-desktop/shortpath-public) if applicable?
Maybe this will help you figure out the issue or cause of the problem.
Greetings, Marco- Yes we are planning a change for this👍
Hi,
Recently we discovered another reason for suddenly disconnecting sessions.
We push the AVD client to fat clients via Intune.
Somehow, the AVD client tries to update itself, but fails to do so because a lack of permissions.
However, before it tries to update itself, it automatically disconnects active sessions.
You can see this happening in the event log of the client. We are now updating the client via a Intune deployed Powershell script so that the AVD client is always up to date, and these reconnects are not happening anymore.
Also, a few days ago MS released a new version of the AVD which seems to fix this bug:
https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/windowsdesktop-whatsnew
- We have finally managed to figure this out and we have managed to completely stop all dropouts across our clients that use AVD. I’m not sure if this applies to everyone and all situations, so this is just our experience.
Our solution was VERY simple, and I still don’t understand why this “fixed” the dropouts but it has. We are only running published applications, no full desktops, so we haven’t tested this as far as full desktops go.
When you first configure Remote Desktop Client and Subscribe a User to a Workspace in the Remote Desktop Client, the published applications that appear on the Remote Desktop Client also get “published” to the user’s Windows Start Menu. So, the application icon appears in the user’s Start Menu. The education process I do with users, is I Pin the icon to the user’s Start Menu and tell them that is how they should start the application. It makes it easy and clean because it appears like it would if it was a locally installed application. Something very familiar to the user.
What we then tried is instead of opening the app using that published icon on the Start Menu, we opened Remote Desktop Client and then ran the published app from in there. If the Remote Desktop Client is kept open while using the app, the dropouts stop completely. This seems very simplistic, and I have no idea why it’s working. If one shouldn’t run the published app from the icon that is pushed onto the Start Menu when first Subscribing to a Workspace, then why does it get pushed to the Start Menu? If you need to keep the Remote Desktop Client app open while using your published app then the app icon shouldn’t be made available in the Start Menu so that the user is forced to open the Remote Desktop Client and then fire the App from there.
As I said, this seems over simplified and makes no sense at all, but we have now changed all our clients over to this new method of starting their apps and since then we have gone from multiple dropouts a day for all users to NO dropouts at all. This is regardless of the connection method, WiFi, Office LAN, Home LAN or 4G(LTE). Their connections remain solid with zero dropouts.
I would still love to understand why the Remote Desktop Client needs to remain open. Is the Remote Desktop Client doing some sort of “Keep Alive” function in the background?
Anyhow, after many months of frustration, this has been the resolution for us so far. In order to make sure that this was in fact the “fix” we had one or two users continue to open the App using the published icon on the start menu and they continued to experience dropouts while everyone else operated without a single dropout.
I hope someone can shed some light on this “fix” (Microsoft?) and I hope that this might help others experiencing the same issue.- Kathryn_Jakubek
Thank you for sharing this detail. We have a theory on the issue you are hitting and we will reach out when we have a build you can try out with a potential fix.
Kathryn_Jakubek , is there any news on this potential fix already?
Has anyone found a reliable solution to this issue?
We're in the UK South datacentre and are getting random disconnects from users in various countries- Hi,
We are still facing massive random disconnects our WVD is in the UK South region. Is anyone else still having this issue ?- Same here. UK South and getting disconnections constantly. I have a ticket open with Microsoft (logged on 14th October) but still no resolution. How can so many people be having issues with this and MS not have a fix!!? Azure is supposed to be the future, new and shiny, better technology, etc. But this sort of issue is making me wish we'd stuck to our on-prem RDS servers!
- Please share you Microsoft support case number so I can link to the case we have
- This is currently happening for us. Was there ever a resolution to this?
- Are you still facing this issue ?
We've had this issue the week after we launched our WVD environment. The clients (end-users) pc's/thin clients, etc. momentarily stop sending heart beats to the RG Gateway.
We've done A LOT of network tracing and discovered that's what was happening.
The fix:
GPO to change registry values on your host pool VM's. I've attached it as a PDF.
Basically you need to add registry keys to increase heart beat intervals so that the RG gateway continues to stay connected even though the client may have dropped some heart beats. That's when the RG gateway disconnects. Hope this helps!
troyjones thank you for sharing! Unfortunately, this did not seem to make any improvement for us. In fact, one of our MacOS users started getting reconnects every minute or so after implementing this. Once the registry keys were deleted, it immediately fixed that issue.
UDP shortpath has been a lifesaver for us in terms of fixing the disconnects primarily. It hasn't completely resolved things but it's significantly more stable now.
Roger1175 We got the exact same issue with Mac users when adding these registry keys, the disconnects for them increased massivley.
- Awesome find! Thank you for sharing!
- You can also find this in our public documentation: https://docs.microsoft.com/en-us/azure/virtual-desktop/troubleshoot-agent#error-users-keep-getting-disconnected-from-session-hosts
Yesterday, 9/3/2020 was pretty bad. We have a small shop client that we setup with WVD Spring Release back in May, and they have had instances like this where they all get disconnected at the same time.
According to Log Analytics, these are the reasons for failures
CodeSymbolic UserCount NL_ERR_TDSKTCONNECTFAILED 24 ConnectionFailedClientDisconnect 24 UnexpectedNetworkDisconnect 17 ConnectionFailedServerDisconnect 6 CM_ERR_MISSED_HEARTBEAT 6 SavedCredentialsNotAllowed 4 NL_ERR_TDTIMEOUT 4 SSL_ERR_FRESH_CRED_REQUIRED_BY_SERVER 4 ConnectionFailedUserHasValidSessionButRdshIsUnhealthy 2 ConnectionFailedRDAgentBrokerConnectionNotFound 1 These disconnects happened pretty much all throughout the day, makes it extremely frustrating and hard for them to do their work, and frustrating for us trying to provide a root cause analysis. Overall WVD is great, as long as it's working properly and the users are not getting disconnected. Hoping that someone can weigh in on some insight as to what might have been happening yesterday. I can provide more details if someone from Microsoft WVD support would like to review the correlation event IDs from the logs gathered from Log Workspace.
