Caution: FSLogix 2009 (2.9.7621.30127) profiles won’t logoff completely

At three customer sites I created test machine catalogs with FSLogix 2009, and all of them had the same issue, that FSLogix profiles won’t logoff completely at the end of the day.

Hanging profiles (2)

Update January 11, 2021: I was informed about a better solution via Twitter, and updated the Blog post accordingly.

The Problem

During my personal tests with FSLogix 2009 (2.9.7621.30127) I discovered that the profiles won’t logoff completely at the end of the day. See the following screenshots.

You can clearly see, that despite there are no active or disconnected user sessions, some of the VHDX disks are still mounted, but more important the folders from C:\users\ won’t vanish.

This makes a second login impossible on the same VDA.

The situation

At my Citrix Machine creation services (MCS) customers, I never update machine catalogs, I always replace them with fresh Golden master images installed from scratch via Microsoft Deployment Toolkit (MDT). So all tests were performed on a freshly installed machine catalog. No in-place upgrade of the FSLogix apps or the Citrix VDA. This is the affected test environment:

  • Windows Server 2016 de-DE
    December 8, 2020—KB4593226 (OS Build 14393.4104))
  • Citrix VDA 1912 CU2 via MCS
  • FSLogix 2009 (2.9.7621.30127)
    (Single SMB share, no Cloud Cache)

Every second day, the test users were unable to login. A reboot could solve the problem temporary.

I wasn’t able to find anything meaningful in the FSLogix logs, but I post them non the less at the end of the blog post, so someone with the same issue might be able to find this blog post through his favorite search engine.

The (old) solution

The solution to my problem, after lots of different tests, was to downgrade to FSLogix 2004 (2.9.7349.30108) and all problems were instantly gone. The current test (and soon to be productive) environments for all my customers look like this now:

  • Windows Server 2016 de-DE
    (December 8, 2020—KB4593226 (OS Build 14393.4104))
  • Citrix VDA 1912 CU2 via MCS
  • FSLogix 2004 (2.9.7349.30108)
    (Single SMB share, no Cloud Cache)

The better solution

This paragraph was added on 11.01.2021

Soon after I published this blog post, Fredrik Endresen contacted my on Twitter, with the following statement:

He encountered the same problems as we did, and during his troubleshooting he discovered an undocumented FSLogix change in version 2009 (2.9.7621.30127). According to him, FSLogix uses the SID of the local include/exclude groups now, instead of the name. As I manage those groups via Group Policy Preferences (GPP) and choose the mode replace instead of update, these groups get re-created during the Group Policy background refresh, which changes the SID, resulting in the issues described above.

Now the real solution would be, to double check how you manage the local FSLogix groups. If you don’t manage them via GPP, there is a great change you belong to the group of people, not affected by this problem.
Now I will test this theory during the next Citrix MCS Master Image tests, set my GPP to update instead of replace, and also as mentioned in the comments and in the World of EUC Slack, the new registry value CleanupInvalidSessions.

The FSlogix logs








Author: Marco

Marco is an IT-System administrator and IT-Consultant with 10+ years experience. He is specialized in the delivery of virtual Apps and Desktops with Citrix solutions. In 2017 he has been awarded Citrix Technology Advocate by Citrix for his community work (#CTA). His second core area is availability & performance monitoring with Zabbix, a leading open-source solution. His employer is the German IT-Company ANAXCO, which is developing a Transport Management Software (TMS) based on Microsoft Dynamics AX. More about Marco

9 thoughts on “Caution: FSLogix 2009 (2.9.7621.30127) profiles won’t logoff completely”

  1. Hi Marco,

    Have you seen this in the release notes
    SET IN: Software\fslogix\apps\CleanupInvalidSessions

    Available in FSLogix release 2009 or later


    Default Value 0

    At times a Windows Session may suffer an inelegant termination, in these cases FSLogix is not provided an appropriate event to trigger the dismount of the VHD(x) file for Profile Container and Office Container. By setting CleanupInvalidSessions to 1, additional FSLogix logic is triggered to make this scenario less likely. Setting CleanupInvalidSessions will cause the functionality to be utilized for both Profile Container and Office Container. KNOWN ISSUE: at this time CleanupInvalidSessions should not be used in conjunction with Cloud Cache when concurrent sessions (e.g utilizing ProfileType/VHDAccessMode) are in use.

  2. I’ve tried the CleanupInvalidSessions suggestion which didn’t work.
    This doesn’t seem to affect all of our setups.

  3. Hello Marco,

    I found your article in the hope of a solution.

    Unfortunately, the problem doesn’t really seem to have anything to do with the groups.
    We don’t distribute the groups with GPP and we have the problem.
    I really believe the issue has to do with the version of FSLogix.

    I’ve described the problem here. Link:

    Unfortunately so far without success.

    Best regards

  4. Interestingly we have the same issues with the 2004 v2.9.7349.30108 release. Probably ther’s something else causing this kind of behavior, maybe another Microsoft update on the OS side…

  5. Hi,
    I experience the same problems with the current fslogix release on Windows Virtual Desktop. Has anyone seen a solution for this ? I´ve also tried the CleanupInvalidSessions reg key, but it does not solve this issue at all. I´m kinda lost here and user profiles are all over the place right now.


    1. Hi,
      I have the same problem with the 2009 HF_01 with Cloud Cache.
      At the next logon the user have a black screen (unable to access in exclusive mode with the vhdx).
      Do you have news about this problem?


  6. Was facing this recently, solution was using GPOs to configure RDS inactive and idle disconnect times, we also applied the reg key for cleanupinvalidsessions with value to each SessionHost. Also had this script handy but didn’t implement it, did test it from cloudshell.
    GPO added to session hosts OU for sessions, I didn’t configure anything for active sessions and setup two hour time outs for idle and disconnected sessions to allow an hour or so for lunch.

    In the Group Policy Management Editor, navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits.

    Script to fix session hosts, run from azure portal using run as, if i was feeling fancy I would use a get-azvm in there and a parralell flag to do it at once, but only had a few session hosts to run it against, make this change on golden image if you can.
    $registryPath = “HKCU:\Software\fslogix\apps”

    $Name = “CleanupInvalidSesions”

    $value = “1”

    IF(!(Test-Path $registryPath))


    New-Item -Path $registryPath -Force | Out-Null

    New-ItemProperty -Path $registryPath -Name $name -Value $value -PropertyType DWORD -Force | Out-Null}

    ELSE {

    New-ItemProperty -Path $registryPath -Name $name -Value $value -PropertyType DWORD -Force | Out-Null}

    (Get-ItemProperty -Path HKCU:\Software\fslogix\apps -Name CleanupInvalidSesions).CleanupInvalidSesions

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.