Group Policy events 1058 and 1030 — cannot read gpt.ini
The client found the policy in Active Directory but could not read its files from SYSVOL, so no policy applies at all.
What you see
Events 1058 and 1030 paired in the System log on many machines. gpupdate /force reports the policy could not be applied. Drive mappings, printers and security settings silently stop being enforced.
What is actually wrong
SYSVOL is unreachable or its DFS namespace is broken, the client cannot authenticate to it, or SMB signing and hardening changes have blocked the path.
Codes and articles
Fixes (2)
Restore the SYSVOL path and its DFS namespace
The domain-based path does not resolve or open.
Test both forms of the path from the client. The difference tells you whether it is DFS or the share.
Test-Path \\example.local\SYSVOL\example.local\PoliciesTest-Path \\DC01\SYSVOL\example.local\Policies
The domain form goes through the DFS namespace and needs the DFS Namespace service and a working domain referral; the server form is a plain SMB share. Which one fails narrows this immediately.
On the DC, confirm SYSVOL and NETLOGON are actually shared.
Get-SmbShare | Where-Object Name -in 'SYSVOL','NETLOGON' | Format-Table Name, Path, Description -AutoSizenet share
If they are missing, SYSVOL has not finished its initial replication — check for the SYSVOL ready flag.
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' -Name SysvolReadyConfirm the DFS Namespace service is running on every DC.
Get-Service Dfs, DFSR, Netlogon | Format-Table Name, Status, StartType -AutoSizeRe-register the DC's records and restart Netlogon, which republishes the referral.
nltest /dsregdnsRestart-Service Netlogon
Test policy application on the client.
gpupdate /forcegpresult /r
gpresult /h C:\temp\gpo.htmlFix authentication and SMB hardening on the SYSVOL path
SYSVOL opens interactively but policy still fails — the machine account, not your account, is what has to read it.
Remember that policy is read by the COMPUTER account for computer policy. Your ability to browse the share proves nothing about it.
This is the single most common misdiagnosis of 1058 — the admin opens SYSVOL successfully and concludes the path is fine.
Confirm the machine's secure channel to the domain is intact.
Test-ComputerSecureChannel -VerboseRepair it if broken.
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)Check the SMB client and server signing settings on both ends — a mismatch after a hardening baseline blocks exactly this.
Get-SmbClientConfiguration | Format-List RequireSecuritySignature, EnableSecuritySignatureGet-SmbServerConfiguration | Format-List RequireSecuritySignature, EnableSecuritySignature, EnableSMB1Protocol
Confirm Authenticated Users still has Read on the policy objects — a delegation change that removes it breaks every client at once.
Get-GPO -All | ForEach-Object { $g=$_; Get-GPPermission -Guid $g.Id -All | Where-Object { $_.Trustee.Name -eq 'Authenticated Users' } | Select-Object @{n='GPO';e={$g.DisplayName}}, Permission }Restore it where missing.
Set-GPPermission -Name 'Default Domain Policy' -TargetName 'Authenticated Users' -TargetType Group -PermissionLevel GpoRead
Related faults
Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.