If a policy applied at the OU level is not affecting all the computers
in the OU, the first thing I would suspect is that security filtering is
in place.  Have you confirmed that the Security Filtering section shows
Authenticated Users having (read) permissions to the policy?  You may
have to go to the Delegation tab to see all the permissions applied.
 
Bill Mayo

________________________________

From: Owens, Michael [mailto:[email protected]] 
Sent: Thursday, May 28, 2009 12:03 PM
To: NT System Admin Issues
Subject: Group Policy Problem - I've lost all my hair



All-

I seem to have a problem with GPO replication. I think. I am not really
sure what the problem is - it just confuses me at this point. Here is
the deal.

I have a 7 server TS farm. They all run server 2008 64 bit edition, but
I believe the problem is something with our DCs. Our domain is 2003.

 Server 1 has the licenses, and distributes them out accordingly. I
added a GPO to it, to lock them down. All servers are in the same OU,
and my test account is in a different OU with the same GPO applied to
it. The servers are named STUCTX0x. STUCTX01 takes any group policy
change I give it. If I change the GPO, and run a gpupdate /force...
STUCTX01 takes the GPO when I log in on my test account. (lab rat) On
STUCTX02-STUCTX07 it doesn't work. I logged onto the DC, and used the GP
modeling wizard to simulate logging onto STUCTX02 with lab rat. It says
it will pull the correct policies. So, I logged onto STUCTX02 and did a
"gpresult /user lrat /v" It gives me "INFO: The user "lrat" does not
have RSOP data."

When I do that on stuctx01, it pulls the correct policy. Replication
otherwise on the domain controllers appear to be working correctly. How
do I get it to apply to all of the servers in that OU? Everything looks
right to me, and I do not even know what to look at next! 

 

Thanks guys, 

Mike

 


________________________________

This message, and any response to it, may constitute a public record and
thus may be publicly available to anyone who requests it in accordance
with Chapter 149 of the Ohio Revised Code.


 

 


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to