I was basically trying to restate what I had mentioned before. I will try it in a different way, and I apologize if I am just telling you what you already know. For a policy to apply, there are several factors involved. The first thing is that the GPO has to be applied at a level that affects the OU of the object (be it computer or user). If a policy is applied at an OU level, then the object has to be in or under that OU. The second thing is that the security filtering has to be set so that the object can read the GPO. By default, "authenticated users" can read a GPO and this includes all domain users and domain computers, so this is something that normally "just works" when setup. It is also relevant as to whether the GPO is not overruled by a higher priority GPO or not (conflicting settings) and the aforementioned loopback processing. The last thing, and the thing that I personally found confusing initially, is that a GPO can contain computer settings (things under Computer Configuration) and/or user settings (things under User Configuration). The computer settings apply only to computer objects in that OU, and the user settings apply only to user objects in that OU. Sometimes the settings seem user specific, but are really computer settings--you have to look and see where it falls. If you OU structure is flat, then it is more straightforward. When you are trying to affect a particular user on a particular computer, and the user and computer are not in the same OU, you have to pay close attention to what is in the GPO. You can put both the computer and user settings in one GPO, and then link that GPO at both of the OU's, and it should work fine (assuming none of the things above block the policy). Alternatively, you could put the computer policies in one GPO and link it at the computer OU, and put the user policies in a different GPO and link it at the user's OU. The key thing is that, absent loopback processing, it doesn't matter what computer the user logs onto, the user is going to get *user* policies applied to him/her through the OU under which the user account sits. Likewise, it doesn't matter what user is logging on, the computer is going to get the computer policies from the OU under which it sits. To get back to the earlier thing that I think I saw, though, it looked as if your servers were not being affected by the policy due to security filtering. I can't say whether you should or should not use security filtering in your situation, but the servers need read access to the GPO *if* there are computer policies which must be applied to them. Bill
________________________________ From: Owens, Michael [mailto:[email protected]] Sent: Thursday, May 28, 2009 2:41 PM To: NT System Admin Issues Subject: RE: Group Policy Problem - I've lost all my hair Everyones answers: Richard: 1. All servers can ping all DCs. 2. I do get a 1704 applied succesfully event. 3. It does host both computers, and user policies. I was thinking about redoing the policies after something Bill told me, sometimes they arent so happy. Bill: 1. I am not sure where to find the setting you are talking about here. ( 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.) I was under the impression that the securities applied to whatever I applied them to under either the security filters field, or under delegation tab? Which, I discovered if I try to add something to either of those fields, I get errors. Want specifics? Or should I just recreate the policies from scratch? 2. I will look into loopback after I send this. Tom: When you say enable network browsing... do you mean in the GPO itself? ________________________________ From: Owens, Michael [mailto:[email protected]] Sent: Thursday, May 28, 2009 2:01 PM To: NT System Admin Issues Subject: RE: Group Policy Problem - I've lost all my hair Give me a minute I am trying all these things. Thanks for the help guys. :) ________________________________ From: Richard Stovall [mailto:[email protected]] Sent: Thursday, May 28, 2009 1:22 PM To: NT System Admin Issues Subject: RE: Group Policy Problem - I've lost all my hair One last wild shot in the dark... Can these servers ping the DCs? I saw a pretty large environment one time (several thousand nodes) where Group Policy didn't work because the network team had prohibited ICMP on all the switches and routers because of Welchia. They didn't disable slow link detection beforehand and it completely broke Group Policy. A Nasty little chicken and egg scenario developed because of it. Couldn't use Group Policy because of slow link detection. Couldn't disable slow link detection b/c Group Policy wasn't working. I begged them to allow ICMP just for a few days to get it resolved, but they wouldn't do it. From: Richard Stovall [mailto:[email protected]] Sent: Thursday, May 28, 2009 1:10 PM To: NT System Admin Issues Subject: RE: Group Policy Problem - I've lost all my hair So it looks like DNS and share permissions are probably OK. Do you get a happy scecli 1704 event "Security policy in the Group policy objects has been applied successfully" after gpupdate? What type of settings are in the GPO? User and Computer? You could always try enabling some innocuous computer setting like adding a logon message box and seeing if it propagates. Here is one fix that involved corruption of a user profile, thought I would think it's unlikely in your case since it's happening on 6 different machines. http://msinfluentials.com/blogs/jesper/archive/2006/11/25/group-policy-f ails-for-one-user.aspx From: Owens, Michael [mailto:[email protected]] Sent: Thursday, May 28, 2009 12:49 PM To: NT System Admin Issues Subject: RE: Group Policy Problem - I've lost all my hair No errors on the app log when I run GP update, and yes I can navigate out to the policies folder. ________________________________ From: Richard Stovall [mailto:[email protected]] Sent: Thursday, May 28, 2009 12:11 PM To: NT System Admin Issues Subject: RE: Group Policy Problem - I've lost all my hair What do you see in the app logs of the problem machines when you run "gpupdate /force" on them? Can you browse to \\domaindns.name\SYSVOL\domaindnas.name\Policies <file:///\\domaindns.name\SYSVOL\domaindnas.name\Policies> from the 02-07? 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. ________________________________ 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/> ~
