FsLogix - Unclean logoff causing locked files until server reboot

Much R 101

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?

Anonymous

2021-01-14T03:03:58.32+00:00

Hello @Much R

Did you check affected user has full control and Owner over their FSLogix Folder and the VHDX files ?

Thanks
Karlie
Much R 101 Reputation points

2021-02-02T08:02:21.997+00:00

Hello,

Where is my answer from yesterday?
Why was this deleted?

How can I open a ticket at Microsoft now?

Thank you
Anonymous

2021-02-02T08:16:39.607+00:00

Hello @Much R

sorry I was going to delete my comment as it wasn't helpful, and your comment is below mine, so it seems they were deleted together. I want to restore but it doesn't has this option.

FSLogix is supported for use with versions of Windows and Office that are still included in the Microsoft Support Lifecycle.

How to open a FSLogix Support Request
https://social.msdn.microsoft.com/Forums/en-US/14ea5f6f-760b-4ad2-83cf-23c3cbc1bcc4/how-to-open-a-fslogix-support-request?forum=FSLogix

Best regards
Karlie
Germain 11 Reputation points

2021-02-19T11:44:10.117+00:00

We are currently experiencing the same issue. The user VHDX is locked by system and can only be unlocked by rebooting the server.
Has Microsoft acknowledged this issue?

Currently using: 2.9.7654.46150
Bracko Ewald 31 Reputation points

2021-02-19T12:10:09.137+00:00

Did you activate the registry value HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Apps\CleanupInvalidSessions (REG_DWORD, 0x1)?
Do you use Cloud Cache or not?

Also, maybe you can check with the frx command line tool if there are still some redirects pointing to the use VHDX file. You can then use that tool to delete them manually and detach the VHDX files afterwards using diskpart.
Marius Neuhaus 1 Reputation point

2021-03-09T10:31:38.737+00:00

Hello,

we have the same problem.
We use on-premise terminalserver.:
Windows Server 2019
Citrix 1912 CU2 LTSR
FSLogix 2.9.7621.30127

I've tried the CleanupInvalidSessions RegKey, but it doesn't effect.
We don't use Cloud Cache.
FSLogix Configuration only local and not per gpo.
The frx command line tool dont show redirects pointing to the use VHDX file.
Permission are set correct. Users work correctly with the containers.
Luckily the problem occurs only randomly and not at every logoff.

In the FSLogix Configuration we include the group domain-users and exclude the domain-administrators.
Could it be a Problem?

Best Regards,
Marius
itsupport 1 Reputation point

2021-05-26T12:40:37.147+00:00

When this happens are you left with multiple <USERNAME>.original folders? I've seen it go as high as <USERNAME>.original11 before I just manually delete all the folders.
Guido Racamato 26 Reputation points

2021-09-28T17:39:34.337+00:00

Hello Everyone, For the Group Policy Access Denied, once you get an affected user, could you please modify the following registry? There's no reboot required.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileService\References\<SID affected user>
REG_BINARY: RefCount
Value: 0
Jon McLeod 1 Reputation point

2021-11-19T14:56:08.267+00:00

This is the answer. Thank you.
Farooq 5 Reputation points

2024-02-14T12:02:36.9533333+00:00

We are having the same issue. We have an RDS environment and time to time users get logged in with Temporary profile, when I check the FSlogix logs I am seeing the following error - Failed to open virtual disk: \server\Profiles\S-1-5-21-26711-2174_user\Profile_user.vhd (The process cannot access the file because it is being used by another process.)
What we done to try resolve this or at least try find the cause and reduce downtime is, we have removed AV from all RDS host, we have created a script which logs out all users at midnight but issue is still occurring. We have a case opened with Microsoft but unfortunately there has been no resolution. Another issue we had is where users could not sign into their Outlook, teams, Office profile on the host. Has anyone else experiencing this issue and has anyone managed to resolve this? Any help or suggestion would be much appreciated.

107 answers

Stefanos Evangelou 116 Reputation points

2021-01-30T20:43:54.123+00:00

Hello,

I am having the exact same issue in a production environment running Citrix Virtual Apps and Desktops LTSR 1912 CU1 on Windows Server 2019 Standard Session Machines with latest OS updates and Office365 updates. Citrix Profile Management components are disabled and not used in the environment. Only FsLogix latest stable release is being used for user profile management.

We have tried to apply the following workarounds, to no avail: https://stefanos.cloud/blog/kb/how-to-resolve-error-group-policy-client-service-failed-the-logon-access-denied-in-citrix-and-fslogix-environments/.

The root cause of the issue seems to be that the local_username profiles created by FsLogix are not released properly at logoff (see attached screenshot). The file handles are kept open by the lsass.exe process. This is reflected in the FsLogix profile container logs (cannot delete C:\users\username folder. Access denied). We tried to manually close these handles with the SYSTEM user but afterwards the FsLogix service would not startup in the session machine.

We have opened a technical case with Microsoft which is being escalated. We really hope that Microsoft provides a release soon including a fix for this issue.
Was this answer helpful?

1 person found this answer helpful.
Bracko Ewald 31 Reputation points

2021-02-01T10:46:40.21+00:00

If you have a deeper look into this issue with the frx tool from fslogix and with diskpart you'll see that this lock is there because the folder redirections were not removed and the corresponding VHD(X) file wasn't detached during the logoff process. Applies to both profile and Office365 containers.

Stefanos Evangelou 116 Reputation points

2021-02-02T10:46:25.733+00:00

Hello,

the screenshot i uploaded in my previous post is actually incorrect, as it refers to the C:\Users\username folder which corresponds to the fslogix profile container. The profile container is eventually properly released in my environment, so no issues there. The issue is with the local profile (C:\Users\local_username folder) which is not properly released, see attached screenshot.

Bracko Ewald 31 Reputation points

2021-02-02T11:20:55.95+00:00

I assume you have the GPO/GPP setting "Keep local folder after user logs out" (registry: HKLM\SOFTWARE\FSLogix\Profiles\KeepLocalDir) configured accordingly?

Stefanos Evangelou 116 Reputation points

2021-02-04T10:36:06.633+00:00

Yes, the KeepLocalDir registry key is set to zero (0).

Bracko Ewald 31 Reputation points

2021-02-04T11:14:43.437+00:00

What does the Profile Log say? Usually it should tell you if it has removed the Local_ path or not.
You should find that close to the end of the logged Logoff process of an user there.

Dlo 96 Reputation points

2021-02-11T15:02:36.3+00:00

We dont have this set and do not have this registry key and we get random local folders still there to.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Much R 101 Reputation points

2021-01-26T10:23:03.213+00:00

I noticed the following, but I'm not sure.

We have a GPO active so that disconnected sessions are automatically logged off after 3 hours. I have currently disabled this setting.
There seems to be a difference whether the user logs out himself or whether this is done by the system.

Does anyone else have this setting active?

Instead of logging off the users whit GPO, we restart the RDS server every day. So far I haven't found any local_username folders
Was this answer helpful?

1 person found this answer helpful.
Bracko Ewald 31 Reputation points

2021-01-26T10:53:52.097+00:00

We are doing something similar than you right now (no auto logoff of the users until server-reboot). Due to those issues with the fxlogix profiles I even implemented a Powershell script to properly log off the users a few minutes before we restart our RDS servers because I assumed the issues might be caused by an improper logoff during the server-reboot.
This didn't help either.
If I understood you correctly you had those issues also with active auto disconnect & logoff settings.
There seems to be a general issue causing this kind of behavior as it looks like.

Much R 101 Reputation points

2021-01-26T17:24:47.263+00:00

As already written, I'm not sure if it has to do with the automatic logout.
It seems better if I disable this setting.

I can say more at the end of the week.

Or it's just a coincidence.....
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Bracko Ewald 31 Reputation points

2021-01-25T16:16:19.713+00:00

We are encountering the same issue with the 2004 release (2.9.7349.30108), too.
The fslogix agent doesn't delete the redirections and unmount the containers on rare occasions.
But when it starts to happen more and more users are affected.
A reboot of the system will "fix" it for the moment.
Maybe this is caused by another Microsft update...
Was this answer helpful?

1 person found this answer helpful.
Gianluca Melis 101 Reputation points

2021-05-06T09:24:35.893+00:00

we had the same problems with 2009, a downgrade to 2004 fixed everything (2.9.7349.30108 to be specific). Please note we had to uninstall 2009, restart, install 2004 and restart again. if you just install 2004 "on top" 2009 ist not going to be replaced but just installed alongside and in our case we could see in the logs that windows was still using the 2009 version.
Maybe your problem ist not strictly related to the 2009 version.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Stefanos Evangelou 116 Reputation points

2021-02-04T11:02:01.567+00:00

I have engaged Microsoft Support on this. We checked a few things:

1) Double check that all antivirus exclusions are set up properly, as per Microsoft recommendations: https://learn.microsoft.com/en-us/azure/architecture/example-scenario/wvd/windows-virtual-desktop-fslogix (antivirus exclusions section).
2) Experiment with changing a few registry key values affecting the FsLogix profile operations, as per: https://learn.microsoft.com/en-us/fslogix/profile-container-configuration-reference.
3) Took procmon and etl traces in a working and non-working scenario, since this is occurring to some of the users. First analysis of procmon did not show any permissions violations, all CloseFile events by the FsLogix service (run with NT Authority\SYSTEM credentials) seems to be clean (SUCCESS). Now waiting on analysis of the procmon and etl logs from another round of testing by Microsoft Support.
4) Stop and disable the "Connected User Experiences and Telemetry" Windows service, as this has been seen to cause issues with profile release operations in Microsoft RDS/UPD environments. Nothing changed, issue persists.
5) Check FsLogix redirections.xml file configuration. This testing is in progress and more details are included in the following post: https://stefanos.cloud/blog/kb/how-to-resolve-error-group-policy-client-service-failed-the-logon-access-denied-in-citrix-and-fslogix-environments/.
Was this answer helpful?

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Much R 101 Reputation points

2021-02-01T16:11:42.237+00:00
Hello,

My workaround:
1. Deactivate all automatisms with which the users are automatically logged off (Tasks, Scripts, GPO,....).
2. Schedule a daily restart of the RDS server.
That seems to be going better.

Additive:
I had a case that did not affect the local_Username folder, but the Username folder. See the attachment.

I will also try to open a ticket with Microsoft. But that doesn't seem so easy...
Microsoft doesn't want anyone to report a problem...
Microsoft doesn't read here in the forum either...
Was this answer helpful?
Mihail Gusev 1 Reputation point

2021-02-11T12:00:51.607+00:00

I wish I could apply such workarond, but my RDS servers used 24/7
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

FsLogix - Unclean logoff causing locked files until server reboot

107 answers

Your answer