Mark Minasi's Tech Forum
Register Calendar Latest Topics Chat
 
 
 


Reply
  Author   Comment  
jshapiro

Still Checking the Forum Out
Registered:
Posts: 9
Reply with quote  #1 
My Windows 10 computer has developed a problem in the last few months where it won't update group policy.  The error is as follows:

The processing of Group Policy failed. Windows attempted to read the file \\domain.local\SysVol\domain.local\Policies\{25161F17-B18F-478B-9434-B2C9371B1986}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:
a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.
User Policy update has completed successfully.

To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.


Initially, I thought it was a corrupt policy.  It is not that.  I thought the machine might not be able to reach a DC.  It isn't that.  I also checked out DC replication and other server-side issues, but there doesn't seem to be a problem.  Other machines are processing GP just fine.

I would love to get this resolved without having to blow away my computer.  Any suggestions?
0
wobble_wobble

Avatar / Picture

Associate Troublemaker Apprentice
Registered:
Posts: 741
Reply with quote  #2 
Yup....

Been there, done that.

Check here - https://community.spiceworks.com/topic/1119601-windows-10-group-policy-issue

Also check here - https://support.microsoft.com/en-us/kb/310568

HTHs

__________________
Have you tried turning it off and walking away? The next person can fix it!

New to the forum? Read this
0
jshapiro

Still Checking the Forum Out
Registered:
Posts: 9
Reply with quote  #3 
Thanks for the suggestions, but nothing has worked.  This problem is strictly my own computer and not a server issue.  No other Windows 10 system is exhibiting this behavior.  Most recently, I tried a repair install of Windows 10.  No help.  I even rolled the computer back to an earlier image backup.  Didn't help.


0
wkasdo

Avatar / Picture

Administrator
Registered:
Posts: 179
Reply with quote  #4 
Did you check the GPO Event Log?

If that gave you nothing, a procmon trace of a gpupdate is a nice one to try.

__________________
[MSFT]; Blog: https://blogs.technet.microsoft.com/389thoughts/
0
wobble_wobble

Avatar / Picture

Associate Troublemaker Apprentice
Registered:
Posts: 741
Reply with quote  #5 
Willem
What would you filter with on procmon?

__________________
Have you tried turning it off and walking away? The next person can fix it!

New to the forum? Read this
0
jshapiro

Still Checking the Forum Out
Registered:
Posts: 9
Reply with quote  #6 
I just tried procmon, and I filtered on gpupdate.exe in the path.  I got lots of lines to review, but it isn't yielding anything that is meaningful to me.
0
wkasdo

Avatar / Picture

Administrator
Registered:
Posts: 179
Reply with quote  #7 
you need to look broader. Check for file access to SYSVOL, see what process (PID) is doing it, and investigate from that point on.
__________________
[MSFT]; Blog: https://blogs.technet.microsoft.com/389thoughts/
0
jshapiro

Still Checking the Forum Out
Registered:
Posts: 9
Reply with quote  #8 
That was a good tip to search for sysvol.  First of several similar entries looks like this:

Process Name:  svchost.exe
Operation:  CreateFile
Path:  \\[domain.local]\SysVol\[domain.local]\Policies\[POLICY GUID]\gpt.ini
Result:  LOGON FAILURE
Detail:  Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, AllocationSize: n/a, Impersonating: NT AUTHORITY\SYSTEM

This implies that it can't reach the path, but I can always reach the path just find in File Explorer.  

Of course, the process is trying to access the policies using NT AUTHORITY\SYSTEM and not my credentials.  Is it possible, that SYSTEM is not authenticating?  I double-checked the permissions, and authenticated users have READ, so in theory, everyone should be able to access the policies area on the server.




0
jshapiro

Still Checking the Forum Out
Registered:
Posts: 9
Reply with quote  #9 
As an experiment, I created a scheduled task on my machine that runs in the SYSTEM context.  The task runs a batch file on my PC.  The batch file attempts to access the Sysvol folder and direct the results to a log file.  I get nothing in that file when I run the task.  Of course when I run the batch directly it in my context, I do get a result.  

So now we know it is some kind of authentication issue tied to the SYSTEM account.  System is not getting access to SYSVOL.  The question is why and what should I do about it?  I know there were some articles that early builds of Win10 had trouble reaching NETLOGON and SYSVOL.  Articles suggested disabling hardened authentication with statements added to the registry such as this:

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\SYSVOL" /d "RequireMutualAuthentication=0" /t REG_SZ

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\NETLOGON" /d "RequireMutualAuthentication=0" /t REG_SZ

I tried these, and it didn't seem to work.

0
jshapiro

Still Checking the Forum Out
Registered:
Posts: 9
Reply with quote  #10 
I did more testing and learned a bit more....

From my normal user command prompt:

dir \\domain.local\sysvol returns something
dir \\domain.local\netlogon returns something

From a system command prompt:

[I was able to get a SYSTEM command prompt using psexec to come back to my machine using the /S switch.]

dir \\domain.local\sysvol returns "The user name or password is incorrect."
dir \\domain.local\netlogon returns "The user name or password is incorrect."

Curiously, I altered the above two tests leaving out the .local in the domain name:

dir \\domain\sysvol returns something.
dir \\domain\netlogon returns something.

So for some reason, the SYSTEM account can't work with \\domain.local.  This of course impacts group policy processing.

0
jshapiro

Still Checking the Forum Out
Registered:
Posts: 9
Reply with quote  #11 
I have cured my problem in a most curious way.

Again from an NT AUTHORITY\SYSTEM command prompt the following didn't work:

dir \\domain.local\sysvol  [throws an error about unknown user or bad password]

however:

dir \\domain\sysvol succeeds in returning something.
dir \\dc-IP address\sysvol succeeds in returning something.

If I ping'd domain.local it would return the DC IP address.

I got the idea to try the following:

from my NT AUTHORITY\SYSTEM command prompt:

net use \\domain.local\sysvol 

I then supplied my domain credentials.

This succeeded.  Then I repeated the above tests, and all worked fine.  I then did a GPUPDATE, and it succeeded too!

I rebooted my computer several times now, and GP continues processing.  It seems that the system account is permanently authenticated now.  

That this works makes sense, but I didn't expect the fix (workaround???) to survive a restart.

The lingering question is why was this even necessary to begin with?  During all my troubleshooting, I disjoined and rejoined the machine to the domain multiple times.  It shouldn't have been a trust issue.

0
Previous Topic | Next Topic
Print
Reply

Quick Navigation: