Jump to content
Welcome to our new Citrix community!
  • 0

Hosted Desktop Profile Management Methodology Question

Jason Fenoglio1709162082


I have a client using CVAD 1912 LTSR CU1.  They run Office 365 and other various applications on 2 hosted desktop servers.  I've configured DFS for folder redirection(User Directories), Citrix UPM (general user profile data and user hive), and FSLogix Office Containers (Everything Office 365 related.)  I'm having issues with profiles getting corrupted on a regular basis.  My folder redirection is working great.  Desktop, Documents, Favorites, etc.. are all being saved during the profile corruption mess.  Citrix UPM has local profile deletion turned on but is delayed for 20 secs while the FSLogix Office VHDX dismounts.  This all appears to be working great.  Sometimes I'll have issues with the Outlook.exe executable stopping on larger OSTs but I have the white space reclamation turned off. 


After a few weeks, profiles will fail to clean up and I'll get TEMP profiles or .001 numbered profile folders will create.  Sometimes it's just cleaning the local profiles up that fixes it and other times, I have to delete the UPM.  I'll also get "Group policy client service failed at logon. Access denied" after a long logon.  At that point, I have to delete the UPM profile from the DFS share.  The customer is getting frustrated having to recreate their profiles so often and I'm wanting to get some validation that this way of profile handing is a valid solution.  I feel that having a separate space for folder redirection, UPM profiles, and FSLogix Office Containers is a nice solution so if one were to fail, I wouldn't lose the other's information and start a user from scratch.


Can anyone validate this and/or give me some advice?

Link to comment

1 answer to this question

Recommended Posts

  • 0

We have a similar setup and are seeing a similar UPM "profile corruption" issue. We are also on CVAD 1912 LTSR CU1 and use folder redirection for Desktop/Documents and UPM for everything else. No FSLogix in use, but it is installed for a potential migration in the near future. Around the beginning of May this year we started having random users experience the dreaded "Group policy client service failed at logon. Access denied" error like your customer is seeing. We started fixing them by "resetting" the UPM profiles to restore access, but it would lose their custom application settings. Having the separate folder redirection of the personal files is nice so we don't lose any real data.


Thing is that we have been working with this hybrid setup for a few years, so why did it stop working now, but not for everyone. There seems to be no rhyme or specific reason for the users that do experience this issue. I had a support ticket open with Citrix, but they told us they couldn't help us as we were running in a oddly versioned environment. We use 1912CU1 VDA, but 1909 DC/SF. UPM is configured using WEM and the agent (1909.1) doesn't match the WEM Broker (1906). I can't blame them, but in my experience the newer agents tend to be backwards compatible with older infrastructure and it's a lot easier to update them instead of the whole shebang, especially in an environment where we can't update as often as we would like to (#1 reason we want to move to Citrix Cloud CVAD sometime in the near future).


Anyways, I did some debugging on our end and determined that UPM (or something else) was resetting the permissions on the root of the user's registry hive. I compared a registry hive from a broken profile and a good profile and they were completely different (most of the permissions were missing on the bad profile). I ended up creating a script that watches the Citrix Connection Broker logs for a Connection Failure Reason of Other and then it checks the affected user's UPM profile for registry hive issues. If it is determined that the user does not have rights to the their own user hive, then it modifies the SDDL string from a known good hive's ACL (inputting the correct SIDs for the affected user) and applies the correct ACL to the bad hive. The next time the user logs in, everything works as if nothing bad ever happened. The script runs on a regular basis (every 5 minutes), so a user could attempt to login one minute, see the group policy error, wait up to five minutes, the bad profile gets automatically fixed by the script, next login goes through fine. Much easier on us and our helpdesk while we wait for an opportune time to upgrade our environment to a newer version of WEM (hopefully moving straight to the Cloud WEM service) as requested by support, then we will open a new support ticket if it still fails to work.


@Jason Fenoglio1709162082 Does your client use WEM to manage their environment? Wondering if there are any other commonalities between our environments.


Here's the rundown on our environment:

VDA: 1912CU1

WEM: 1909.1.1

Host OS: Server 2019 RDSH w/ latest Windows Updates

We use Citrix App Layering 2008 to build our images and use MCS to provision the VMs.

Hypervisor: Nutanix AHV 5.10.7 LTS

File Host: Nutanix Files 3.5.2



Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...