Hi,

For some reason all of the domain joined computers will not apply group policy.

I have tried gpupdate /force on standard and admin account with the follwing error.


Updating policy…

Computer policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows attempted to read the file \###.local\SysVol###.local\Policies{C7599716-C7FB-424D-8D30-2ECF2796D10D}\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.

I have no idea what to do. This is happening on all machines… the only big change I can thing of is when exchange was updated to a new service pack and the server crashed half way through.

For the moment I set some policies for all users like adding a desktop Icon, change the wallpaper and disable C drive access.

3 Spice ups

Hi Reece,

What client OS is this affecting? There is a problem with UNC hardening in Windows 10 that can cause this issue. Other OS’s are affected as far as I’m aware although who knows what MS has patched recently

Also can you get to the file that is being referenced? Does it exist on all your DC’s SYSVOL shares and does it open?

Cheers

Darren

1 Spice up

Its from server 2008, the clients are a mix of windows 7 and windows 10.

You can access the files if you have not done GPupdate.

As soon as you run gpupdate the domain.lcoal\sysvol is password protected, the full address does not exist apparently.

On the server going to

C:\Windows\sysvol\sysvol\cvofires.local\Policies shows the policies which are openable.

ok but you should be able to reach the sysvol share from any machine/user, so that sounds a bit odd.

\###.local\SysVol###.local\Policies{C7599716-C7FB-424D-8D30-2ECF2796D10D}\gpt.ini

Typing that path in fails?

But if you go to a DC and open file explorer you can get to the

C:\Windows\sysvol\sysvol\cvofires.local\Policies{C7599716-C7FB-424D-8D30-2ECF2796D10D}\gpt.ini

without issue?

Sounds like someone might have messed with the NTFS security permissions on the SYSVOL share

1 Spice up

Yeah, its only accessible directly and not on the network.

These are the security properties for sysvol. Do you think I need to add something to it?

what permissions does authenticated users have? It should have Read & Execute, List folder Contents, and Read

If you open GPMC click on a policy and open the delegations tab does it give you an error about the permissions be incorrect?

1 Spice up

Yep, all 3 for authenticated users.

No errors on delegation on any of the group policies.

Is it the same for all of your domain controllers?

so rather than

\domain.com\sysvol\blah blah

which could go to any DC, can you type

\domaincontroller.domain.com\sysvol\blah blah

for each of your DC’s do they all fail? When it fails whats the error message you get, “access denied” or something else?

1 Spice up

there is only 1 DC which is server1.

yes on a domain machine going to: \server1.cvofires.local\SYSVOL shows the policies folder.

So is there a way to get group policy to look just to server1 as shown in screenshot it just looks for domain name.

ok so that’s interesting that going directly to the server share works. Group policy will always use the domain name in the share because if you have more than one DC (it’s a good idea to do this) it will be fault tolerant (and also AD site aware)

You didn’t tell me what the error was when you try to get to the UNC path with the domain, is it path not found? I say this because i’m now thinking it might be a DNS issue. If you ping domain.com does it resolve the IP of the DC or another IP or no IP at all?

1 Spice up

\cvofires.local\SysVol opens an explorer windows that says access denied and wants user credentials.

Every user credential i try says access denied,

basic user, built in, network admin, admin, all get access denied.

\server1.cvofires.local\SysVol Straight in, no problem.

“ping cvofires.local” replies with server 1’s IP

ok so its definitely permissions related, can you check the Share Permissions (rather than the NTFS permissions) for SYSVOL on server1? Everyone should have Read, Authenticated Users should have Full and Administrators should have Full

I’m guessing this should be fine, as the server share works, which then leads me to comment I made about UNC Path hardening

http://serverfault.com/questions/725087/windows-10-group-policy-fails-to-apply-directly-after-boot-succeeds-later

and here

In this second link it talks about the registry keys that are affected so it might be worth checking a failing clients registry and also the DC to see if they are in alignment

if you want to disable UNC Path Hardening on the SYSVOL and NETLOGON shares you can run the powershell lines below on the affected workstations

New-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths" -Name "\\*\SYSVOL" -Value "RequireMutualAuthentication=0" -Property "String"
New-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths" -Name "\\*\NETLOGON" -Value "RequireMutualAuthentication=0" -Property "String"
1 Spice up

Just noticed today I couldnt get windows deployment to work either.

It seems even though exchange is gone there are still a lot of leftovers which looks like they are causing problems.

Deployment wont start because an exchange account group is missing… and checking things like best practice analyzer tells me exchange has a lot of problems (Like being uninstalled).