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

FSL1.txt

FSL2.txt

FSL3.txt

Eventlog

Eventlog
Eventlog

Event1.txt

 

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

2 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
    CleanupInvalidSessions
    SET IN: Software\fslogix\apps\CleanupInvalidSessions

    Available in FSLogix release 2009 or later

    TypeDWORD

    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.

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.