Event ID 1058: Windows cannot access gpt.ini for a Group Policy object

Fix it now

Microsoft publishes 1058 as “Windows attempted to read the file from a domain controller and was not successful”, and names three causes: name resolution or network connectivity to the current domain controller, replication latency, and the DFS client having been disabled. The settings inside the policy are almost never the problem; the path to SYSVOL is.

gpupdate /force
dcdiag /test:NetLogons
dcdiag /test:SysVolCheck

1. Read the 1058 entry and note the policy identifier and the exact path it tried, then open that path from the failing machine. Whatever error you get there is the real one.
2. Try a named domain controller as well as the domain-based path. If \\dc02\SYSVOL\... works and \\corp.example.com\SYSVOL\... does not, the fault is the referral rather than the file.
3. Check the DFS client on the machine. Microsoft names a disabled DFS client as one of the three documented causes, and it is the one nothing else in this list will reveal.
4. On the domain controller, run dcdiag /test:NetLogons, which Microsoft describes as validating that the shares can be connected to and read without security errors.

dcdiag /test:SysVolCheck reads a registry value and, in Microsoft’s own words, does not check whether the SYSVOL and NETLOGON shares are accessible. Use NetLogons for that question.

If the path opens and gpupdate completes cleanly, you are done. If not, the next section explains why the domain name is not a server.

Why it happens

The path \\corp.example.com\SYSVOL looks like a share on a server of that name, and no such server exists. It is a domain-based namespace. The client asks a domain controller for a referral, receives a list of the domain controllers hosting SYSVOL, and connects to one. Reading one small text file therefore depends on the DFS client on the machine, the referral it is given, SMB to whichever domain controller it picked, and the share and file permissions there.

Microsoft’s published cause list for 1058 matches that chain exactly. It names name resolution or network connectivity to the current domain controller; replication latency, where a file created on one domain controller has not reached the one the client is talking to; and the DFS client having been disabled. Two of those are about which domain controller the client reached, and one is about whether the client can follow a referral at all.

That explains the shape of the problem. 1058 frequently affects one site, or one subnet, or appears intermittently as clients are referred to different domain controllers. It also explains why opening the policy happily in the management console proves nothing, because your own workstation followed its own referral, probably to a different server.

Event 1030 is the same failure one step earlier: Microsoft publishes it as Windows having attempted to retrieve new Group Policy settings for this user or computer, with the detail in the event’s own Details tab, and notes that domain-joined computers need proper name resolution and network connectivity to a domain controller for policy discovery. The other two events in this family – 1096 and 1055 – are not published by Microsoft, so read them for what they carry rather than for what their numbers are said to mean.

Full reference

The events in this family

Testing the path properly

1. Open the exact path from the 1058 entry on the failing machine, not from your own.
2. Open the same policy folder through a named domain controller. A difference between the two isolates the referral from the file.
3. Repeat from a second machine in the same site, then from one in a different site. 1058 that follows a site is a domain controller problem; 1058 that follows a machine is usually the client.
4. On the domain controller the client used, run dcdiag /test:NetLogons and read what it says about share access.
5. Only then start looking at replication.

Tools and what they actually answer

dfsutil is where the client-side referral information lives, and the parameter Microsoft documents for it is cache. Older material uses switches that are not in the current reference; if a command you have been given is rejected, that is why.

When the policy folder is genuinely missing

Occasionally the identifier in the event does not exist under the Policies folder on any domain controller, and the policy shows as inaccessible in the management console. That is an orphan: an object in the directory with no folder behind it, usually left by an edit made while SYSVOL replication was broken. Restoring a policy backup recreates the folder with the same identifier and is the clean fix. Without a backup, delete the orphaned object, build a replacement and link it, and then find out why the folder went missing, because the same conditions will orphan the next one.

What not to do

• Do not edit the version number in the file by hand. It is maintained by the management tools and compared against a matching attribute on the policy object; editing one half desynchronises the two.
• Do not delete and recreate the policy because the path is unreachable. A new policy lives at the same unreachable path.
• Do not conclude from a passing SysVolCheck that the share is readable. Microsoft says explicitly that the test does not check share access.
• Do not assume the console proves anything. Your workstation followed its own referral to its own domain controller.

Reading the operational log instead of guessing

The Group Policy operational log records the start and end of each processing cycle with timings, which is how you tell a policy that failed from a policy that was never in scope. A cycle that starts and fails at the point of reading a policy file is this article’s problem. A cycle that completes without ever mentioning the policy you expected is a filtering problem and belongs elsewhere. The distinction takes a minute to establish and saves an afternoon of checking permissions on something that was never being applied.

Every code this article covers

Confirm the fix worked

1. The exact path from the 1058 entry opens from the affected machine using the domain-based namespace, not only through a named domain controller.
2. gpupdate /force completes with no new 1058 entries.
3. dcdiag /test:NetLogons succeeds on the domain controller the client used.
4. A second machine in the same site applies the same policy.
5. The settings the policy carries are actually in effect, rather than the policy merely being listed.

Questions people ask about this