Consistent Disconnection from WVD Pool

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.

@EddyG

As discussed in the article you shared, ClientDisconnect means that the connection between the client and the gateway has been lost. Issues could be between the Session Host and the service.
The users are getting disconnected because they stop receiving packages(heartbeats).

Question is does the issue only repro on the thin client? if so what thin client are you using and what is the OS?

As the Issue is intermittent, and not all users face the issue at the same time. We need to collect network captures from both client machine and the AVD host machine when the issue is present.

Currently this issues needs deeper investigation, and the logs with and without Zscalar need be analyzed to understand the root cause. Support team will be able to check and help on this. I would recommend you to open a azure support case.