Sign in with
Sign up | Sign in
Your question

Error 1058 and 1030 on Clients

Last response: in Windows 2000/NT
Share
Anonymous
June 30, 2005 7:00:02 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

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
Anonymous
June 30, 2005 8:37:15 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

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.

--
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" <JamieHankins@discussions.microsoft.com> wrote in message
news:8489A04D-C793-4F8E-8AE5-D7E9A1D51C49@microsoft.com...
> 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
Anonymous
June 30, 2005 9:45:02 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

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.

"Darren Mar-Elia" wrote:

> 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.
>
Related resources
Anonymous
June 30, 2005 10:10:56 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

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



"Jamie Hankins" <JamieHankins@discussions.microsoft.com> wrote in message
news:BB011AC6-2C32-4C16-B8B5-9310BE2A4FC1@microsoft.com...
> 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.
>
> "Darren Mar-Elia" wrote:
>
>> 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.
>>
>
Anonymous
July 1, 2005 11:28:05 AM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

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?

"Darren Mar-Elia" wrote:

> 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
Anonymous
July 1, 2005 11:45:20 AM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

The next thing I'd try is enabling verbose userenv logging and see what
turns up in the log.



"Jamie Hankins" <JamieHankins@discussions.microsoft.com> wrote in message
news:F496B71C-5EAA-40BD-A864-39C26138147C@microsoft.com...
> 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?
>
> "Darren Mar-Elia" wrote:
>
>> 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
>
Anonymous
July 1, 2005 1:07:04 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

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)" wrote:

> The next thing I'd try is enabling verbose userenv logging and see what
> turns up in the log.
Anonymous
July 1, 2005 4:44:59 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

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" <JamieHankins@discussions.microsoft.com> wrote in message
news:B5AF7224-5460-4927-B753-0D19AC3FBBB6@microsoft.com...
> 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)" wrote:
>
>> The next thing I'd try is enabling verbose userenv logging and see what
>> turns up in the log.
>
Anonymous
July 11, 2005 4:44:11 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

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

"Darren Mar-Elia" wrote:

> 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.
>
Anonymous
July 12, 2005 12:39:41 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

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

--
Mike Shepperd
MCSE NT4, 2000, 2003
NewFuture Consulting
Seattle, Washington


"Jamie Hankins" <JamieHankins@discussions.microsoft.com> wrote in message
news:2EEA7B56-06A2-4C24-B32C-1F3FF7BA8216@microsoft.com...
> 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
>
> "Darren Mar-Elia" wrote:
>
>> 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.
>>
>
Anonymous
July 12, 2005 4:43:01 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Yes, I did this very early on.

"Mike Shepperd" wrote:

> 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".
Anonymous
July 12, 2005 4:43:17 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Hi Jamie,

Sorry there is no previous post here.

So what is the current security set?

br,
Denis

"Jamie Hankins" <JamieHankins@discussions.microsoft.com> wrote in message
news:2EEA7B56-06A2-4C24-B32C-1F3FF7BA8216@microsoft.com...
> 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.i
ni
> ** 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-11D
2-945F-00C04FB984F9}\GPT.ini
>
> "Darren Mar-Elia" wrote:
>
> > 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.
> >
>
Anonymous
July 12, 2005 4:43:18 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Here is the URL so you can get the entire thread:
http://support.microsoft.com/newsgroups/newsReader.aspx...

Thanks,
Jamie

"Denis Wong @ Hong Kong" wrote:

> Hi Jamie,
>
> Sorry there is no previous post here.
>
> So what is the current security set?
>
> br,
> Denis
Anonymous
July 12, 2005 5:09:19 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

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



"Jamie Hankins" <JamieHankins@discussions.microsoft.com> wrote in message
news:7DA016C9-68B6-425A-A586-5840FE5B97FC@microsoft.com...
> Here is the URL so you can get the entire thread:
> http://support.microsoft.com/newsgroups/newsReader.aspx...
>
> Thanks,
> Jamie
>
> "Denis Wong @ Hong Kong" wrote:
>
>> Hi Jamie,
>>
>> Sorry there is no previous post here.
>>
>> So what is the current security set?
>>
>> br,
>> Denis
>
Anonymous
July 12, 2005 6:00:03 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

The only two computers on the domain that are not having trouble applying the
machine group policy are the two domain controllers.

"Darren Mar-Elia" wrote:

> Ok. My last guess. Is it one machine having problems or multiple? If one,
> maybe try re-adding it to the domain?
Anonymous
July 12, 2005 6:06:02 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

I've posted a netmon capture of a gpupdate to
http://groups.msn.com/FixMyDomain/documents.msnw.

"Darren Mar-Elia" wrote:

> 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
Anonymous
July 13, 2005 11:32:05 AM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

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.
Anonymous
July 13, 2005 4:22:53 PM

Archived from groups: microsoft.public.win2000.group_policy (More info?)

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

"Jamie Hankins" <JamieHankins@discussions.microsoft.com> wrote in message
news:7DA016C9-68B6-425A-A586-5840FE5B97FC@microsoft.com...
> Here is the URL so you can get the entire thread:
>
http://support.microsoft.com/newsgroups/newsReader.aspx...
>
> Thanks,
> Jamie
>
> "Denis Wong @ Hong Kong" wrote:
>
> > Hi Jamie,
> >
> > Sorry there is no previous post here.
> >
> > So what is the current security set?
> >
> > br,
> > Denis
>
!