See this link Stephanos, Marco and Fredrik describes the situation
https://www.meinekleinefarm.net/caution-fslogix-2009-2-9-7621-30127-profiles-wont-logoff-completely/
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Problem is described by M4deman under unclean-logoff-causing-locked-files-until-server-reboot
It seems to have something to do with the 2009 version.
The latest version of FSLogix is installed whats-new
Description
After a user logoff, the "System" Process (PID 4) locks the following folders:
C:\Users\local_username\AppData\Local\Microsoft\Credentials
C:\Users\local_username\AppData\Roaming\Microsoft\Credentials
The user is completely logged of, according to Task Manager.
In the FSLogix Profile Log file I can see the following:
[07:53:55.601][tid:00000c90.0000ce44][ERROR:00000020] Delete profile failed for sid S-1-5-21-3364776539-3721753400-1968955100-1179, Cleaning up manually. (Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.)
The last sentence means that the process cannot access the file, because another process already uses it.
Also the whole "local_username" folder cannot be deleted:
[08:23:15.479][tid:00000c90.0000bcc4][WARN: 00000005] Failed to delete C:\Users\local_usename (Access is denied)
Access Denied
Does someone have any info on this behaviour?
See this link Stephanos, Marco and Fredrik describes the situation
https://www.meinekleinefarm.net/caution-fslogix-2009-2-9-7621-30127-profiles-wont-logoff-completely/
In an effort to keep this thread active I'd just like to describe our current situation.
We have recently deployed FSLogix in our environment. As discussed in this thread, in our case, it seems to be that when a user is logged off due to inactivity (set to 8 hours in our environment) then two things happen, one is that sometimes the profile disk will stay attached on that machine until it is administratively removed. The second issue I'm finding, through reading the ODFC logs, is that when the user is logged off due to inactivity the following logs are displayed when trying to detach the container, saying that the "User is not a member of the include group" even though it they definitely are (and had been using FSLogix during that session).
[12:32:12.701][tid:00000dac.00001abc][INFO] ===== Begin Session: Detach Outlook Data Folder Container: George
[12:32:12.701][tid:00000dac.00001abc][INFO] Configuration Read (DWORD): SOFTWARE\Policies\FSLogix\ODFC\Enabled. Data: 1
[12:32:12.701][tid:00000dac.00001abc][INFO] Include group SID: S-1-5-21-2421605326-1487003826-3486927839-16969
[12:32:12.701][tid:00000dac.00001abc][INFO] Exclude group SID: S-1-5-21-2421605326-1487003826-3486927839-16970
[12:32:12.701][tid:00000dac.00001abc][INFO] Reason set to 1: User is not a member of the include group
[12:32:12.701][tid:00000dac.00001abc][INFO] Reason set to 1: User is not a member of the include group
[12:32:12.701][tid:00000dac.00001abc][INFO] User is not a member of the include group
[12:32:12.716][tid:00000dac.00001abc][INFO] Do not handle this session
[12:32:12.716][tid:00000dac.00001abc][INFO] ===== End Session: Detach Outlook Data Folder Container: George
Once this has happened I've found that I'm having to go into the registry and remove the session key for that users SID and then the next time they log in it will work as normal. Otherwise it will say a log message similar to "The container is already connected to another session" and the profile will not load.
Today we've implemented a workaround in the way of a scheduled task that polls the server every 30 minutes to see if there is any profile disk attached to the machine for a user that's not currently logged in, if there is then it detaches the disk. It also clears out the Session registry keys for any user that isn't currently logged on. I'll let you know how I get on with this script and whether or not it stops the issues occurring.
Anyone here who has found out more regarding the Fslogix locks problem?
So the test package they gave me was for windows 10 1809 not 1909 so it wouldn't install.
I am waiting for them to update it for 1909 which they did but they said they got some errors they need to fix now.
Once they get it I will let you guys know what happens.
I also tried enabling CleanupInvalidSessions and DeleteLocalProfileWhenVHDShouldApply to see if maybe that helps with the folders not being deleted off the server for the time being.
the VHD's aren't getting stuck as much as they use to but not sure why but still have all the folders not being deleted and I believe its related to search.
I will update you once I get a working package and test.
So, I think I have found somewhat of a workaround for this, ([WARN: 00000005] Failed to delete C:\Users\local_usename (Access is denied)). Feel free to try and see if you have any luck.
My Redirections.xml file was fairly robust to try and keep our profile disks as small as possible. It carried over partially from our UPM exclusions. I rebuilt it again based off of : https://stealthpuppy.com/fslogix-profile-containers-redirections/, and then put in an AV exclusion for every path listed in the Redirections file for "userprofile\path listed in exclusion file". We were getting 30 to 40 locked profiles from hung sessions a day, and now we have been 48 hours without 1. I will update if the beast returns, but would be curious if this helps anyone else out.