I have been trying to resolve this error, like many others:

The processing of Group Policy failed. Windows attempted to read the file \domain.local\SysVol\domain.local\Policies{3EF90CE1-6908-44EC-A750-F0BA70548600}\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.

Error code: 5 = Access Denied.

The incredibly helpful post is this one (http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/2003_Server/A_1073-Diagnosing-and-repairing-Events-1030-and-1058.html). Quoting from this post:


--Sometimes the permissions of the file folders that contain Group policies (the Sysvol folder) can be corrupted.

--Sometimes you have problems with NetBIOS:

--Sometimes the GPO itself is corrupt, or you have a partial set of data for that GPO.

--Sometimes you may have problems with File Replication Services, which almost always indicates a problem with DNS

--Sysvol may be a subfolder of itself: Sysvol/Sysvol

I have the problem listed where sysvol is a subfolder of sysvol.

The directory structure is:

    -staging areas
    -sysvol (shared as "\\server\sysvol")

Interestingly, the second sysvol folder is the one that is shared as "\server\sysvol". This makes me confident this is the issue with the permissions and error code 5.

Also interestingly, my server 2008 R2 servers can see it fine - my server 2008 servers cannot, and get the error. This is consistent across all my servers.

This latter fact makes me uncertain what I need to do to fix this up. Do I, e.g., simply move the shared sysvol folder up a level to replace the non-shared one?

Any help greatly appreciated.



  • The folder structure and share is perfectly normal. What exactly is the problem you're asking about?
    – joeqwerty
    Commented Apr 10, 2011 at 23:37
  • I added a quote from the Experts Exchange post I was referring to - it lists a possible cause of the error being when sysvol is a subdir of sysvol. Do you think this is not a problem, or not a potential cause of the problem?
    – Hanshan
    Commented Apr 11, 2011 at 0:14
  • In a typical installation, there is a sysvol folder under the "root" sysvol folder. Post the text of the event ID 1058 as there are several that are related to AD and GP.
    – joeqwerty
    Commented Apr 11, 2011 at 0:39
  • Thanks for your patience mate, have added the text of the error, and the error code (5 = access denied).
    – Hanshan
    Commented Apr 11, 2011 at 1:20

2 Answers 2


I'm not sure what the "experts" exchange post was taking about. Follow the steps listed here to troubleshoot the issue:

Group Policy failed Event ID 1058 Error Code 5

  • Unfortunately, I have run through these steps to no avail - quite thoroughly, I believe. However, re-reading them, I am quite sure my problem is not, as I thought, that sysvol is a subdir of sysvol.
    – Hanshan
    Commented Apr 11, 2011 at 4:56
  • So the permissions are ok on the INI file?
    – Jim B
    Commented Apr 11, 2011 at 14:49
  • They are. Furthermore, I have a number of servers - some 2008 R2, others just 2008. The problem is consistent across all 2008's, and is absent on all 2008 R2's.
    – Hanshan
    Commented Apr 11, 2011 at 23:05
  • do you get this is you manually run Gpupdate /force? What exactly are the permissions on this file? One quick way to reset the perms (sometimes) is to open the GPO, make a change, apply, change it back apply.
    – Jim B
    Commented Apr 12, 2011 at 16:14
  • In the first instance, that the policy isn't applied is apparent from the features. Running a gpupdate raises the error. Perhaps it is telling that the User Policy updates fine, but the Computer policy does not?
    – Hanshan
    Commented Apr 13, 2011 at 0:05

Experienced this same issue and error code. After troubleshooting for more than half a year--including countless and largely fruitless interactions with Microsoft support--we eventually found the problem was due to a startup script (powershell) modifying the system PATH variable and this caused a series of unexpected effects.

The string that was being manipulated by this script was somehow also getting mangled, and the SYSVOL path needs to exist here and be readable by Windows for group policy to function properly.

My best guess is that the script wrote the updated value to the PATH variable but in a more modern encoding than what these archaic Windows system-level processes could read. Interestingly (and unfortunately), the Windows GUI still displayed the updated PATH variable values correctly, so everything appeared as it should. This made troubleshooting the issue much more complicated than it otherwise would have been because it looked like our script was working as intended.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .