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
Most helpful Newest Oldest
  1. Андрей Михалевский 3,476 Reputation points
    2021-10-20T09:55:31.237+00:00

    As a temporary solution, I use this script when a user logs out using group policies. 

    $SID = ([System.Security.Principal.WindowsIdentity]::GetCurrent()).User.Value

Set-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileService\References\$SID" -Name RefCount -Value ([byte[]](0x00,0x00,0x00,0x00))

    Was this answer helpful?

    2 people found this answer helpful.
  2. MarkD 1 Reputation point
    2021-11-24T21:57:57.35+00:00

    Hi All, we battled variations of this and took us a while to pin ours down because we believed it to be centered on FSLogix. We experienced many of the symptoms laid out here and it was very intermittent and unpredictable.

    Environment:

    • Citrix Virtual Apps (Published Desktops / Shared Session Hosts) Version 1912.
    • Windows Server 2019
    • Tried with two FSLogix versions: 2.9.7117.27413 and 2.9.7979.62170

    Our Experience:

    • Users VHDX would get locked.
    • The Citrix Session would be logged off most of the time but not always.
    • Regardless of ^^ the session would show active from VHDX storage using "Net Session" sourcing from the VDA they were logged in from.
    • They would get temporary profiles due to profile lock.
    • Sometimes while in the middle of working, they would lock up.
    • Rebooting the non-persistent VDA seemed to be the only way to truly clear it along with manually closing the open profile on the VHDX Profile share.
    • This was random across 20+ VDA servers.

    Our Troubleshooting:

    • We would watch the session timers on the shared storage using Net Session and keep an eye on ones that would have high counters.
    • We would review FSLogix logs on users who were getting temp profiles.
    • We would review event logs.
    • Lots of reading which brought me here.

    Summary:

    The real pointer came when we were able to remote to a user who was actively having a session lock while still working. Since the VDA's were being rebooted daily to help get through the issue, we would miss some log entries.

    Ultimately, that user was creating a ton of Event ID 107 Citrix.Authentication.IdentityAssertion in the app log.

    That led us to article: https://support.citrix.com/article/CTX255423

    That was our issue, the Kerberos Renew Time was set to 10 hours. Many of our users due to various reasons have been working longer hours and we are requried to have very high session limit timers for idle but active then disconnected. If that user had never disconnected and reconnected during the day or even had their 20 minute idle screen come up, their ticket would expire and not renew causing all access to network resources to come to a halt. Primary indicator was loss of access to the VHDX. The session wouldn't tear down correctly due to this. We discovered this in our GPO's and modified that at the domain level and we have been error free since.

    Another helper was a log aggregator that allowed us to see TGT requests and if the user only had the initial request and no subsequent requests from that machine, you could begin to predict the failure.

    Check your Kerberos settings in your Default Domain Policy or whatever policy is applied at the domain level that manages Kerberos ticket times.

    I am sure this won't solve it for all but based on what I read here, it might be contributing.

    It was very frustrating to figure out. Looking back, since this has been this way since before I started working here, it explained some other strange access issues that got written off after reboots.

    Hope this helps!

    Was this answer helpful?

  3. Jan Koppelin 1 Reputation point
    2021-11-27T09:12:10.74+00:00

    Hello everyone,
    after an update from 1912 CU2 to 1912 CU4, we have the exact the same problems.

    After a long search we restored the master image from the backup and the problems were gone...

    We examined the difference between the master images and found that the working worker has not "Citrix User Profile Manager" and a "Citrix User Profile Manager WMI Plug-In" installed. Is there a connection? Do you have these VDA plugins installed?

    Was this answer helpful?

  4. Krüger Benjamin 1 Reputation point
    2021-11-29T14:02:13.933+00:00

    A preview update has been released. "KB5007266"

    Addresses an issue that causessearchindexer.exe to keep handles to the per user search database in the path below after you sign out: “C:\Users\username\AppData\Roaming\Microsoft\Search\Data\Applications\<SID>\” As a result, searchindexer.exe stops working and duplicate profile names are created.

    https://support.microsoft.com/en-us/topic/november-22-2021-kb5007266-os-build-17763-2330-preview-c9ba0c4c-c8b7-409a-8fac-a76ffae8f94f

    https://twitter.com/\_POPPELGAARD/status/1463418452958453768

    Was this answer helpful?

  5. owen osborne 1 Reputation point
    2021-11-30T16:34:01.703+00:00

    Using the latest version of fslogix we suffer the same problem on our rds 2012r2 servers and have done through various releases.
    If you have the GPO setting to remove the local profiles at log off the profile will be trashed and we will find file locks on local search folders. Causing a profile error.
    "C:\Users\username\AppData\Roaming\Microsoft\Search\"

    You can use delprof to remove the profile cleanly
    you can stop search to remove the lock

    As a all in one solution i disable the GPO that removes the local profile. Then on on a nightly schedule stop the search services, disable the search services. Have delprof run. Rinse and repeat a few times.

    by the morning previous sessions are cleaned off so new sessions work fine.
    Works 95% of the time.

    Was this answer helpful?

    0 comments

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.