Error 1058 and 1030 on Clients

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I've been searching online for two days for the solution to this, and I'm not
having any luck.

Problem:
Clients on my network are not applying computer domain policies. They are,
however, applying user domain policies. They all have the following in the
eventlog:

Windows cannot access the file gpt.ini for GPO
CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=dev,DC=surveillant,DC=net.
The file must be present at the location
<\\dev.surveillant.net\sysvol\dev.surveillant.net\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>.
(Access is denied. ). Group Policy processing aborted.

From a client, I can see the contents of
\\dev.surveillant.net\sysvol\dev.surveillant.net\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini
just fine. However, if I try it from NT AUTHORITY\SYSTEM (using at.exe), I
get access denied. Also, the two domain controllers don't have a problem
applying the policies locally.

Here are the things I've ruled out:
1. dfsutil /PurgeMupCache doesn't help.
2. The DFS service is not stopped on the server (we use DFS for other things).
3. The DFS client is working fine on the clients.
4. The domain controllers are running DNS, and it's working fine.
5. The SMB signing thing is not the issue. The settings are compatible.
6. We don't have any account names that use non-ASCII characters.
7. We don't have too many IP addresses.
8. Our domain controllers are dual-homed, but the second NIC is disabled in
both.
9. No permission I set on the contents of the SYSVOL folder seems to make a
difference.
10. I added the ip addresses for the DCs in the HOSTS file on the DCs.
11. The TCP/IP NetBIOS Helper service is started on all machines.
12. The domain controller security policy has "bypass traverse checking"
rights assigned to the appropriate people.

What should I try next?

Thanks,
Jamie
 
Jamie-
What are the permissions on that GPT.ini file on the replica DC where your
clients are having problems? I would also compare the file on that replica
to the one on the PDC-role holder DC as it should be considered the master
copy unless you are changing the default focus when you edit GPOs.
 
I've tried every permission for that file that I know. I tried giving
"Everyone" full control. Since it's machine accounts that seem to have
trouble, I even explicitly gave my test machine full control
(DEV\JHANKINS-TEST$).

I tried permissions on the individual DCs (\\surv-exch\sysvol\...) and I've
tried permissions on the domain, (\\dev.surveillant.net\sysvol\...).

The actual file GPT.ini simply contains a line with a version number, and
this file is consistent throughout.

I captured this via Network Monitor, and you can see the file being accessed
twice. The first time is successful, and that's probably when the user
policies are being updated. The second time, it returns access denied, when
the NT AUTHORITY\SYSTEM account is trying to get the computer policies.
 
Since its computer specific maybe its a network timing issue. Have you seen
this article?
http://support.microsoft.com/default.aspx?scid=kb;en-us;842804. What version
of OS is running on the client?

Also, check out
http://support.microsoft.com/default.aspx?scid=kb;en-us;840669, which may be
another avenue to explore by increasing the GPNetworkStartTimeoutPolicyValue
entry to allow for additional time to initialize the network. I've seen this
change work on systems that use wireless cards.

Darren
--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
Check out http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Whitepapers and Utilities for all things Group Policy-related
 
The servers (two DCs) are running Win2K SP4 with all Windows Update hotfixes.
The clients are running WinXP SP2 with all WU hotfixes except for one Server
2003 client with all WU hotfixes.

The first article involves computers coming out of standby. Also, it says
that a work-around is to use "dfsutil /PurgeMupCache". This doesn't work.
Also, it says that this problem was corrected in WinXP SP2, which most of the
clients are running.

I don't think the second one is it either. It describes a race condition
during startup. I can manually type "gpupdate.exe" at the command prompt and
still get the error. If it were a startup only issue, then gpupdate would
work. Also, this problem results in event ID 1054 and 1000, not 1058 and
1030.

Thanks for trying and hopefully we can eventually come up with an answer.
Why in the world did Microsoft ship something this fragile?
 
The next thing I'd try is enabling verbose userenv logging and see what
turns up in the log.
 
As I would expect, the log shows that the user can read the policy and the
machine can't. Here are the relevant sections:

User:
USERENV(1c0.780) 11:56:04:343 ProcessGPO: ==============================
USERENV(1c0.780) 11:56:04:343 ProcessGPO: Searching
<CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=dev,DC=surveillant,DC=net>
USERENV(1c0.780) 11:56:04:343 ProcessGPO: User has access to this GPO.
USERENV(1c0.780) 11:56:04:343 ProcessGPO: GPO passes the filter check.
USERENV(1c0.780) 11:56:04:343 ProcessGPO: Found functionality version of: 2
USERENV(1c0.780) 11:56:04:343 ProcessGPO: Found file system path of:
<\\dev.surveillant.net\sysvol\dev.surveillant.net\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}>
USERENV(1c0.780) 11:56:04:359 ProcessGPO: Found common name of:
<{31B2F340-016D-11D2-945F-00C04FB984F9}>
USERENV(1c0.780) 11:56:04:359 ProcessGPO: Found display name of: <Default
Domain Policy>
USERENV(1c0.780) 11:56:04:359 ProcessGPO: Found user version of: GPC is
62, GPT is 62
USERENV(1c0.780) 11:56:04:359 ProcessGPO: Found flags of: 0
USERENV(1c0.780) 11:56:04:359 ProcessGPO: Found extensions:
[{25537BA6-77A8-11D2-9B6C-0000F8080861}{88E729D6-BDC1-11D1-BD2A-00C04FB9603F}][{3060E8D0-7020-11D2-842D-00C04FA372D4}{3060E8CE-7020-11D2-842D-00C04FA372D4}][{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}][{C6DC5466-785A-11D2-84D0-00C04FB169F7}{BACF5C8A-A3C7-11D1-A760-00C04FB9603F}]



Machine:
USERENV(1c0.438) 11:56:04:250 ProcessGPO: ==============================
USERENV(1c0.438) 11:56:04:250 ProcessGPO: Searching
<CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=dev,DC=surveillant,DC=net>
USERENV(1c0.438) 11:56:04:250 ProcessGPO: Machine has access to this GPO.
USERENV(1c0.438) 11:56:04:250 ProcessGPO: GPO passes the filter check.
USERENV(1c0.438) 11:56:04:250 ProcessGPO: Found functionality version of: 2
USERENV(1c0.438) 11:56:04:250 ProcessGPO: Found file system path of:
<\\dev.surveillant.net\sysvol\dev.surveillant.net\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}>
USERENV(1c0.438) 11:56:04:265 ProcessGPO: Couldn't find the group policy
template file
<\\dev.surveillant.net\sysvol\dev.surveillant.net\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>, error = 0x5.
USERENV(1c0.438) 11:56:04:265 ProcessGPO: ==============================
 
Well that is just no help, is it? How about a network trace from the client?
How about just copying over the gpt.ini file from the PDC emulator to the DC
where this client is hitting. Maybe there is just something funky (technical
term) with the file.

--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
Check out http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Whitepapers and Utilities for all things Group Policy-related



Jamie Hankins said:
As I would expect, the log shows that the user can read the policy and the
machine can't. Here are the relevant sections:

User:
USERENV(1c0.780) 11:56:04:343 ProcessGPO: ==============================
USERENV(1c0.780) 11:56:04:343 ProcessGPO: Searching
<CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=dev,DC=surveillant,DC=net>
USERENV(1c0.780) 11:56:04:343 ProcessGPO: User has access to this GPO.
USERENV(1c0.780) 11:56:04:343 ProcessGPO: GPO passes the filter check.
USERENV(1c0.780) 11:56:04:343 ProcessGPO: Found functionality version of:
2
USERENV(1c0.780) 11:56:04:343 ProcessGPO: Found file system path of:
<\\dev.surveillant.net\sysvol\dev.surveillant.net\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}>
USERENV(1c0.780) 11:56:04:359 ProcessGPO: Found common name of:
<{31B2F340-016D-11D2-945F-00C04FB984F9}>
USERENV(1c0.780) 11:56:04:359 ProcessGPO: Found display name of:
<Default
Domain Policy>
USERENV(1c0.780) 11:56:04:359 ProcessGPO: Found user version of: GPC is
62, GPT is 62
USERENV(1c0.780) 11:56:04:359 ProcessGPO: Found flags of: 0
USERENV(1c0.780) 11:56:04:359 ProcessGPO: Found extensions:
[{25537BA6-77A8-11D2-9B6C-0000F8080861}{88E729D6-BDC1-11D1-BD2A-00C04FB9603F}][{3060E8D0-7020-11D2-842D-00C04FA372D4}{3060E8CE-7020-11D2-842D-00C04FA372D4}][{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}][{C6DC5466-785A-11D2-84D0-00C04FB169F7}{BACF5C8A-A3C7-11D1-A760-00C04FB9603F}]



Machine:
USERENV(1c0.438) 11:56:04:250 ProcessGPO: ==============================
USERENV(1c0.438) 11:56:04:250 ProcessGPO: Searching
<CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=dev,DC=surveillant,DC=net>
USERENV(1c0.438) 11:56:04:250 ProcessGPO: Machine has access to this GPO.
USERENV(1c0.438) 11:56:04:250 ProcessGPO: GPO passes the filter check.
USERENV(1c0.438) 11:56:04:250 ProcessGPO: Found functionality version of:
2
USERENV(1c0.438) 11:56:04:250 ProcessGPO: Found file system path of:
<\\dev.surveillant.net\sysvol\dev.surveillant.net\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}>
USERENV(1c0.438) 11:56:04:265 ProcessGPO: Couldn't find the group policy
template file
<\\dev.surveillant.net\sysvol\dev.surveillant.net\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>,
error = 0x5.
USERENV(1c0.438) 11:56:04:265 ProcessGPO: ==============================


Darren Mar-Elia (MVP) said:
The next thing I'd try is enabling verbose userenv logging and see what
turns up in the log.
Click to expand...
Click to expand...
 
I'm sorry it's been so long. I was out last week.

I've tried a network trace (you mean NetMon.exe?). You can see the access
denied when you try gpupdate.exe. The client successfully reads the file
during the user portion. However, the client gets an access denied when it
tries to read it during the machine portion. What this tells me is that a
normal domain user can read the file. However, a machine account cannot.

I tried deleting the file and re-creating it.

As for copying over the gpt.ini file, I'm not sure exactly what you mean.
On both of the domain controllers, the file is at:
c:\WINNT\SYSVOL\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini
** and *
c:\WINNT\SYSVOL\sysvol\dev.surveillant.net\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini

From a remote machine, the file is at
\\dev.surveillant.net\sysvol\dev.surveillant.net\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\GPT.ini
 
Hi Jamie,

Sorry there is no previous post here.

So what is the current security set?

br,
Denis
 
Make sure that Authenticated Users have permissions all the way down the
tree to the policy files. Computer accounts are members of the
Authenticated Users "group".
 
Ok. My last guess. Is it one machine having problems or multiple? If one,
maybe try re-adding it to the domain?

--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
Check out http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Whitepapers and Utilities for all things Group Policy-related
 
The only two computers on the domain that are not having trouble applying the
machine group policy are the two domain controllers.
 
Hi Jamie,

This might not be helpful, but have you tried gpresult?

Have you tried gpotool (also with switches /checkacl and /verbose)?
Sometimes, the basic ones are the most useful.

You might also have checked this out, just FYI.

Applying Group Policy causes Userenv errors and events to occur on your
computers that are running Windows Server 2003, Windows XP, or Windows 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;887303

br,
Denis
 
FYI, the way I solved this was to rebuild the SYSVOL using the following steps:

1. Stop the "File Replication Service" on all DCs.
2. On one DC, set the "BurFlags" to "D4" (see below for details).
3. On all other DCs, set the "BurFlags" to "D2".
4. Back up all policies using the new spiffy policy editor. Alternatively,
copy all directories and files under c:\winnt\sysvol\domain\Policies.
5. Back up files (if any) under c:\winnt\sysvol\domain\scripts.
6. Delete all files under c:\winnt\sysvol\domain\Policies on all DCs.
7. Start the "File Replication Service" on the computer you set to D4.
8. Start the "File Replication Service" on all other DCs.
9. Restore the policies and scripts on the D4 DC.

To set the BufFlags, in RegEdit, go to
"HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets". Make
a note of the GUID (big hexadecimal number) that is the single key under
"Replica Sets". Now go to
"HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica
Sets". Under that, go to the key that is the GUID that you made a note of.
There is a value under that called "BurFlags". This is the value that I am
talking about in the instructions above.

It seems like there are many different reasons for this problem. I tried
all of the other solutions I found, and this is what finally solved my
problem.
 
Back
Top