QuickPost – FSLogix container failures when managing local groups through GPP

I know several people in the community have written about this before, but I will cover it quickly today as I encountered it myself for the first time. I think it is also important to get this out there as I am well aware I have suggested to many customers that they manage their FSLogix local groups through Group Policy Preferences, so this will make sure they do it properly!

As many of you who use FSLogix will know, FSLogix drives the users who are enabled for both Profile Containers and Office Containers through local groups. There are two sets of groups with both Include and Exclude functionality, allowing you to enable FSLogix users for either set of containers on a black- or whitelist basis. The commonest practice is to simply add users or groups from Active Directory to either the FSLogix Profile Include List group or FSLogix ODFC Include List group.

For a long time I’ve always thought the best way to deal with this is to use Group Policy Preferences Local Users and Groups. This allows you to control the membership of the groups in a quite granular fashion, and also, I always recommended using it in Replace mode. The idea with Replace mode for the users and groups CSE is that if an administrator modified the group in any way, then at the next policy refresh it would be forced back to the initial desired state.

However, recently I noticed that some sessions using FSLogix were failing to log on properly. This would happen mainly to shared systems like XenApp/RDSH, but also occasionally on Windows 10 VDI as well.

Exploring the issue naturally led us into the FSLogix logs. We observed that the FSLogix container appeared to be locked at logon, which can commonly happen when something has kept the profile open.

Normally, it is antivirus or other security software to blame, but in this instance that didn’t appear to be the case. Looking at the file shares revealed that the user’s profile was still open on a particular machine. However, it did not appear to be locked by anything other than the SYSTEM account.

Digging further, we found that the user’s profile was indeed fully mounted still on the target device, and loaded in Windows – as if the user had failed to detach at logoff.

Naturally, this would lead to problems at logon if the user tried to hit another device – if the FSLogix policies for “stop when profile fails” were active, you would see this error

If you didn’t have this policy active, you would simply see the user get a “new” default local profile, so none of their changes would persist.

If you were using dedicated pooled machines, however, the profile would simply be already be mounted so you possibly wouldn’t see any error, although the logs would mention that the profile was already in use.

However on some occasions, especially after a reboot, you may also see this problem causing temporary profiles to be loaded.

Investigating further, we tried to identify why the profile wasn’t unmounting at logoff. Luckily, the FSLogix logs also capture information during dismount. We observed the following

You can see the problem – the profile isn’t unmounted because the FSLogix driver thinks the user isn’t in the include group. WTF? The user definitely is…

However, it turns out that recently FSLogix has moved from using the name of the group as the marker for membership to the actual SID of the group. This makes sense. It’s only when you understand how Group Policy Preferences Local Users and Groups works that you see the issue.

When GPP Local Users and Groups is set to Replace mode, the CSE doesn’t remove the users/groups from the local group and add them back in – it actually recreates the groups completely. So the original FSLogix local group is deleted, and replaced with a new one – with a new SID.

So if a refresh occurs while the user is logged in (which it generally will), then the SID of the group changes, and the FSLogix driver no longer thinks that the user is in the local group – and henceforth doesn’t unmount the profile and causes problems at next login.

To resolve it, you have one of two choices:-

1. Switch to Update instead of Replace for your GPP Local Users and Groups policy

2. Switch to the old Restricted Groups policy instead of using GPP

Personally, I prefer option #2 – I find the old Restricted Groups more reliable than GPP in Update mode, although they are significantly less granular. When setting up Restricted Groups, you simply need to type the FSLogix local group names in – no prefix such as BUILTIN is required.

I have tested both these solutions with users during multiple policy refreshes and can confirm they work fine.

So if I’ve ever suggested using GPP Local Users and Groups in Replace mode to manage your FSLogix local groups, please accept my apologies, but now you will need to switch to one of the above.

Hopefully I should have a new part from my logon times series out very soon – I am just ironing out some kinks in the lab.