I had disabled inheritance on that OU, so the OUs further down the tree should not grab any other policies either, correct? should loopback be enabled or disabled on THIS policy?
________________________________ From: Mayo, Bill [mailto:[email protected]] Sent: Thursday, May 28, 2009 12:54 PM To: NT System Admin Issues Subject: RE: Group Policy Problem - I've lost all my hair If the servers/computers are not included in the security filtering, then the policy will not affect them. Whether or not this is a problem has to do with the policies invoked within the GPO. If all the policy items are user configuration items, then it will make no difference. If there are computer configuration items in the policy, then the security has to be set to include the servers/computers. If you have a mixture, you need to ensure that the GPO applies to the computer(s) and user(s). This is the default; it is only an issue if it has been changed. The other thing I would mention is that you might need to check to see if there are any other policies that invoke loopback processing. When this is in effect (on a computer object), it applies policies from the OU of the computer only (more info at http://support.microsoft.com/kb/231287, if you are unfamiliar with this). Bill Mayo ________________________________ From: Owens, Michael [mailto:[email protected]] Sent: Thursday, May 28, 2009 12:38 PM To: NT System Admin Issues Subject: RE: Group Policy Problem - I've lost all my hair The only security filter I have in place is tied to a security group that the account (lab rat) is a member of. Should I specify the servers in there as well? The server that works is not a member of that security group. ________________________________ From: Mayo, Bill [mailto:[email protected]] Sent: Thursday, May 28, 2009 12:09 PM To: NT System Admin Issues Subject: RE: Group Policy Problem - I've lost all my hair 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. ________________________________ 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. ________________________________ 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/> ~
