[gptalk] Re: Local Policies on Windows XP

  • From: "Darren Mar-Elia" <darren@xxxxxxxxxx>
  • To: <gptalk@xxxxxxxxxxxxx>
  • Date: Tue, 31 Oct 2006 15:59:00 -0800

Michael-
I missed that part--yes, GP replication is domain-specific. So, probably not
an issue with your forest root DCs causing child GP problems.

Darren 

-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of mikedd@xxxxxxxxxxx
Sent: Tuesday, October 31, 2006 3:49 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Local Policies on Windows XP

Thx Darren. Interesting. So despite SYSVOL being domain based, this problem
could of been caused from the forest root DC's........ I thought only DC's
within the domain could replicate SYSVOL? Is their any way to prevent this
in the future from happening.

Michael


Michael-
The inconsistent permissions message could cause a difference in GP
application behavior. Basically that message means that the inheritance
flags on individual GPO folders in SYSVOL were tweaked, resulting in those
GPOs getting a set of ACLs that were inherited from the Parent folder, which
can of course affect the visibility of a GPO for processing. I would not be
surprised if your replication problems caused this, although its hard to
tell in retrospect.

Darren

-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of mikedd@xxxxxxxxxxx
Sent: Tuesday, October 31, 2006 2:16 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Local Policies on Windows XP

I recently experienced a weird problem, I'm hoping someone can shed light
on, and possibily provide a link to a MSKB or whitepaper as I've turned up
nothing so far. I have a Windows Server 2003 R2 environment with Windows XP
SP2.0 clients. Recently users network adapters disappeared from network
connections on the desktop. Connectivity was still present, and IPCONFIG
confirmed IP addressing information obtained. However access to various
tools to check policies failed using admin rights on the box including
GPRESULT, GPEDIT.MSC, and RSOP.MSC. When reviewing the local policy on a few
machines, and event logs noticed that the accounts (specifically the SERVICE
account) under "Impersonate client after authentication" was changed to a
domain account.

When checking the domain GPO's using GPMC received the message of
inconsistency with both of the default policies (Domain controllers/Default
Domain) other two test GPO's were fine which are not linked to the domain.
Clicking okay made them consistent again and eventually returned the local
policies on the desktops back to there previous state with the correct
Impersonation settings.  I'm puzzled how the two relate, and why only some
settings changed?

The Microsoft Article 828760 refers to the inconsistency problem with us
running R2 so not sure why we got the problem also. Article suggests client
side processing problems can occur due to mismatch. Desktop clients due have
the 902400 security patch, which can cause the above as stated in 909400,
but these patches have been installed for months without problems until the
inconsistency occurred.

Only other problem occurring around this time was that the forest root DC's
had replication problems, with our DC's being a child domain within the
forest, but can't see the domain GPO's being affected due to this.

Anyone experience this?

TIA

Michael Parkes


***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at http://www.freelists.org/archives/gptalk/
************************

***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at http://www.freelists.org/archives/gptalk/
************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at http://www.freelists.org/archives/gptalk/
************************

***********************
You can unsubscribe from gptalk by sending email to 
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by 
logging into the freelists.org Web interface. Archives for the list are 
available at http://www.freelists.org/archives/gptalk/
************************

Other related posts: