GPO processing fails

Contributor

Hello everyone,

 

I have recently figured out that gpupdate /force command on any machine leads to an error

nikitamobile855_0-1649996660090.png

Event Viewer shows up 1058 error messages related to gpt.ini access

nikitamobile855_1-1649996716900.png

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. 

 

 

 

21 Replies

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-contr...

 

 

 

@nikitamobile855 

 

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 /testdcs

 

Cheers,

Lain

Just checking if there's any progress or updates?

 

(please don't forget to mark helpful replies)

 

 

 

 

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

@LainRobertson 

 

Thanks for your reply! Here is the outcome of the command execution.

 

nikitamobile855_0-1650261912704.png

 

@nikitamobile855 

 

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.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.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

@nikitamobile855

 

I've spun up a new forest with a single domain controller and it reflects my previous results (above) for the "dfsdiag" command.

 

Each testing phase is actioned and a status provided in the cyan-coloured lines, the same as my previous test.

 

At this stage, something looks really wrong with your DFS namespace configuration within that sm.local domain/forest.

 

dfsdiag running against a forest with a single domain controller.dfsdiag running against a forest with a single domain controller.

 

Cheers,
Lain

@LainRobertson 

 

Yes definitely something wrong with DFS cause I'm getting errors from DFS as well

 

nikitamobile855_0-1650272032413.png

 

@nikitamobile855 

 

Yes, I believe, I've replied to that issue in the separate thread created for it.

 

Keep in mind DFS-R (replication) and DFS-N (namespaces) are separate processes.

 

The other thread is definitely about DFS-R. I'm not sure where this thread fits yet but it sounds more like DFS-N, based on the error from the original post.

 

Did you find any event ID 5308 records in the GroupPolicy node in Event Viewer?

 

Cheers,

Lain

@LainRobertson 

 

I have checked but I'm not getting any 5308 errors..

 

nikitamobile855_0-1650284223081.png

 

@nikitamobile855 

 

Event ID 5308 isn't an error, it's an information event in the "Applications and Services Logs/Microsoft/Windows/GroupPolicy/Operational" node.

 

I dropped a screenshot two replies up that shows an example of one from my environment.

 

It'd be highly unusual to not find a 5308 information event.

 

Cheers,

Lain

@LainRobertson 

 

I have found events with 5308 ID. Pls see the screenshot below

 

nikitamobile855_0-1650442928622.png

 

@nikitamobile855 

 

Okay, that's great news and really helpful.

 

The one you've found seems to be a few days recent than your error, which was from the 15th. Are you able to find one from the same timestamp as an error?

 

It doesn't have to be from the 15th. If you have more recent errors, that's fine, just have a look and see if you can find the matching event 5308.

 

If you know how to "filter" the "GroupPolicy/Operational" node, then it will be easier for you to find a matching pair if you filter on events 1058 and 5308 as shown below.

 

gp-events-1058-5308.png

 

If the server is still showing up as uztassrv01.sm.local then it may not be name-related - we're just checking the basics at the moment.

 

If we find it's not related to names then we can shift our focus over to the actual files, and check things like permissions and even that the files themselves do actually exist (GPO's definitely going to fail if the files don't exist!)

 

Cheers,

Lain

@nikitamobile855

 

Also, since UZTASSVR02 keeps popping up, it might pay to find and delete any orphaned DNS records - particularly those that play an important role in service discovery.

 

Here's three commands that will help you find any orphaned DNS records belonging to UZTASSVR02:

 

# Look for orphaned service locator records.
Get-DnsServerResourceRecord -ComputerName uztassrv01.sm.local -ZoneName _msdcs.sm.local -RRType SRV | Where-Object { $_.RecordData.DomainName -like "uztassrv02*" }

# Look for orphaned AD replication locator records.
Get-DnsServerResourceRecord -ComputerName uztassrv01.sm.local -ZoneName _msdcs.sm.local -RRType CNAME | Where-Object { $_.RecordData.HostNameAlias -like "uztassrv02*" }

# Look for orphaned name server records.
Get-DnsServerResourceRecord -ComputerName uztassrv01.sm.local -ZoneName sm.local -RRType NS | Where-Object { $_.RecordData.NameServer -like "uztassrv02*" }

 

Cheers,

Lain

@LainRobertson 

 

Here are the 2 events happened today simultaneously 

 

nikitamobile855_0-1650514997263.png

nikitamobile855_1-1650515041241.png

 

@LainRobertson 

 

Here is the outcome:

nikitamobile855_0-1650515155648.png

May be it also worth mentioning that every view minutes there appears 5504 event mentioning different internal dynamic addresses

 

nikitamobile855_0-1650515270885.png

 

 

 

@nikitamobile855 

 

Okay, great. Since event 5308 is referring to uztassrv01.sm.local, we'll shift away from names and onto content.

 

Can I ask you to copy-and-paste the UNC text from the details in event 1058 in here? I'm old and typing out GUIDs just results in me making lots of mistakes.

 

What I'm talking about is the text starting with "\\sm.local" and ending with "gpt.ini"

 

Having the text will make it easier for me to provide you with useful PowerShell commands to run.

 

Cheers,

Lain

@LainRobertson 

 

Please find:

\\sm.local\SysVol\sm.local\Policies\{D6735583-A7D1-4988-83C3-75D788D95E7B}\gpt.ini

@nikitamobile855 

 

Here's five PowerShell commands to run that will provide some useful information on the two halves that make up a group policy object:

 

  1. The files on the SYSVOL area of the file system (lines 1 and 2); and
  2. The data from the Active Directory GPO object (lines 4 to 6).

 

Get-Content -Raw -Path "\\sm.local\SysVol\sm.local\Policies\{D6735583-A7D1-4988-83C3-75D788D95E7B}\gpt.ini";
(Get-Acl -Path "\\sm.local\SysVol\sm.local\Policies\{D6735583-A7D1-4988-83C3-75D788D95E7B}\gpt.ini").Access | fl AccessControlType, IdentityReference, FileSystemRights;

$gpo = Get-ADObject -Filter { (objectClass -like "*") -and (cn -eq "{D6735583-A7D1-4988-83C3-75D788D95E7B}") } -SearchBase "CN=Policies,CN=System,DC=sm,DC=local" -SearchScope OneLevel -Properties *;
$gpo | Select-Object objectGUID, objectClass, cn, displayName, gPCFunctionalityVersion, versionNumber, gPCFileSysPath;
$gpo.nTSecurityDescriptor.Access | fl AccessControlType, IdentityReference, ActiveDirectoryRights;

 

If you get any errors such as "file not found" or "access denied" while running these commands, be sure to let me know as that may be quite relevant.

 

Cheers,

Lain