Diagnosing and repairing Events 1030 and 1058

Let's say you are going through your server's event viewer logs, under START>>Control Pannel>>Administrative Tools>>Event Viewer>>system logs and you see a lot of errors saying:

--Event ID 1030- Windows cannot query for the list of Group Policy objects....
--Event ID 1058 - Windows cannot access the file gpt.ini for GPO....

Well, events 1030 and 1058 are very generic errors and can be caused by one of many different reasons. I often see questions at Experts Exchange on how to overcome these events. I don't have all the answers, but have helped out a lot of people diagnose and fix these events. Since this is a frequently asked question with a bunch of different fixes, I hope to steer you in the right direction on how to troubleshoot and fix your error with this article.

ABOUT GROUP POLICIES:
Without going into too much detail, Group policy objects, when created, are basically:
1) saved within the Sysvol folder of the Domain Controller (DC);
2) then replicated as a DFS (Distributive File shares) using FRS (File Replication Service), or DFSR (Distributive File Share Replication) between domain servers using DNS as the communications protocol;
3) then like all DFS (Distributed File Shares) shares are distributed out using NetBIOS.  

If you run into a problem within one of these three stages, you will run into event log errors 1030 and 1058. These two events are just symptoms, not the problem. So, if you get into the roots of the three stages a number of different problems can cause your errors. The number of different possibilities makes these errors generic.  A list of potential root problems, a guide on how to troubleshoot your problem, and the list of some known fixes are outlined below.

HERE IS A LIST OF POTENTIAL PROBLEMS THAT CAN LEAD TO 1030 AND 1058 EVENT ERRORS:

--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

Since there are a number of reasons Events 1030 and 1058 may occur, you should know how to pinpoint your problem.

___________________

YOUR FIRST STEP IS SELF ASSESSMENT:

>>FREQUENCY OF ERRORS:
A) If your errors are logged every 5 minutes, it usually means a server to server error. This would imply a file replication issue or permissions issue on the Sysvol folder.

B) If these errors show up every 15 minutes, it is usually a server to client problem. This would imply a NetBIOS issue or a corrupt GPO on the server. A corrupt GPO could also be a part of a partial replication set, so, this too could be a file replication problem.

Frequency is important to help you determine if this is a client to server problem or server to server problem. Remember the three basic stages of a Group Policy object. A server to server problem implies that you have a problem with replicating the policy from one DC to the other. A client to server problem implies the client is having a problem using NetBIOS or only seeing a partial GPO in the Sysvol of its DC. So this implies either a NetBIOS problem or a partial replication.

>>MULTIHOMED SERVER:
Determine if you have two NICs on the server. NetBIOS will bind to both NICs, but there is a bind order. If you have two NICs, you may have the "outside" NIC bound before the "inside" NIC.

>>FILE REPLICATION PROBLEMS:
Now go into your FRS event viewer logs of the DC and see if you have warnings or errors in the 13000's. These errors could include, but are not limited to:

A) Event ID 13508- The File Replication Service is having trouble enabling replication from <server 1 name> to <server 2 name> for c:\winnt\sysvol\domain; retrying.

B) Event ID 13568 - The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.

C) Event ID 13566-       File Replication Service is scanning the data in the system volume. computer <domain name> cannot become a domain controller until this process is complete. The system volume will then be shared as SYSVO
and so on.

D) Event 13565-      File Replication Service is initializing the system volume with data from another domain controller. computer BACKUP cannot become a domain controller until this process is complete. The system volume will then be shared as SYSVOL.

This will tell you if you have FRS problems. FRS problems are almost 100 percent of the time caused by DNS issues.

PLEASE NOTE: If you discover FRS problems, you may stop right there and seek DNS troubleshooting and fixing. Once done, 2003 Server (Standard edition and older) may need to reset the replication procedures using the BurFlag method to reset the replication set. BurFlag is a registry flag edit to tell your DC to rebuild the Sysvol and netlogon shares and reset replication. An example of the BurFlag method is outlined in the fixes below. 2003 Server R2 and newer should never use the BurFlag method because of the enhanced features of DFSR (Distributive File Share Replication) over FRS (File replication service).

>>CHECKING THE EXISTANCE OF THE GROUP POLICY ITSELF:
Your errors (Event 1030 and 1058) should point you to the path of the GPO that is trying to be accessed. You could look in your Sysvol folder to make sure they exist.  If not, you may have a replication problem or you could have a corrup GPO and may need to recreate the GPO.

>>ENSURE THE CORRECT SERVICES STARTED:
You might also look in services to make sure the Netlogon service is started and the Distributive File Share (DFS) service. To do so, go to the START button>>select run>>and type services.msc. When the window opens up, you will see a list of services, check to make sure the DFS service and Netlogon services are set for automatic and started.

>>VERIFYING SYSVOL AND NETLOGON STATUS, INCLUDING PERMISSIONS:
Verify that the proper permissions are set for SYSVOL replication. At the command prompt, type the following command, and then press ENTER:

dcdiag /test:netlogons


NOTE The DCDIAG, is found in the 2003 server support tools. There are two places to find these support tools:
      \\Support\Tools\Support.cab file on the Windows Server install disk.
    or you can download these tools
      http://download.microsoft.com/download/8/e/c/8ec3a7d8-05b4-440a-a71e-ca3ee25fe057/rktools.exe
    There are a great set of tools that many administrators use to diagnose and fix Domain and network problems.

>>VERIFYING DNS SRV RECORDS:
For a simple test, you can go to the command prompt of your server and type:
DCdiag /test:DNS

NOTE: Once again DCdiag is a part of the 2003 server support tools, and found on your install disk or downloaded from the internet.

____________________________________________________________

AFTER THE SELF ASSESSMENT IS THE LIST OF POTENTIAL FIXES:

1)FRS REPLICATION PROBLEMS:

--NOTE: FIX DNS FIRST: (Get help if needed)
If you are running into FRS replication problems, almost always, you have a problem with DNS. DNS is the protocol that file replication uses to communicate with. Since DNS troubleshooting is beyond the intent of this article, I recommend you get a little help on this by posting a question about fixing DNS. Or you can review another article I wrote for troubleshooting DNS errors:

https://www.experts-exchange.com/articles/Networking/Protocols/DNS/DNS-Troubleshooting-made-easy.html

In addition to fixing DNS: File replication errors in the 13000s can indicate that you have partial replication set. This means that your file replication stopped in mid-process. In other words, it is in stand-bye. A partial replication set and a halt to the File Replication Services  is called journal wrap . To overcome journal wrap, 2003 R2 servers and 2008 servers should do this automatically because of the enhanced features of DFSR. 2003 standard and older may need a little assistance using the BurFlag method. If you are in journal wrap, FRS will not always replicate on these older servers until the replication set is reset using the BurFlag method.

NOTE: Sometimes you can force replication and that will restart the file replication services. You should try to force replicate prior to the Burflag method. It is s less invasive method and you will not have to edit registry keys to force replicate. This article explains, in simple terms, how to force replicate beteween servers:
http://www.windowsnetworking.com/kbase/WindowsTips/Windows2003/AdminTips/ActiveDirectory/ForcingActiveDirectoryReplication.html

After fixing DNS, and if force replication doesn't resolve your issue, you will have to use the burflag method to reset the file replication set.

From what I see, the number one cause of group policy 1030 and 1058 events is FRS problems.

Then, example of FRS problem and how to use the  burflag registry flag to reset your replication set example on NON-DFSR servers: https://www.experts-exchange.com/Q_23407701.html
_________________________________________________________________

2)DUAL NICS:

Multi-homed servers can cause another problem. The problem is, netbios binds to one NIC as its preferred NIC for NetBIOS translation. On a multihomed server, you may have an "outside" NIC and an "inside" NIC. If both NICs are providing NetBIOS, then your clients may not be able to get the DFS shares via NetBIOS because the outside NIC may be the first to bind to NetBIOS. The fix is to disable NetBIOS on the outside NIC. For that matter, you may wish to uninstall file and print sharing on that NIC.

Dual NICs Example (and plausible fix): https://www.experts-exchange.com/Q_22990774.html
__________________________________________________________

3) REMOTE SITES:

NetBIOS is not routeable. This means it will not go through a VPN tunnel, through NAT routers, to different subnets, or to a remote site.  So, if you are trying to administer your group policies to a remote site or over a VLAN, then you might need to consider a WINS connection between your DC and that remote DC or client.

NetBIOS problems example: https://www.experts-exchange.com/Q_23507742.html
___________________________________________________________________

4) PURGING THE MUPCACHE

I saw this helps some people out with 1030 and 1058 errors, but I had to ask myself what does purging the MUPcache do. So, let's break it down:

DFSutil means Distributive File Share Utility
MUP stands for Multiple UNC Path for short, (multiple Universal Naming Conventions Path)
cache is just a saved object stored in memory on the server that is updated from time to time, (much like DNS cache)

For Definition: UNC stands for Universal Naming Convention and is used in different ways to communicate with the share. It is used to contact a mapped share. Example
\\Domaincontrollername\share (A NetBIOS UNC Path to a share)
\\Domaincontrollername.domain.name\share (A DNS name to a share)
\\123.456.789.101\share (using the IP path to the share)

If your UNC path to your Sysvol and Netlogon shares are incorrect, I could see this causing a problem with your client computers inability to access the sysvol and netlogon shares.

Bringing it all back together, if you type DFSutil /purgemupcache, you will be deleting potentially incorrect UNC paths to your sysvol and netlogon shares. All cached records will recreate themselves through netbios broadcasts and that recreation will be transparent to the administrator and users.

Purging the mupcache is something that is not detrimental to your server and could potentially fix your problem.
https://www.experts-exchange.com/Q_22123082.html

There is an article from Microsoft's TechNet which briefly describes mupcache:
"How DFS Works":  http://technet.microsoft.com/en-us/library/cc782417(WS.10).aspx

"The multiple UNC provider (MUP) cache stores information about which redirector, such as DFS, SMB, or WebDAV, is required for each UNC path that a client computer attempts to access. Entries in the MUP cache are held for 15 minutes. You can use Dfsutil.exe's /PurgeMupCache parameter to clear the MUP cache. This might be necessary when a folder is changed from an SMB shared folder to a WebDAV or DFS root folder or vice versa."

So, once again, the frequency of your errors is important. The MUP cache is a list of UNC paths that the client accesses every 15 minutes, by default, to contact the server for DFS shares. So, if you use this command line utility, make sure your GPOs work afterwards. It may have just masked the problem instead of resolving it.

NOTE The DFSutility, for purging the mupcache, is found in the 2003 server support tools. There are two places to find these support tools:
      \\Support\Tools\Support.cab file on the win server install disk.
or
      http://download.microsoft.com/download/8/e/c/8ec3a7d8-05b4-440a-a71e-ca3ee25fe057/rktools.exe
There are a great set of tools that many administrators use to diagnose and fix Domain and network problems.

_____________________________________________________________________

5) PERMISSIONS PROBLEMS ON THE SYSVOL AND NETLOGON FILE FOLDERS:

Sometimes the permissions are corrupt or incorrect on the Sysvol folders. In that case, there is a fix. You can find it here in EE's time tested solutions:

https://www.experts-exchange.com/Q_21587377.html
_____________________________________________________________________

Conclusion:

Just seeing Event errors 1030 and 1058 is not enough to diagnose and find a fix them. The fix depends on what is causing your particular problem with group policy. A good self assessment, and a list of potential fixes hopefully helps you pinpoint your problem and resolve it. I hope this provides you with the ammo to overcome your GP issues. If not, use your self assessment and post an Experts Exchange question for added assistance. In your question, please provide this article as a reference for the Experts Exchange Expert to assist you better.