Getting an error when trying a Group Policy Update

PM006 

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:

1. Clearing the Operational log;
2. Run the gpupdate /force command to generate some new entries;
3. 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.

Finding the GroupPolicy event log.

Example of event 5308 showing the domain controller used during the policy 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.

Example output from "dfsutil /pktinfo".

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