Q: I’m seeing a lot of events with ID
1058 (Windows cannot access the file
gpt.ini for GPO) and ID 1030 (Windows
cannot query for the list of Group
Policy objects) in my application
event logs on my client machines
whenever Group Policy is processed,
and Group Policy seems to be failing.
What’s causing these errors?
A: These errors are common, and
unfortunately there’s no one cause—
or solution. These errors arise when
the client computer can’t successfully
read the Sysvol portion of a Group
Policy Object (GPO), which is where
the gpt.ini file is stored. Most often,
these errors occur because Windows’
networking stack doesn’t initialize
in time for Group Policy processing
to occur. In such cases, you’ll typically
see that computer processing of
Group Policy will fail, but then user
processing of Group Policy will succeed.
There are a couple of Microsoft
articles that address these network
timing problems, including “Group
Policy application fails on a computer
that is running Windows 2000, Windows
XP Service Pack 1, or Windows
XP Service Pack 2” (support.microsoft
.com/?kbid=840669), which helps you
fix a variety of these problems, and
“How to disable the Media Sensing
feature for TCP/IP in Windows” (support.
microsoft.com/?kbid=239924),
which may also help with these types
of problems, especially in wireless
scenarios. The article “A client connected
to an Ethernet switch may
receive several logon-related error
messages during startup” (support.
microsoft.com/?kbid=202840) can
also apply in certain scenarios where
your network switch is not initializing
a system’s Ethernet port by the time
Windows has started up.
The class of problems in which
these events occur are when the gpt.
ini is either missing for a given GPO
or the permissions on it are such that
the user or computer can’t read them.
In both cases, the error is usually the
result of File Replication Service (FRS)
problems with the Sysvol portion of a
GPO on the domain controller (DC)
that’s currently being used by the
computer for Group Policy processing.
The quickest way to check this
kind of problem is to use the gpotool.
exe utility that ships as part of Windows
Vista, or, for earlier OS versions,
in the Windows Server 2003 Resource
Kit Tools. You can use Gpotool to
check the consistency of GPOs across
DCs within your environment. The
quickest way to check for problems
from a system on which you’re getting
1058 and 1030 event errors is to run
Gpotool against the DC that the computer
is currently using to process
policy (usually a DC in its local Active
Directory—AD—site) and compare
that to the PDC-emulator DC, which
is typically where Group Policy
changes originate. In the following
example, I use Gpotool to check the
consistency of the Default Domain
Policy GPO, including ACLs, on both
my local DC (dc100) and my PDCemulator
DC (sdm1):
gpotool /gpo:”Default Domain Policy”
/dc:sdm1,dc100 /checkacl /verbose
The /verbose option lets me see
full details for each comparison.
If I find a problem with either
missing files on my local DC or
incorrect permissions, then its
time to break out the FRS troubleshooting
tools, such as Sonar
(www.microsoft.com/downloads/details.aspx?FamilyID=158cb0fbfe09-
477c-8148-25ae02cf15d8&
DisplayLang=en) or try one of
the techniques described in
the Microsoft article “Applying Group
Policy causes Userenv
errors and events to occur on
your computers that are running
Windows Server 2003, Windows
XP, or Windows 2000” (support.microsoft.com/?kbid=887303).