Single user has multiple sessions to multiple session hosts in AVD in the same host pool

Greetings, I am a coworker of Mr. Sadiq and wanted to expand on some key points that may help someone key in on the root cause.

For this example i will refer to our host and pools as Prod-0 and Prod-1 and subsequently the pooled machines within as Prod-0-1 ~ 30 (for example)

This is not something we have experienced before save for the rare occasion, and when terminating the session it would not come back.

So though not unheard of, it was vary rare, where this is constantly all day happening.

The week of 11/6 on Prod-0 FSLogix was implemented.

This was also the following week after the release of the Remote desktop application 1.2.4763.0 x64 that most of our clients had or have updated too since release.

We use a Virtual desktop for our application to be used within, to which the user only ever sees the application (much like the RD Apps of days gone by)

When disconnected the user, if the pooled server has the available user slots, will pool you back into your most recent session so as to "continue where you left off".

Immediately on the morning of 11/6 Users started to report that they were seeing the Virtual Desktop app simply shut down, no errors or anything else.

They would open the Remote app again and it would launch the WVD session but our program would report that the user was already logged in, which is what it is meant to do if the user was logged in already.

We also saw ourselves, and random reports from users that upon relauch, the app was very degraded, which there are multiple reports of already (what appears to be 8-bit color scheme, missing buttons, icons, loss of function)

This could take 2-4 times of terminating the WVD session before the Azure and WVD system would finally stop and go back to normal performance (colors were back, buttons and functionality returned)

Upon investigation we started seeing multiple remote app sessions for the same WVD user, but on different pooled machines.

One or more disconnected, and one active, or all disconnected.

You may see disconnected sessions on Prod-0-7, and Prod-0-17, then maybe one active on Prod-0-3 (just examples so you understand what we are seeing)

This lasted all week until the morning of 11/13 when it mysteriously stopped, or at some point over that weekend.

But then this issue rolled to a new server, Prod-1 (which had FSLogix implemented that weekend and Prod-0 was the week prior)

Now instead of users on Prod-0 calling, we have spent all week dealing with the exact same issue for Prod-1 users and Prod-0 Users have stopped. (????)

Below is a visual of what we are seeing happening.

There you see the same WVD user listed twice. some case it can be 3 or 4 times. (i can make it climb to 8 and higher if i manually replicate by disconnecting my WVD session with the Remote Desktop Icon in the task tray in windows, then log back in, it just keeps stacking more sessions.)

This "Disconnected" session is holding our application open, in a "paused state" if you will. And blocking the user from logging into our app.

You can launch WVD as much as you want, it will open each time with a new session, leaving the prior there in a disconnected state.

The one and only cure is to terminate the session from the pooled machines they are connected to, thus killing our program, and now the user can log into WVD properly and launch the program.

So here we have multiple things happening all surrounding one for thing.

Implementation of FSLogix, with a side comment of the release of the 1.2.4763.0 Remote Desktop Application.

We are guessing that over the weekend the "Prod-1" machine will stop doing what it is doing because that is what the "Prod-0" pool did, we did nothing to it, it just corrected itself.

But we can not explain who/what/where/when/why this is happening.

We have stopped the FSLogix rollout to see if no other server has any issues and will not continue with it until cause/fix is found.

How/Why is fslogix+Azure+WVD doing this for up to a week then mysteriously stopping.

How is it correcting itself ?

What are we doing incorrectly with the implementation that causes this ?