# Event ID 1058: Group Policy Failed to Read gpt.ini (Fix) Source: https://srvscripts.com/guides/event-id-1058-group-policy/ Updated: 2026-10-07 Publisher: srvScripts (https://srvscripts.com/) **Short answer:** Event ID 1058 means the computer could not read a GPO’s `gpt.ini` file from SYSVOL on the domain controller it picked. Find the path and DC in the event, then test that exact path with `Test-Path` as the failing user or computer. A missing file points to SYSVOL replication (check DFSR backlog); “network path not found” points to DNS, DC location or the DFS client; “Access is denied” points to GPO permissions, Kerberos or hardened UNC path settings. Fix that cause, run `gpupdate /force`, and confirm with `gpresult` that the event stops. Commands checked against the official documentation (linked below) on 7 October 2026; not yet run on our lab servers. ## The exact Event 1058 error text Event 1058 is logged in the **System** log with source GroupPolicy. The message reads: ``` The processing of Group Policy failed. Windows attempted to read the file \\contoso.local\SysVol\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following: a) Name Resolution/Network Connectivity to the current domain controller. b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller). c) The Distributed File System (DFS) client has been disabled. ``` The GUID differs per GPO (the one above is the Default Domain Policy). The event’s Details tab also shows an error code and description, and the GroupPolicy Operational log names the domain controller used. Pull recent events with: ``` Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-GroupPolicy'; Id=1058} -MaxEvents 5 | Format-List TimeCreated, Message Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -MaxEvents 50 | Where-Object LevelDisplayName -ne 'Information' | Format-List TimeCreated, Id, Message ``` Note three things before you start: the GPO GUID, the DC name, and the error description. The description narrows the cause quickly: | Error description in the event | Most likely cause | | --- | --- | | The system cannot find the path specified / file not found | The GPO folder has not replicated to that DC (SYSVOL replication), or the GPO was deleted while still linked | | The network path was not found / network name cannot be found | DNS or DC location problem, SYSVOL share missing on the DC, DFS client disabled | | Access is denied | GPO or SYSVOL permissions, Kerberos failure (time skew, broken secure channel), hardened UNC path or SMB signing requirements | ## Step 1: Confirm which DC the client uses and that it can find it On the affected computer, in an elevated prompt: ``` gpresult /r /scope computer nltest /dsgetdc:contoso.local nltest /sc_verify:contoso.local ``` `gpresult /r` shows “Group Policy was applied from” and the last apply time. `nltest /dsgetdc` returns the DC the machine located through DNS; `/sc_verify` checks the computer’s secure channel to the domain. A failed secure channel causes “Access is denied” on SYSVOL for the computer account; fix that first (see our [trust relationship failed guide](/guides/trust-relationship-failed-fix/)). Check DNS. The client must use your AD DNS servers only, never a public resolver as secondary: ``` Get-DnsClientServerAddress -AddressFamily IPv4 Resolve-DnsName contoso.local Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.contoso.local ``` Every address returned for `contoso.local` must be a live DC that serves SYSVOL. A stale A record for a demoted DC sends clients to a server that no longer answers; clean it up as part of [DC metadata cleanup](/guides/demote-domain-controller-metadata-cleanup/). ## Step 2: Test the gpt.ini path from the client Use the path from the event, then the same path against a specific DC: ``` Test-Path '\\contoso.local\SysVol\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini' Test-Path '\\DC01\SYSVOL\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini' Get-Content '\\DC01\SYSVOL\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini' ``` Microsoft notes that you must run this test as the account that failed. If the event is for computer policy, the computer account (SYSTEM) is what reads SYSVOL, not you. One way to test as SYSTEM is Microsoft Sysinternals PsExec: `psexec -s -i powershell.exe`, then run the same `Test-Path` in that window. Remove PsExec afterwards if your security policy does not allow it on endpoints. - **True as you, False as SYSTEM**: a computer-account problem: secure channel, permissions on the GPO for Domain Computers or Authenticated Users, or Kerberos. - **False against one DC, True against another**: SYSVOL replication. Go to Step 3. - **False against every DC**: the GPO folder is missing everywhere (deleted GPO still linked), or the client cannot reach SYSVOL at all (Step 4). ## Step 3: Check SYSVOL on the domain controllers (DFSR) On each DC, confirm the SYSVOL and NETLOGON shares exist and the GPO folder is present locally: ``` net share Test-Path 'C:\Windows\SYSVOL\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini' dfsrmig /getglobalstate ``` `dfsrmig /getglobalstate` should report the Eliminated state, meaning SYSVOL uses DFS Replication. If it still uses FRS, that has to be migrated before anything else, because FRS is not supported on current Windows Server versions. Then check the SYSVOL backlog between DCs in both directions, and the replicated folder state: ``` Get-DfsrBacklog -GroupName "Domain System Volume" -FolderName "SYSVOL Share" ` -SourceComputerName "DC01" -DestinationComputerName "DC02" -Verbose Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrReplicatedFolderInfo | Select-Object ReplicatedFolderName, State ``` State 4 is Normal; 5 is In Error. A large or growing backlog, or DFSR events 2213 (dirty database shutdown) or 4012 (offline longer than MaxOfflineTimeInDays) on a DC, is your root cause. Our [DFS Replication backlog guide](/guides/dfs-replication-backlog-powershell/) covers those fixes. If one DC has a broken or stale SYSVOL, a non-authoritative (D2) sync of that DC is usually the cleanest repair. Older scripts use `dfsrdiag backlog`; it gives the same answer: `dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /sendingmember:DC01 /receivingmember:DC02`. Also confirm AD replication itself is healthy (`repadmin /replsummary`), because DFSR reads its configuration from AD; see [AD replication errors 1722 and 8453](/guides/ad-replication-error-1722-8453/). ## Step 4: Check the DFS client, permissions and SMB hardening ### DFS client disabled Domain SYSVOL paths (`\\contoso.local\SysVol`) are DFS paths. If the DFS client is disabled on the computer, they fail. Check the registry value Microsoft documents for this case: ``` Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Mup' -Name DisableDFS -ErrorAction SilentlyContinue ``` If `DisableDFS` exists and is 1, set it to 0 (or remove it, after exporting the key as a backup) and restart the computer. If it is missing or 0, the DFS client is not the problem. ### GPO permissions Since the MS16-072 security update (June 2016), computers read user GPOs using the computer account. A GPO that has had Authenticated Users removed from its delegation, without adding Domain Computers with Read, will fail for computers. In Group Policy Management, open the GPO’s **Delegation** tab and confirm Authenticated Users or Domain Computers has Read (security filtering can still limit who applies it). Our [security filtering guide](/guides/group-policy-security-filtering/) shows the correct combination. On the DC you can also look at the folder ACL: ``` icacls 'C:\Windows\SYSVOL\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}' ``` ### Kerberos, time and hardened UNC paths Microsoft’s MS15-011 guidance sets hardened UNC paths for `\\*\SYSVOL` and `\\*\NETLOGON` to `RequireMutualAuthentication=1, RequireIntegrity=1` (**Computer Configuration > Administrative Templates > Network > Network Provider > Hardened UNC Paths**). Mutual authentication only works with Kerberos; NTLM cannot provide it. So when Kerberos fails, SYSVOL access fails with “Access is denied”. Typical reasons: - Clock skew between client and DC. Check with `w32tm /stripchart /computer:DC01 /samples:3` and fix the domain time hierarchy ([PDC emulator time sync](/guides/pdc-emulator-ntp-time-sync/)). - The client reaches SYSVOL by IP address or by an alias that has no SPN, so Kerberos cannot be used. - No Kerberos ticket for the DC: run `klist` and look for `cifs/DC01.contoso.local` after accessing SYSVOL. Do not “fix” 1058 by setting the hardened path values to 0 or by turning off SMB signing, as some old posts suggest. Both remove protection against SYSVOL tampering and man-in-the-middle attacks. If you need to rule them out, do it on one test machine, then fix the real Kerberos problem and restore the setting. Our [SMB signing guide](/guides/smb-signing-group-policy/) explains the signing settings. ## Fix and check that it worked - Fix the cause you found: replication, DNS, DFS client, permissions or Kerberos. - On the client, clear the DNS cache if you changed DNS records or DCs: `ipconfig /flushdns`. - Run `gpupdate /force`. You should see “Computer Policy update has completed successfully.” and “User Policy update has completed successfully.” - Run `gpresult /h C:\Temp\gpresult.html` and confirm the GPO from the event is listed under Applied GPOs with a current time. - Check the System log: Microsoft lists events 1500, 1501, 1502 or 1503 from GroupPolicy as successful processing. Over the next few refresh cycles (about every 90 minutes by default) there should be no new 1058 events. - For many machines, push the refresh remotely with the methods in [force gpupdate on remote computers](/guides/force-gpupdate-remote-computers/). ## Common problems - **1058 only right after boot or on Wi-Fi/VPN**: the network was not ready when policy processing started. If it clears on the next background refresh, it is transient; on laptops, consider the “Always wait for the network at computer startup and logon” policy. - **1058 for a GUID that no longer exists anywhere**: the GPO was deleted but a link remains (often on an OU or site). Find and remove the orphaned link in Group Policy Management. - **1058 together with 1030**: the client could not query the GPO list either; start with DNS and DC location (Step 1). - **Works for users, fails for computers**: a computer-account or permissions problem; test as SYSTEM and check Domain Computers read access. - **Still failing after all checks**: work through the wider list in [Group Policy not applying](/guides/group-policy-not-applying/), or ask us via [Get it fixed](/get-it-fixed/). **Official documentation:** [Applying Group Policy troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/applying-group-policy-troubleshooting-guidance) · [Event ID 1058: Group Policy preprocessing](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd392533(v=ws.10)) · [Force synchronization for DFSR-replicated SYSVOL](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization) · [MS15-011 hardened UNC paths](https://support.microsoft.com/en-us/help/3000483/ms15-011-vulnerability-in-group-policy-could-allow-remote-code-executi) **Related:** [Group Policy Not Applying: 12 Checks with gpresult and Events](/guides/group-policy-not-applying/) · [Force gpupdate Remote Computers: 5 Methods for Every OU](/guides/force-gpupdate-remote-computers/) · [Group Policy Security Filtering: 6 Ways to Target or Exclude](/guides/group-policy-security-filtering/) · [AD Replication Error 1722 and 8453: Fixes](/guides/ad-replication-error-1722-8453/) · [AD Health Check Report: dcdiag and repadmin PowerShell Script](/scripts/ad-health-check-report/) **See also:** [Event ID 1030: Group Policy Processing Failed (Causes and Fix)](/guides/event-id-1030-group-policy/) · [Event ID 1129: Group Policy Failed, No Connectivity to a DC](/guides/event-id-1129-group-policy/) · [DFS Replication Backlog: Check It with PowerShell and Fix It](/guides/dfs-replication-backlog-powershell/) ## Frequently asked questions ### What does event ID 1058 mean? Windows could not read a GPO’s gpt.ini file from SYSVOL on the domain controller it contacted, so that GPO, and sometimes all policy processing, was skipped. ### Is event 1058 harmful if it happens once? A single 1058 at boot that does not repeat is usually transient, for example the network was not ready. Repeated events on the same GPO mean settings are not applying and need fixing. ### Can SYSVOL replication cause event 1058? Yes. If a GPO was created or changed on one DC and has not replicated to the DC the client uses, the gpt.ini is missing there. Check the SYSVOL DFSR backlog between DCs. ### Should I disable SMB signing or hardened UNC paths to fix 1058? No. Those settings protect SYSVOL from tampering. Find the underlying Kerberos, time or name resolution problem instead. ### How do I test gpt.ini access as the computer account? Run a PowerShell window as SYSTEM, for example with Sysinternals psexec -s -i powershell.exe, and use Test-Path on the gpt.ini path from the event.