Hi everyone,
I'm getting the following error when I'm trying a Group Policy update ( gpupdate /force) in a newly domain joined Windows 10 computer
-- This doesn't happen with all the Windows 10 PCs of the domain. Only like 2-3 computers so far.
-- The Windows build in the affected PC is 21H2.
Can Ping and reach the domain controller. The SYSVOL folder can be reached when browsed via Explorer.
I have tried
-- ipconfig /flushdns , reboot, trying the gpupdate
-- Removing the computer account from the AD, rejoining the PC to the domain and running a gpupdate
Can anyone please help me with this ?
Thank in advance! Any help is really appreciated. Let me know if you need more details.
Hi,
Unfortunately, the error itself is pretty vague (as most are.) Here's some additional commands you can run to get more information related to discovering and using DFS namespaces (DFS-N, as distinct from DFS replication groups, DFS-R.)
Event Viewer
The first port of call would be the GroupPolicy node inside Event Viewer on the impacted client. You can find it under Applications and Services Logs/Microsoft/Windows/GroupPolicy/Operational.
It can be a very busy log with individual policy refreshes generating dozens if not hundreds of rows, so I'm recommend:
- Clearing the Operational log;
- Run the gpupdate /force command to generate some new entries;
- Checking the log for any errors, as well as event some of the early "information" events such as 5308 that tell you which domain controller was used for this refresh.
It's also good to check the System event log for any errors or warnings, particularly from sources like Netlogon and Schannel.
Dfsutil
You can also use dfsutil.exe to inspect the DFS-N client's current state.
If you run "dfsutil /pktinfo" straight after your gpupdate then you'll be able to see to which server the DFS client connected for the SYSVOL content. In reality, it should mirror what you found out from above via event 5308, but it doesn't hurt to know your options.
Here's an example of what you'd expect to see.
Checking you can read the file
Straight after you get the error from gpupdate, you should see if you're able to read the file (gpt.ini in this case), as if there's issues with DFS-R, the file might exist on some domain controllers but not others.
You an copy-and-paste the file path straight out of the error text returned by gpupdate and use one of the following commands (depending on where you launched gpupdate from) to see if you can read the contents:
From the command prompt shell
type "\\yourdomain.com\sysvol\yourdomain.com\Policies\guid\gpt.ini"
From PowerShell
Get-Content -Path "\\yourdomain.com\sysvol\yourdomain.com\Policies\guid\gpt.ini"
(Reminder: the value for Path should come from your error, not this example)
If you can't read the file then that's a red flag. If you can read the file, that's positive but doesn't rule out that it may not exist on all domain controllers.
Check which site your client belongs to
This PowerShell command will provide the site the client belongs to as well as the domain controllers it considers relevant to that site. This is a handy way to quickly check if you're pulling content from local domain controllers or possibly getting a random list, which can happen where the sites and subnets aren't properly defined.
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite() | fl Servers, InterSiteTopologyGenerator;
ipconfig /all
It's hard to go past good old "ipconfig /all" when troubleshooting.
This is useful - on domain controllers and clients alike - when checking if DNS is part of the problem.
If you're able to gather any of this information and share it here, that might help us work towards the cause.
Cheers,
Lain