View Blog

Jul 2013
09

To BLOCK or NOT to Block.. That is the Question !

I got this fun email from Mads Lomholt from the Oslo Norway Norwegian Fanclub of GPanswers.com. (I didn’t know we had a Norwegian fanclub branch of GPanswers.com, but I’m super happy to learn it’s alive and doing well!)  Here’s his question (and my answer!)

Mr Moskowitz! ? Do you take requests?

Is there any situation where blocking inheritance of GPOs (often followed by enforcing GPOs which are higher) is a good and lasting solution?

I am not an expert on this, but so far I have seen only bad things happen when people dive into blocking and enforcing GPOs.

To a certain extent I believe I understand the principles, but why not craft the OU structure to account for this instead of blocking/enforcing?

I’ve read that Microsoft states: “It is recommended that Enforced and Block Inheritance be used sparingly”, Okay. Sure.

Excited to hear the expert judgment of my question!

Mads Lomholt
Norwegian fanclub, Oslo ?

Jeremy’s answer:

Mads:
Great question. Let’s clarify some items.
First: You don’t / can’t block inheritance of ONE GPO. People sometimes think that blocking is about a particular GPO. It’s not. Its about saying “From this point onward, we’re starting fresh and ignoring GPOs before this point.”
So, said another way, when you Block Inheritance upon an OU you’re starting fresh and saying that you don’t want policy setting (higher than here) from affecting your users or computers.
However, what’s also true is that you cannot block any GPOs where their links have the Enforced property. This means any GPO’s links that are enforced will always “make it through” any Block Inheritance.
So, when is Blocking Inheritance on an OU good? Well, anytime you want to “break free” from GPOs set higher up. I usually recommend Block Inheritance as a GOOD THING when OU administrators are really totally in charge of their own Group Policy desires.
For instance, in the domain, lets say Company X has:

  • North Sales OU
  • East Sales OU
  • All of Marketing OU
  • All of Research OU
  • Other OUs…

Let’s assume that the administrators in the company are:

  • Fred: OU admin, manages North Sales OU (and nothing else).
  • Mary: OU admin manages East Sales OU (and nothing else).
  • Gary: Domain admin, manages the domain AND “All of Marketing OU” and “All of Research OU” and some other OUs.

Gary might make some decisions at the domain which would affect Fred and Mary.

If Fred and Mary basically are allowed to “do their own thing” and don’t really answer to Gary, then they should Block Inheritance to create a clean slate for their OUs.
But, if there’s something REALLY important (like a security setting which should affect everyone) then Gary is able to link it to the domain and Enforce it, which will definitely affect everyone.

So, that’s a GOOD reason to use Block Inheritance.

However, going back to your original question: I often see Block Inheritance used way, way too much. And, as such, I see the Enforced property used way, way too much.

I would agree: designing first to try to avoid a lot of blocking and enforcing is ideal whenever possible. But in my case above there are perfectly fine times to use it.
Additionally, it should be noted that if administrators are well versed in Group Policy Preferences, then Item Level Targeting feature can be used to usually avoid Block Inheritances and subsequent enforces.

That’s because you’re specifically targeting WHICH users or computers should get whatever setting you want. (Note that PolicyPak ALSO hooks into the Group PolicyPreferences Item Level Targeting as seen in this demo https://www.policypak.com/videos/sn6j7q1clmq.html. So in this way you don’t have to have lots of weird design just to manage applications’ settings via Group Policy).

So, Mads, I think basically you answered your own question. You saw that having lots of blocking and enforcing cannot be good. But you also saw (I think) that there would be some times where you couldn’t architect around it.

I hope this article helps you and others out.

Thanks !

Comments (0)

No Comments!