FsLogix - Unclean logoff causing locked files until server reboot

Much R 101 Reputation points
2021-01-13T16:29:50.18+00:00

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?

Windows for business | Windows Client for IT Pros | User experience | Remote desktop services and terminal services
Windows for business | Windows Client for IT Pros | User experience | FSLogix

107 answers

Sort by: Oldest
  1. Much R 101 Reputation points
    2021-01-21T16:07:18.98+00:00

    Hi,

    I found Marco's article describing the same problem.

    He also confirms the problem with the new version of FSLogix

    Link: caution-fslogix-2009-2-9-7621-30127-profiles-wont-logoff-completely

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments

  2. Much R 101 Reputation points
    2021-01-22T07:37:31.043+00:00

    Hi,

    I saw that there is a update for the version 2009.
    whats-new

    Unfortunately, this doesn’t solve the problem either.

    Best regards
    Michael

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments

  3. 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.

  4. 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.

  5. 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.
    62107-citrix-fslogix-handle64-lasassexe.png
    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.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.