Forum Discussion
GPO processing fails
Hello everyone,
I have recently figured out that gpupdate /force command on any machine leads to an error
Event Viewer shows up 1058 error messages related to gpt.ini access
Previously we had 2 DCs but later one was demoted and completely excluded from the network Most likely these errors are the consequences of those improper actions.
Most likely these errors are the consequences of those improper actions.
Not sure what is meant but you can check for and clean up remnants if needed.
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup
https://techcommunity.microsoft.com/t5/itops-talk-blog/step-by-step-manually-removing-a-domain-controller-server/ba-p/280564- Thanks for your prompt reply. The server where the issue happens is actually the one which remained as a DC. and not the one which was demoted. So don't think that metadata remnants need to be cleaned out here
The following command can be used to check the consistency of your DFS namespace (not to be confused with the supporting DFS replication group.)
You will need to run this as a domain administrator.
dfsdiag /testdcsCheers,
Lain
Okay, thanks for that.
I'm not actually sure what to make of those results as I'm not familiar with only having a single domain controller in an environment.
It looks like it has actually skipped performing any actual tests, but maybe dfsdiag does that in single domain controller environments - I don't know. If I get time, I'll try spinning up a single domain controller forest and check (for my own benefit, too.)
What it should have looked like is the following, where you can see the test results showing up as the cyan lines. But of course, this is from my own business where I have two domain controllers, hence my uncertainty.
Sample dfsdiag output.
Since your screenshot has no lines in cyan, I'm guessing it didn't run any tests.
What I'm trying to figure out is whether or not you have any references to old domain controllers within your SYSVOL DFS namespace configuration.
There's multiple ways of cross-referencing that, but the first one (dfsdiag) suggests there aren't any.
Can you have a look within Event Viewer again - under the same "GroupPolicy" node as your original screenshot from your original post - and see if there's an information event with an ID of 5308 around the same time as your original screenshot?
Event 5308 should be there and it will tell you the DNS name of the domain controller it attempted to process group policy from. It will have almost the same timestamp as your error from above.
It will look something like this.
GroupPolicy Event 5308.
If the reference is to your single remaining domain controller then this is getting interesting. It may be that the client does not have READ permissions but the Event Viewer error reads more like a connectivity issue, which is what I'm still focusing on for the time being.
If it's a reference to a long-gone domain controller, then this explains your original error, and what happens afterwards is that you need to remove any remaining references to it (in areas such as DNS, for example.)
Cheers,
Lain
Just checking if there's any progress or updates?
(please don't forget to mark helpful replies)
