Jun 25 2020 04:37 AM - edited Jun 26 2020 02:18 AM
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:
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?con.... 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%20po...). The image on the master VM is based on the Windows 10 Multi-Session 2004 gallery image.
Aug 18 2020 05:14 AM
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
Jan 19 2021 07:52 PM
@Pylsa Did you find an answer to this ?
Sep 07 2021 11:18 AM
Sep 07 2021 11:09 PM
Sep 08 2021 08:54 AM
Solution@Chris1989 @tapandewanjee1984 @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.
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!
Sep 08 2021 11:50 PM
Nov 10 2021 05:03 AM
Jun 08 2022 09:49 AM
Sep 08 2021 08:54 AM
Solution@Chris1989 @tapandewanjee1984 @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.
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!