Forum Discussion
FSLogix Lock issue - user cannot login - user cannot be manually disconnected from session
Issue just started happening. On latest version of FSLogix (hotfix 4), upgraded from hotfix 1. Issue presented in hotfix 1, MS support suggested to update to latest. We have a 15 minute policy pus...
CL981 now this isn't a recommended fix but I have in the past basically just gone into Azure Files (which is where we are storing profiles) share in the Azure Portal, browsed to to the users profile VHD file and just deleted the locks on the SMB handles - that is a pretty dirty fix but it will release it without a reboot - that would be similar to NMI triggered reboot of a hung host. Have a look at this Troubleshooting FSLogix Profile Container Issues: Open File Handles on Azure File Share - Microsoft Community Hub - it doesn't quite say that fix but it does basically in other words in so far as it explains how to do it via CloudShell.
I would have a look at whether there is anything about either the disk being logged dirty or needing repair (something it will perhaps be after doing that unclean forced disconnect solution!) or it doing a disk defrag VHD Disk Compaction - FSLogix | Microsoft Learn; that isn't new, that should have been in HF1 too but worth a look as to whether you have VHDCompactDisk set to either 1 or the setting missing (which is equlivant to 1 as the default) and whether it might be worth testing with it set to 0 see https://learn.microsoft.com/en-us/fslogix/reference-configuration-settings?tabs=profiles#vhdcompactdisk - I have to say I am debating whether that is better off; we are using Azure Files with a 1 month daily snapshot retention and I'm not convinced that that disk compact doesn't cost more than it saves in extra change churn casing the snapshots to grow!
PS. I was looking at a load of "Failed to acquired check session lock for user username" in FSLogix logs last week - I would have a look at this Azure Virtual Desktop - Black Screens on logins - What we've tried so far - Microsoft Community Hub as there is a undocumented known issue with a regression introduced in the the July D week release (aka Preview for August's B non-security content), August B week release (Patch Tuesday) through to today's October B week release that should be fixed in the October D week release; this has been causing various of us issues but it seem to be related to FSLogix on Windows 10 22H2 AVD VMs with login issues (or according to one engineer I was dealing with on a Sev A CritSit call over the weekend is triggered through an issue with the processing of AppX content at a user logoff and then causes issues with subsequent user logins). Now it might be unconnected but what we have seen is that regression only really start to cause some real headaches since September Patch Tuesday release went out, and certainly from what we saw on our systems is it seemed to "build up" in impact from niggly issues with AppX based apps not working to full blown 20 min login/out delays as the AppX deployment services crashed the longer time progressed with that September update installed.
dit-chris Thanks so much for the very detailed reply.
MS recommended to delete the Azure file locks like just like you suggested. Unfortunately, it did not unlock the session/log the user off.
The FSLogix profiles we use are for performance reasons, so when we've had issues in the past, I just go into the Azure file share, and delete the user's entire profile. I've done this 3 times already, and for some reason, this particular user's issue keeps occurring. They log in successfully after a reboot, but our 15 minute disconnect session does not work for them and they're session just gets stuck until the next reboot. The local and fslogix profile folders also need to be manually deleted on the Win10 machine after reboot.
We have the disk compaction disabled in our environment. Nobody saves anything to the FSLogix disk.
I also read a bit about the possible bad Win 10 updates. We removed one that was suspect which was installed in our environment on 9/15 - KB5043064. There's a few reddit posts about this update and it affecting AVD environments with Teams. While we don't use Teams in our AVD environment, I figured it was worth a try removing it.
The issue still persists - I just cannot figure out why it is ONLY for this 1 user out of the 10 or so that use this session host.
We have a sev A case open and am awaiting feedback. Hopefully they can assist. Might be worth to move to Win 11 session host at this point.
MS recommended to delete the Azure file locks like just like you suggested. Unfortunately, it did not unlock the session/log the user off.
The FSLogix profiles we use are for performance reasons, so when we've had issues in the past, I just go into the Azure file share, and delete the user's entire profile. I've done this 3 times already, and for some reason, this particular user's issue keeps occurring. They log in successfully after a reboot, but our 15 minute disconnect session does not work for them and they're session just gets stuck until the next reboot. The local and fslogix profile folders also need to be manually deleted on the Win10 machine after reboot.
We have the disk compaction disabled in our environment. Nobody saves anything to the FSLogix disk.
I also read a bit about the possible bad Win 10 updates. We removed one that was suspect which was installed in our environment on 9/15 - KB5043064. There's a few reddit posts about this update and it affecting AVD environments with Teams. While we don't use Teams in our AVD environment, I figured it was worth a try removing it.
The issue still persists - I just cannot figure out why it is ONLY for this 1 user out of the 10 or so that use this session host.
We have a sev A case open and am awaiting feedback. Hopefully they can assist. Might be worth to move to Win 11 session host at this point.
Did you ever find a solution for this issue? If you could report back and let us know what the fix was please.
Yes, MS issued a bad update back in Aug/Sep 2024 time frame for win10 that affected AVD hosts. We worked with MS and an interim workaround was given to us, and eventually a subsequent update was supposed to fix it, but neither worked for us. We ended up moving to Server 2022 hosts for our AVD environment, and it had been stable since.
