Forum Discussion
Single user has multiple sessions to multiple session hosts in AVD in the same host pool
Recently in the past week and now this week as well. We've seen multiple users with multiple sessions (one active and other disconnected) to different session hosts in the same host pool with the breadth-first load balancing. Where it should only allow 1 session at a time to any session host in the host pool, and when trying to reconnect, it should always try to connect to the same session host it was previously connected to and not a new one.
This has caused issues with our remote app as customers have an active session to the application with their first AVD session and not able to get back into the application with the same user login (user login for application) because the new AVD session is on a different session host with a different id. If that makes sense?
Also, this started after we implemented FSLogix. Currently happens to one resource (Host pool) at a time. Started with one resource (host pool) and went on for a week, first host pool is okay now and then it started on another resource (host pool) and there for a week now.
Has anyone else faced a similar issue? Is it the newest release of WVD client/Remote Desktop client or something else?
Thanks.
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 ?
- Have you by any chance deployed both RemoteApp and Desktop application groups in the same host pool? Problems arise when these are assigned to the same user. This is not supported. The story reads as if this is the case. If not, this may help others with these issues.
https://learn.microsoft.com/en-us/azure/virtual-desktop/terminology#app-groups
