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

The Group Policy Client service failed the sign-in. Access is denied.


Question

Hi everyone,

 

We are having problems with Citrix Virtual Apps. Some time ago a message "The Group Policy Client service failed the sign-in. Access is denied." would appear every so often, when the user openned any application, only with specific users...  but yesterday this message began to appear in masse...

 

-If we rename (or delete) the user's profile in the share where we have the profiles, that user can run apps again.

-If we give administrator permissions on each VDA to all domain users, anyone can run apps again.

 

What could be happening? It is clearly seen that it is a permission issue, but I do not know how we can do to solve it, and for security reasons, do not give administrator permissions to all domain users in all VDAs.

 

Our version is Citrix Virtual Apps and Desktops 7 1912 LTSR CU2 and the VDAs are Windows Server 2019.

Recently we have not applied Windows updates, policies, changed permissions...

 

Thanks in advance.

Citrix_Error.PNG

Link to comment

12 answers to this question

Recommended Posts

  • 1

I was strugling with "The Group Policy Client service failed to sign-in. Access is denied" issue last 3 months. Today it is fifth day without this error.

 

What we did? Upgraded to 1912 CU6 and disabled GPO which is called "Set time limit for disconnected sessions". Unfortunatelly I don't know which of those two helped.

  • Like 1
Link to comment
  • 0

We're having the same problem but not with all users, just a couple. I'm finding that the user profiles on our VDAs were deleted, both the profile folders from c:\users and the registry. I can't think of anything which would produce this behavior. RSOP isn't showing anything funky, all the VDAs are in the same OU, all the users are in the same OU and groups, just nothing sensible.

Link to comment
  • 0

This has been occurring on all of our 2109 VDAs kind of randomly with no specific frequency (starting on 2103). Sometimes it'll happen to two users in a day, sometimes it won't happen for three weeks. Citrix's recommended fix is to reset the UPM profile, which you can only pursue by renaming the OS version folder of the UPM profile (the user is not logged in so you can't do it from director). I've sort of associated it to somewhere in the logoff process, a user's profile gets corrupted, but nothing in the log or Citrix Profile Management data will tell you why.

 

For what it's worth, we have user profiles set to delay deleting locally cached profiles on the VDA for 60 seconds. I've seen some people say this is a good thing to do for 2016 and 2019 servers, and I've seen people say it's a bad thing. Citrix doesn't say either way. I don't know if it is even associated with the root cause of the issue, it just never used to happen in our old LTSR environment when we had it set to 0. The Citrix support article is associated here:

 

https://support.citrix.com/article/CTX203201

 

Seems to be something that has happened forever, and they have had little to no solution for it other than resetting the profile. 

Link to comment
  • 0

We are working on this topic for a month with the Citrix and the Microsoft support without a final solution. In our case, we disabled the profile mgmt setting "Delete locally cached profiles on logoff" as a workaround. But this is not a permanent solution for us. Citrix and Microsoft said, that one service blocks a successful write back the profile become corrupt. But they still analyse the logs which service could be the reason for the problem. We do have the issues currently only on Windows Server 2019 machines with VAD 1912 LTSR CU3, CU2, CU1 which are hosted in AWS. Windows Server 2019 machines which are hosted onPremise are not affected although they have the same setup, settings and so on. We also tested some different delays in the setting "Delay before deleting cached profiles". The higher the Delay was configured, the fewer problems we had. But we have not found a delay where we do not get any problems. I keep you updated as soon as i have some more results from the support.

Link to comment
  • 0

Opened up a ticket with support on this issue and relayed some interesting information to them regarding their release notes for LTSR CU5. Granted we are running 2109 and Server 2016 VDAs , but as with all Citrix bugs, the key is to start poking around in unassociated documentation to your own release version to find a solution (hilariously).
 

This appears to be a bug fixed in LTSR CU5 with a non-public internal case note assigned to the bug. I got confirmation that his was indeed the case and this was fixed. I then asked support why they would push fixes to LTSR CU5 and not their current release platform, as their business model is pushing into that cloud based SaaS model. This netted me crickets, and then the suggestion to mix and match Profile Management for LTSR CU5 and my 2109 VDAs to which my response was naturally “what?” They assured me that this would work, but it’s still something I am not willing to pursue blindly and without a quality amount of testing.

 

The support engineer then let me know that this would be fixed on the current release channel in “future releases” with no date to be determined. 
 

For those of you on LTSR…an upgrade to CU5 might sort you out on this issue. Check the release notes on it, and let me know if you have success on getting it to go away. At this point, we are stuck in the mode of knowing how to resolve the issue quickly with the user, wanting the issue to go away, but also not wanting to cause a new string of issues by doing something that seems like reaching. 

Link to comment
  • 0
On 3/22/2022 at 11:38 PM, Bradd Schlosser said:

Opened up a ticket with support on this issue and relayed some interesting information to them regarding their release notes for LTSR CU5. Granted we are running 2109 and Server 2016 VDAs , but as with all Citrix bugs, the key is to start poking around in unassociated documentation to your own release version to find a solution (hilariously).
 

This appears to be a bug fixed in LTSR CU5 with a non-public internal case note assigned to the bug. I got confirmation that his was indeed the case and this was fixed. I then asked support why they would push fixes to LTSR CU5 and not their current release platform, as their business model is pushing into that cloud based SaaS model. This netted me crickets, and then the suggestion to mix and match Profile Management for LTSR CU5 and my 2109 VDAs to which my response was naturally “what?” They assured me that this would work, but it’s still something I am not willing to pursue blindly and without a quality amount of testing.

 

The support engineer then let me know that this would be fixed on the current release channel in “future releases” with no date to be determined. 
 

For those of you on LTSR…an upgrade to CU5 might sort you out on this issue. Check the release notes on it, and let me know if you have success on getting it to go away. At this point, we are stuck in the mode of knowing how to resolve the issue quickly with the user, wanting the issue to go away, but also not wanting to cause a new string of issues by doing something that seems like reaching. 

 

We are already running on 1912 LTSR CU (Windows 2019) but we have still this issue.
 

Link to comment
  • 0

Oh that's no good. Sounds like support was maybe just claimining the fix had been established in the last 1912 CU. Has anyone tracked down a solution for this otherwise? To update you guys on the logging and behaviors we've experienced, it seems to be just the corruption and failed recovery/backup of the user's NTUSER.dat file. I am finding that I experience like 3-5 profile corruptions and subsequent resets the week after Windows updates are applied to our VDA RDSH servers. Then it sort of goes quiet for 2 or 3 weeks and then they pop up again. Luckily we are only about 160 users strong, so this isn't extremely debilitating, but it's still an annoyance that I think everyone would prefer goes away. It's almost without fail that the pattern goes like this as well.

Link to comment
  • 0

My previous post was referring to supports recommendation for us to move to the profile management component for 1912 CU5 back in March as a potential fix to the issue we were having on version 2109 at the time. They were asking me to try that component with my 2109 VDAs, because Profile Management for CU5 had a fix for this error in the release notes. The previous poster mentioned he was still having the same issue on that 1912 LTSR CU5 version back in May. I just provided their recommendation based upon the fact that there were a number of LTSR folks in the thread here, and we were actively going through the same problem. This problem has been recurring for years based upon the initial behaviors referenced in the support article here:

 

https://support.citrix.com/article/CTX203201/logon-fails-with-error-group-policy-client-service-failed-at-logon-access-denied-when-user-launch-ica-session

 

Start date of the problem referenced in the article is 2015, but I've seen stuff referenced as far back as 2012. I don't entirely chalk the problem up to a Citrix problem at this point, because of how spread out it has been over the years on various releases. The only consistency with it has been that it is on RDSH servers with UPM enabled.

 

Hopefully that cleans up the timeline and information a little.

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...