WVD logon issues. The Group Policy Client Service failed the sign-in. Access is denied.

Copper Contributor

Hi. We have a mutli-session Win10 WVD farm up and running. We are running 1909 with the latest quality updates applied. FSLogix profile container is being used. 


We are seeing intermittent issues with users not being able to login. They are being presented with the error:


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




From investigation, cant see anything appropriate in the event logs. Anyone seen this issue before?



58 Replies
We installed the preview in our production environment and have not had the issue come up again. We have about 50 users across 3 pools and around 15 hosts. The Preview version is 2.9.8048, not 2.9.7979.
Will this resolved permanently once and after installation of latest version (FSLogix) ?
It has resolved it for us so far. We have not seen the error come up since. Please note that you need the preview version of FSLogix, not the latest production version.
Since this preview was January, I know there's a subsequent issue with it, and it's now March can we have an update please? I have a few affected users who log on when I'm not working, due to time zones and me being the only IT person in the business. I can't have them not working until I get back to work, imagine if I was on leave for a week.

@Lee_E Hello. Sorry for the issue you are experiencing. We released a fix for the public preview a few weeks ago please check :FSLogix 2201 Public Preview Update 1 is now available - Microsoft Tech Community 

That issue has restarted our QA process. Unfortunately we cannot commit to a date until it meets our quality bar. I'll keep you all posted here. Sorry for the inconveniences that this is causing.


I've set up a 5 minute scheduled task that runs a script (below).  It's not pretty and if someone logs off and back on in less than 5 minutes it may still error until the 5 minute point but it works for us. We can run this with minimal complications until a production ready version is released.  Hope this helps a few of you.

$profilesKey = "HKLM:SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileService\References\"
$userProfiles = Get-ChildItem -Path $profilesKey
ForEach ($userProfile in $userProfiles) { 
    $RefCountProperty = Get-ItemPropertyValue -Path "Registry::$userProfile" -Name "RefCount"
    If ($RefCountProperty[0] -eq 1) {
        $RefCountProperty[0] = 0
        Set-ItemProperty -Path "Registry::$userProfile" -Name "RefCount" -Value $RefCountProperty 




Hi Michael, we are seeing this issue with the latest FSLogix version running on Server 2022.  If I set the Refcount key to 0 then the affected person can log in again.

same for us "access denied" for users (less then before but still happening)... with AVD and Windows 10 Enterprise multi-session (mostly when 2 or more sessions hosts are in a AVD-ppol)
I installed fslogix 2201 hotfix 1 but we still have this issue.
We are using profile and office container in a RDS environment.
We notice the problem when the server does an unexpected reboot and with user logged on.
With Lab I noticed that this issue appear only when office 365 Is installed, without it there is no issues.
If I delete the "user" folder the user can log in. If can help under the user folder there is ntuser.dat file (without Office 365, the folder is empty).

Still, we are facing this issue for some of the users.

Any solution?

Life saver, I had this issue when not even using fslogix but was on an Azure AD joined AVD, deleting the user from the "Reference" folder fixed it, Thanks

@Guido - in my case user is getting same Group policy error but Ref count is already 00000 . Let me know how can we fix this


In regedit HKLM:SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileService\References\ have you tried deleting the user effected s-15-21 folder completely as this resolved the issue for me.
Got it also yesterday, rebooting the host fixed the issue

I was able to predict the problem happening with this script.  I checked the non-zero usernames against who was logged in with the 'quser' command.  Code formatting doesn't work?


# profilecheck.ps1

function sid2user {
  $SID = New-Object System.Security.Principal.SecurityIdentifier($id)
  $objUser = $SID.Translate([System.Security.Principal.NTAccount])

get-itemproperty HKLM:\SOFTWARE\Microsoft\Windows` NT\CurrentVersion\ProfileService\References\* refcount |
select @{n='Sid';e={$_.pschildname}},@{n='User';e={sid2user $_.pschildname}},@{n='Refcount';e={$_.refcount[0]}}


# example:

.\profilecheck.ps1 | ? refcount


Sid User Refcount
--- ---- --------
S-2-4-11-3423303271-1025932689-3187700767-574700 jszabo_98 1


I successfully predicted this happening by looking for users with a non-zero refcount, and seeing if they were actually logged in.  I tried to post some powershell, but I don't see it yet.

I'm hopeful that upgrading from "FSLogix 2201 hotfix 1 (2.9.8171.14983)" to "FSLogix 2210 (2.9.8361.52326)" resolves the issue for me.


In particular, this bug fix note for hotfix 2 (2.9.8228.50276) sounds promising:


"Resolved an issue during profile cleanup where user registry hives would be removed regardless of the FSLogix local group exclusions."


In my case, the affected user is a member of an AD group that is in turn a member of  the local "FSLogix Profile Exclude List" group. So, it makes sense that fslogix is interfering with the user's hive despite being a member of that exclusion group - because of that bug.