Apr 14 2022 09:27 PM
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.
Apr 15 2022 06:32 AM
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...
Apr 15 2022 11:47 PM
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
Apr 17 2022 04:12 PM
Just checking if there's any progress or updates?
(please don't forget to mark helpful replies)
Apr 17 2022 11:04 PM
Apr 17 2022 11:05 PM
Apr 17 2022 11:33 PM
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.
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.
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
Apr 18 2022 01:44 AM
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.
Cheers,
Lain
Apr 18 2022 01:53 AM
Apr 18 2022 03:37 AM
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
Apr 18 2022 05:17 AM
Apr 18 2022 05:21 AM
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
Apr 20 2022 01:22 AM
Apr 20 2022 01:36 AM
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.
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
Apr 20 2022 02:17 AM
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
Apr 20 2022 09:23 PM
Apr 20 2022 09:25 PM - edited Apr 20 2022 09:28 PM
Here is the outcome:
May be it also worth mentioning that every view minutes there appears 5504 event mentioning different internal dynamic addresses
Apr 20 2022 09:34 PM
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
Apr 20 2022 10:07 PM
Please find:
\\sm.local\SysVol\sm.local\Policies\{D6735583-A7D1-4988-83C3-75D788D95E7B}\gpt.ini
Apr 20 2022 10:26 PM
Here's five PowerShell commands to run that will provide some useful information on the two halves that make up a group policy object:
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