Event IDs 1030 and 1058 on Server 2003 Domain Controller

Written by Sam McGeown

Published on 29/3/2010 - Read in about 2 min (335 words)

Published under Microsoft #Active Directory #Active Directory #Microsoft #Windows #Windows Server 2003

I logged onto a production domain controller this morning and checked the event logs to be confronted with this:

Event ID 1030 and 1058 every 5 minutes, looking into the detail for these events I can see its a replication issue for one of the GPOs.

Event Type:	Error
Event Source:	Userenv
Event Category:	None
Event ID:	1030
Date:		29/03/2010
Time:		04:01:29
User:		NT AUTHORITY\SYSTEM
Computer:	DC01
Description:
Windows cannot query for the list of Group Policy objects.
Check the event log for possible messages previously logged by the
policy engine that describes the reason for this.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

The slightly more informative 1058 showed

Event Type:	Error
Event Source:	Userenv
Event Category:	None
Event ID:	1058
Date:		29/03/2010
Time:		04:06:30
User:		NT AUTHORITY\SYSTEM
Computer:	DC01
Description:
Windows cannot access the file gpt.ini for GPO CN={3A7AC061-A26C-4154
-8CF5-01D5754E5C2C},CN=Policies,CN=System,DC=DOMAIN,DC=LCL.
The file must be present at the location <\\DOMAIN.LCL\SysVol\DOMAIN.LCL
\Policies\{3A7AC061-A26C-4154-8CF5-01D5754E5C2C}\gpt.ini>. (Access is denied. ).
Group Policy processing aborted. 
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

There was no visible cause for the errors, DFS had just got it’s knickers in a twist somehow and was not resolving the DFS share for the domain correctly.

The resolution was fairly simple, running the “dfsutil /purgeMUPCache” command seems to have resolved it for now. The /PurgeMUPCache command clears the MUP Cache (duh!) which holds info about DFS and other shares on the client system.

Technet says: “Clears the client MUP cache, preventing confusion about the current provider when such names conflict. Except for a temporary performance hit, this command has no other adverse effects. This command does not affect any DFS metadata. If this command is not run, and the namespace is not accessed, the obsolete cache entry eventually expires.”

There are plenty of other causes for these errors, if your server is multi-homed (multiple NICs) then check that your “public” NIC is at the top of the adaptor bindings.

My DC is now running happily, no 1030 or 1058s.

Share this post