Consistent Thin Client Disconnection from WVD Pool

[Sbarnet]

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

[#2]

We had also problems with unexpected disconnects, windows 10 20H2 version. After fully patch this vm;s the problem seems to be gone. The 21H1 version was working without problems.

[#3]

This is interesting, are you also located in the UK south data Center ?

[#4]

No, we are in West Europe datacenter

[#5]

Please share you Microsoft support case number so I can link to the case we have

[#6]

Are you still facing this issue ?

[#7]

We don't have a MS case at this moment. We are still in investigate "mode". This customer is still in project status. We hope we found the issue for this customer. Probably we found a issue with the forced MFA request which conflicts with the CA MFA reuqests.

[#8]

We have some session hosts on 21H1 but still facing the issue.

[#9]

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 

[#10]

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.

[#11]

@EddyGaiao 

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.

[#12]

@Kathryn_Jakubek , is there any news on this potential fix already?

[#13]

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/windowsdeskto...

[#14]

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.

[#15]

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

[#16]

Yes we are planning a change for this:thumbs_up:

[#17]

Since two days we also experience connection losses. We have a couple of hundred people working on thin clients (Igels). We are using AVD for almost a month now and since two days a couple of people have random lose of connections. They see the message : "An unknown error has occured" and then the login screen again. After they login again they can continue in their session. In the portal the sessions shows disconnected at the time between. We haven't changed anything since two days so this is a complete riddle for us.

[#18]

Hello ATWVD,
Can you provide me with your case # for this issue? I want to have someone look at it. Thank you.

[#19]

Have you read my post earlier regarding the method of how I found a fix for these weird and unexplainable dropouts? Maybe you want to try that. It's completly stopped the dropouts for us.

[#20]

I sent you a message with the case numbers

[#21]

Hi,
Thanks but your solution doesn't work for us. We use full desktops in combination with Linux thin clients.