So,

We have 2 domain controllers.

1 in the UK, 1 in India.

I’ve created a WSUS policy for the UK and attached to the UK computer OU - Works perfectly.

I created a WSUS policy for India and attached to the India computer OU - same settings but getting this when trying to gpupdate /force from an India workstation;

The processing of Group Policy failed. Windows attempted to read the file \[DOMAIN NAME]\Policies{EA6EE080-AA12-45B3-A851-9E59F54299F3}\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.

I have tried;

Removing the settings from the GPO - gpupdate came back with no errors but the policy wasn’t applied in gpresult (probably because it didn’t do anything).

Deleting and creating the GPO again.

The sysvol folders on both DCs seem to be replicating. Same date modified/size/GUID of folders and subfolders.

Restarted the servers and been testing over and over and over.

Please help before I suffer from a GPO induced meltdown.

Thanks

12 Spice ups

Check the output of on you DCs to verify that replication is operating properly:

dcdiag /c /v 
repadmin /replsum

just in case.

2 Spice ups

Does the GPO appear on the Indian DC? If so are all the settings in there correctly?

If not it may not have replicated yet (if at all) and it may be worth recreating the GPO on the India DC itself and applying from there

Is the folder {EA6EE080-AA12-45B3-A851-9E59F54299F3} viewable and accessible from the India DC? IF not you could have permissions issues that are stopping the read. It could be the DC as a whole or just the India OU that’s not inheriting the permissions from the forest

Check the Security Context for the GPO

This got alot stricter with the June2016 updates…

1 Spice up

Hi M Boyle,

Right you are onto something (although I don’t know whether it’s related at present).

In short our main DC was replaced before I arrived and I’m finding lots of reference to it everywhere (I’ve removed all GPO’s relating to it).

However dcdiag /c /v is reporting lots of ‘CANNOT FIND SERVER X’ results, because it doesn’t exist.

When I’ve tried to remove it from AD before,

spice.PNG

Unfortunately this server is long gone. I guess the first thing to do would be to remove this.

Any ideas how to do this in a clean way?

Also I don’t really know what I’m looking for in the results here. Is there anyway to export this to a text file so I can break it down a little?

Hi Alex,
Yes it appears in the Indian DC and the settings are there correctly.
I can try creating it on the Indian DC first if you think it will help?
The folder is there with the same date stamps and everything so we know it’s been created.
In regards to permissions, this is where I get a bit puzzled.
Do the permissions need to be on the ‘policies’ folder in SYSVOL or the OU itself? Do you know what account actually runs the gpupdate?

David

If you’ve got an orphaned DC then you’ll need to clean up the metadata for this DC…

2 Spice ups

Hi Martin,

I’ve just had a read through this and ‘authenticated users’ still have ‘read’ access and ‘apply to GP’ selected for the policy.

I’ll have another read through it later on.

Thanks for the response. I’ll let you know how I get on with the other suggestions in the article.

Thanks

Thanks again Martin.

I’ll run through these to get the redundant server removed first.

I have a feeling this may be causing a lot more issues than I initially thought.

Just an update all, it’s fixed.

Removed the DC controller that was no longer needed. And Voila!

ws3.PNG

Obviously a synchronisation error.

I don’t know what to mark as the answer. M Boyle’s suggestion for running dcdiag or Martin’s help on removing the DC?

Thanks again. This is a fantastic community.

You can give me a helpful answer if you’d like. Martin actually followed up properly :slight_smile:

The 2 checks that I mentioned, they might be something to add to your maintenance procedures. Say run them every month to verify that things are still happy in AD land.

Brilliant. Will do. I never knew about them and they are powerful commands.

I will definitely include them in my monthly checks now.