Forum Discussion
Solved
WVD broker doesn't route to disconnected/existing session
We have a farm set up with about 13 WVD session hosts based on Windows 10 2004 Multi-session. We use FSLogix on Azure File Shares to store user profiles.
Whenever a user wants to reconnect to his/her user for any reason, WVD seems to automatically assign one of the session hosts for logon and tries to connect the user to that host. Unfortunately, for us this means there's about a 1/13 chance of this user getting connected to the right host to pick up the old session. When this doesn't happen, FSLogix throws an error because the VHD is already locked in the other disconnected session and there is no way for the user to log back onto the system without admin intervention to manually trace and terminate the disconnected session that has the VHD locked.
This pretty much 100% of the times happens when:
- A user's client device dies, goes to sleep, or loses connection otherwise and the user the tries to reconnect.
- A user tries to log on to another client device with the other one still open.
- A user uses the "disconnect" option in Windows and then tries to reconnect later.
This means there is no way for us to set an "idle" policy to disconnect users for security purposes and causes significant inconvenience for users and a puts a lot of stress on our service desk. We are trying out WVD in production for the first time and the course of this pilot will decide wether or not we are going to implement it with some of or other larger clients.
This is either a huge flaw in WVD features or a huge flaw in our configuration. Is there something we can do about this?
We have tried setting the host settings through GPO but the WVD broker of course doesn't pick this up. We have tried settings customRDPProperty disableconnectionsharing:i:value that is advertised as being compatible with WVD according to https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/rdp-files?context=/azure/virtual-desktop/context/context. However, this has had no effect.
Our image is deployed from a VHD attached to a master VM to managed disks for our hosts using the WVD-update template (https://github.com/Azure/RDS-Templates/tree/master/wvd-templates/Update%20existing%20WVD%20host%20pool). The image on the master VM is based on the Windows 10 Multi-Session 2004 gallery image.
Chris1989 tapandewanjee19 Daniel Cairns
Apologies everyone, I have not been actively monitoring this question! My bad!
In the end, we ended up creating a ticket with Microsoft and then escalating it further and further with our own (deep-dive) technical findings. We ended up being connected to the actual dev team for AVD (then WVD) and they found the error for us.
SpoilerSurprise: It was in the AVD back end.What ended up being the case was that we had previously synchronised on-prem users to AAD and used AVD with those users. We then deleted everything from AAD to start afresh with the Azure/O365 side of things as there was a lot of polution. We then synchronised the on-prem users back to AAD which created new user objects for all of them with the same UPN as before but with a new SID on AAD.
Because the SID changed for these users. the Microsoft-managed broker service thought these users were actually different users from the one we had created initially and then made two "slots" available for these users in the brokering service.
However, FSLogix (and lots of other services) use the UPN for reference so everything windows-based in our AVD environment went wrong when two users with the same UPN were logged on.
The product team manually removed the duplicate entries for us in the back end and that resolved all of our issues. We have now successfully rolled out and are successfully using and managing AVD for multiple (large) clients and we have been ever since this issue.
Again, apologies for the late solution but I hope this helps someone else!
8 Replies
Chris1989 tapandewanjee19 Daniel Cairns
Apologies everyone, I have not been actively monitoring this question! My bad!
In the end, we ended up creating a ticket with Microsoft and then escalating it further and further with our own (deep-dive) technical findings. We ended up being connected to the actual dev team for AVD (then WVD) and they found the error for us.
SpoilerSurprise: It was in the AVD back end.What ended up being the case was that we had previously synchronised on-prem users to AAD and used AVD with those users. We then deleted everything from AAD to start afresh with the Azure/O365 side of things as there was a lot of polution. We then synchronised the on-prem users back to AAD which created new user objects for all of them with the same UPN as before but with a new SID on AAD.
Because the SID changed for these users. the Microsoft-managed broker service thought these users were actually different users from the one we had created initially and then made two "slots" available for these users in the brokering service.
However, FSLogix (and lots of other services) use the UPN for reference so everything windows-based in our AVD environment went wrong when two users with the same UPN were logged on.
The product team manually removed the duplicate entries for us in the back end and that resolved all of our issues. We have now successfully rolled out and are successfully using and managing AVD for multiple (large) clients and we have been ever since this issue.
Again, apologies for the late solution but I hope this helps someone else!
- Thank you
This thread should be a bible for Microsoft, just going through the same with MS support now.
Issue occurred when the Azure AD accounts were deleted and re-synced. Now we get duplicate sessions. Hopefully an automated solution can be developed. - Thank's for that information.
I opened a ticket and they resolved the issue. Even if the support case said that they haven't found anything the problem is gone => there was a problem on the session broker side 100% sure..
Regards
Christoph - Thank you. It's possible that we are issuing the same problem during the switch from Azure AD sync from an old server to a new one.
I'll open a ticket wihtin Microsoft to get resolved this finally.
Thank you
- AVD Team should look into this issue. This is really an issue most of us are seeing while using the AVD
- Microsoft seems not to care about the known issues in WVD.
There aren't enough clients on it that they are reacting..
Pylsa Did you find an answer to this ?
- SpoilerSame Problem
Helo,
same Probleme here since 2019. Never find a solution!!
I opened a ticket last year and Microsoft did some changes into my Azure Agent Token.
Our 8 vm's weren't shown via system management powerShell as online. Just one of them appearing randomly. But they all must be shown as in the picture:
Get-RdsSessionHost -Tenant "name" -Hostpool "pool" | ft SessionHostName, AssignedUser, HostPoolName, AllowNewSession, Sessions, LastHeartbeat, AgentVersion, Status, UpdateState, LastUpdateTime, UpdateErrorMessage
This Problem has been fixed. Since this we are sometimes! able to reconnect existing session.
I think we are able to reconnect a closed session when the MS WVD Client APP is closed via "X".
But most users aren't able to reconnect after a user's client device dies, goes to sleep, or loses connection otherwise and the user the tries to reconnect.We are using FSLogix with an SMB share on a classic Windows File Server. Multi Session is denied. We wan't the users to get his same session always.
Any update on this ?
Regards
