Error 1058 and 1030 on Clients

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
17 answers Last reply
More about error 1058 1030 clients
  1. 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
  2. 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.
    >
  3. 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.
    >>
    >
  4. 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
  5. 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
    >
  6. 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.
  7. 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.
    >
  8. 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.
    >
  9. 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.
    >>
    >
  10. 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".
  11. 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.
    > >
    >
  12. 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?&guid=&sloc=en-US&dg=microsoft.public.win2000.group_policy&p=1&tid=8489a04d-c793-4f8e-8ae5-d7e9a1d51c49&mid=a1bf3924-30ee-4b2b-88fc-de576f63f33a

    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
  13. 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?&guid=&sloc=en-US&dg=microsoft.public.win2000.group_policy&p=1&tid=8489a04d-c793-4f8e-8ae5-d7e9a1d51c49&mid=a1bf3924-30ee-4b2b-88fc-de576f63f33a
    >
    > 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
    >
  14. 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?
  15. 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
  16. 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.
  17. 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?&guid=&sloc=en-US&dg=microsoft.public.win2000.group_policy&p=1&tid=8489a04d-c793-4f8e-8ae5-d7e9a1d51c49&mid=a1bf3924-30ee-4b2b-88fc-de576f63f33a
    >
    > 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
    >
Ask a new question

Read More

Domain Windows