GPO in one OU, affect computers in another

OK, the title probably made no sense...

I need to run a shutdown script that installs an exe on a couple hundred machines at our branch office.

In my AD setup (just a test VMware box right now) I have created an OU called 'Test' where I applied the GPO. Now, if the computers are inside this OU, the GPO gets applied to them, the script runs on the computer during shutdown, everything is good.

But, when we hit the production network, we don't want to move these computers into a new OU just to make this work. We also don't want to roll out the GPO on ALL the computers at once, just select ones to start. Slowly we'll be adding computers about 30 at a time.

I created a security group and put it in the Test OU where the GPO is applied. I've added the computers in the default 'Computer' container to this security group. The computers do not get the GPO applied to them.

Under the GPO Security Settings (looking under 'Delegation Tab --> Advanced) I have the security group with ALL permissions set, except 'Full Control', 'Special Permissions', and obviously I don't have any Deny ones checked.

I'm 3 weeks on the job here. It's a lot of fun, but obviously I didn't learn everything I needed in school :) I've been fighting with this for a while, is there anyone here who can shed some light on it for me? Any help would be greatly appreciated! I'll continue googling around too, maybe I just haven't put in the right search strings yet.


Thanks so much!


Dave

Well, let me open up with GPO processing can be very confusing. I personally hate the whole "Last Write Wins" schema.

With that being said,
Is this "Security Group" inside your "Test" OU linked to the GPO? Does this GPO need to be enforced? . How many GPO's are being applied to this "Test" OU? (Sorry about the questions, just trying to understand your setup)

Also, I know there's a setting that can determine exactly which Users/Computers etc. will be allowed to process the GPO (towards the bottom screen when you've highlighted the actual GPO itself).

Can you elaborate a bit more as to the setup?

Sorry for the delay, I'm back from the weekend now.

Alright, thanks for the response ShagDevil.

Right now, the Test OU only has the one GPO assigned to it. The only other GPO is the 'Default Domain Policy' on the domain itself, which I haven't touched.

The GPO I'm working with is linked to the Test OU, I can see that in the Group Policy Management interface. It also says Enforced and Link Enabled.


The setting I think you're talking about is the "Security Filtering." Right now it's set to 'Authenticated Users' and also the security group I created. (This is under the 'scope' tab.)


Thanks for your help, I'm still playing around trying to figure this out.



Dave

Going off ShagDevil's hint about the linking... I played with the Group Policy Modeling, which showed me that the Test OU's GPO was not being applied to them. I thought that just having the Security Group inside the Test OU was enough to have the member client computers have the GPO applied to them too, even if they're outside of the OU.

So, I linked the GPO to the domain, not just the Test OU, and the GPO is now being applied to the computers. I guess this is technically a workaround? Or is there still a way to have the GPO assigned to the group computers more directly?


I'll try to illustrate this:

My active directory:

DaveTest.local
--> Computers
-------> All my client computers, who are members of security group 'lockdown'
--> Test (OU)
-----> lockdown (the security group, who has the client PC's as members)
-----> My GPO with the Shutdown script, linked to this OU

My GPMC:
Forest
-Domains
-->DaveTest.local
----->'Default Domain Policy' (I linked the Test OU GPO here which made it work, but originally it wasn't here)
----Test (OU)
------>My GPO


Does that make sense?

EDIT: Never mind, now even if I pull a client computer out of an OU, the GPO still gets applied to them. (Even if they aren't in the security filtering either...) So back to square one I guess :)

EDIT 2: OK, I played with the Security Filtering. I removed the 'Authenticated Users' and left only the 'lockdown' security group, now it seems to be working. So is this the correct way? Do I really have to link the GPO at the domain level as well? not just the OU with the security group in it?


Thanks! :)

Quote:

---

The GPO I'm working with is linked to the Test OU, I can see that in the Group Policy Management interface. It also says Enforced and Link Enabled

---

Ok. First it should process your Default Domain Policy, then this GPO linked to your "Test" OU. And even though you have a nested "Security Group" OU, your GPO should still apply because it's the only GPO being processed.

You know, before we go any further. When you added this "Security Group" OU, to your '"Test" OU, did you happen to run "gpupdate" on the computers added to this new group (before testing the script)?

I just read your most recent reply and it's still possible that "gpupdate" could be the culprit. Depending on when your systems refresh their policies.

OK, thanks for the reply. I just did my second edit.

Yes, I've been running 'gpupdate /force' on the clients before I reboot them.

So again with my second edit before I noticed you'd replied:

I played with the Security Filtering. I removed the 'Authenticated Users' and left only the 'lockdown' security group, now it seems to be working. So is this the correct way? Do I really have to link the GPO at the domain level as well? not just the OU with the security group in it?

Quote:

---

Do I really have to link the GPO at the domain level as well? not just the OU with the security group in it?

---

No, you shouldn't have to. You should be able to apply your GPO without linking it to the domain.

Ok, let's keep at it. Another question, is your Default Domain Policy also being enforced?

Thanks!

Ok, yes, when I run the query in the Group Policy Modeling, it shows the Default Domain Policy is being enforced. When I unlink the GPO from the domain level, that GPO is no longer being enforced on the client.

No problem.

Listen, I have to run out to lunch but, I'll think about this a bit and get back to you.

I'll leave on this thought; My guess is that your Default Domain Policy is probably overwriting any settings in your "Test" OU GPO (or vice versa?). I always get a bit confused when it comes to enforcing multiple policies. :what:

Keep me up to date!

Any luck as of yet?

Hey, still nothing so far. We tried recreating it from scratch, maybe something was missing, but that didn't work either. I just wish there was a more verbose log somewhere showing exactly what's happening with the policy application. Everything works fine if we move the computers to the Test OU, but without them in there, it refuses to apply our GPO. We're playing with different permissions right now as well, maybe we missed something there.

I'll let you know if we figure anything out.


Thanks for the help!


Dave

Alright, keep me posted because I'll undoubtedly run into this issue someday and I'd like to understand exactly what's going on.

The one thing I was thinking is this. Use your Default Domain Policy for all other systems. Then use the Block Inheritance option on your "Test" OU. And link the GPO you created to "Test" OU. This should at least separate the two policies.

Just make sure that your Default Domain Policy is not enforced, as I'm fairly sure that will override any Block Inheritance options.

We just talked with our windows administrator, he doesn't think it works the way we're trying to do it. He says the safest way is to just create a sub-OU under the main container where the computers sit, and apply the GPO there. That way the GPO's move down from higher levels, and the sub-ou adds to them. (The sub-ou gpo will have highest priority, then the OU above it, etc all the way up to the default domain gpo.)

This is what our windows admin does, so maybe that's the only way to get it working. I figured it would be possible to apply GPO's to a group in one OU to affect computers in a higher OU, but maybe it's simply not possible after all. Maybe this is because of possible complications, what if the computer is part of multiple groups in multiple OU's, it would make figuring out the effective GPO setting a lot more complicated.

So as of now, I will stop working on the group thing, I'll fall back to the sub-ou solution for now. Unfortunately I just don't have that much time left to play around. Hopefully I can get a test box setup and home and I can play with it on my own time.

Anyways, thanks for the help ShagDevil, I really appreciate it!


Dave