Group Policy delegation can help. The idea is simple: give someone else the rights to create and/or edit GPOs in the domain, so you don’t have to manage them yourself. One successful strategy for Group Policy implementation is to put the power in the hands of deputy administrators—those who are closest to the users. Before you object, let’s analyze this for a moment.

Ask yourself who knows your users best. Sometimes, the answer is the Domain Administrator. Often, however, it turns out this is really the organizational unit (OU) Administrator, the branch administrator, or some other admin altogether. Let’s call these people (whoever they are) "deputy administrators."

Typically, these deputy administrators don’t have Domain Administrator rights—instead, they’re just average Janes and Joes with a specific task and limited permissions that have been delegated to them. While the Domain Administrators are the only people who can create GPOs by default, these permissions can be delegated to deputy administrators so they can create GPOs, alleviating some of your burden.

It’s quite easy for a Domain Administrator to permit others to create new GPOs. Figure 1 illustrates the basic procedure. In the Group Policy Management Console (GPMC), I click on the Group Policy Objects node, select the Delegation tab, and then click the Add button (at the bottom of the page). Now I add the user who I want to delegate the ability to.

In this example, I anoint Nurse1 (who is a deputy administrator) to create GPOs. Now, just because this deputy administrator can create GPOs doesn’t mean he can actually do anything useful, like link them somewhere. In other words, the simple fact that a GPO has been created doesn’t mean that it’s doing anything or affecting anyone. For that sort of power, there’s another delegation tab, which is found at the level in Active Directory you want to delegate (for instance, the domain or an OU). To truly empower Nurse1, I must grant him the ability to both create GPOs and link them to the Nurses OU.

You’re probably thinking there are some risks in doing this. You’re right. One concern is that these delegated deputy administrators can do very bad things with this new-found power. This is always a possibility, but then you wouldn’t delegate someone to drive your Ferrari unless he took a lesson or two, right? Let’s look at a more specific problem: a deputy administrator who either intentionally or inadvertently hides access to the GPO from the Domain Administrator.

First, note that the person who creates a GPO also owns the GPO. There is a level of trust when you delegate these abilities. Unfortunately, some bad administrators have been known to use their rights inappropriately, performing actions like changing the permissions on the GPO so even the Domain Administrator can’t see the GPO. To my dismay, Nurse1 has turned out to be a rogue administrator. In Figure 2 you’ll see that he has set the permissions on the GPO so that the Domain Admins group is expressly denied all access (even Read access).

Now, when the Domain Administrator looks at the Group Policy Objects node in the GPMC, the GPO is not listed. Note, however, that once Nurse1 links the GPO to a location in Active Directory, the GPO’s properties are viewable, though inaccessible (see Figure 3).

At this point, nothing is technically wrong. The Nurses will get the GPO applied to them and everything will continue to function normally. The only problem is that an unruly deputy administrator is hiding his or her actions from the Domain Administrator. At this point, as the Domain Administrator, I have two options: I can do nothing, allowing the GPO to function as is, or I can perform a Take Ownership action on the GPO and reclaim power.

To understand how a Domain Adminstrator can take ownership of a GPO, it’s important to understand that the Group Policy Objects node in the GPMC is a representation of the two halves of a GPO. It includes the Group Policy Container (GPC), which is the part that lives in Active Directory, and it includes the Group Policy Template (GPT), which is the part that lives in the SYSVOL. In order to take ownership of a GPO, you need to take ownership of both halves.

The GPC controls visibility of the GPO. To take ownership of the GPC, select View | Advanced Features in Active Directory Users and Computers. Next, you dive down into the GPC part of the Group Policy via System | Policies and look for the GUID of the GPO. In this view you cannot see the GUID of the hidden GPO in the left pane, but it is listed as Unknown in the right pane.

At this point, you might be tempted to give the Domain Administrator Full Control rights. But, if you try, it won’t work. You must first take ownership of the object by right-clicking on the Unknown GPC, selecting Properties, clicking on the Security Tab, selecting the Advanced button, and then clicking the Owner tab. Here, you’ll be able to specify the owner, as seen in Figure 4.

Unfortunately, once you’ve taken ownership of the object, you cannot immediately give the proper permissions back to the object. First you need to close the access control list (ACL) editor, right-click on the GPC portion again, and then select Properties | Security. Only now can you actually change the permissions. At this point you can grant the Domain Administrators Full Control rights over the GPC, which you now own (see Figure 5).

Once you’ve granted Domain Admins Full Control over the GPC, it’s time to take ownership of the GPT. The GPT part of a GPO lives on every Domain Controller, typically in the \Windows\system\sysvol\sysvol\domain name\policies directory. (That’s two sysvol directories.) Inside this directory there are directories for each GPO’s GPT. In my example, my GPT has a GUID starting with 0F8D1AD2 (see Figure 4). So I need to locate that directory and take ownership of it in the same way I did with the GPC.

Once you’ve done this, you’ll (again) have to exit the ACL editor and reenter it. Then, as you did with the GPC, ensure that Administrators have Full Control. Though in this case, note that the default permissions should automatically set Administrators (not Domain Admins) to Full Control.

If, at this point, you were to go back to the GPMC and refresh the Group Policy Objects node, you would see the previously-hidden GPO. However, when you click on it, you might get an error message similar to the one shown in Figure 6.

Responding to this message moves you closer to the goal: clicking OK will cause the permissions from the GPC to be copied over to the GPT. The bad news is that, depending on a variety of factors, you might not actually get this message. If you don’t, you have to manually kick-start permissions synchronization between the GPC and GPT.

To do that, click on the Delegation tab of the GPO and click the Advanced button. You’ll be able to edit the actual ACLs of the GPO, which should (simultaneously) affect both the GPC and GPT. Simply make a change (any change) in the advanced properties of the GPO and apply it—even if it’s something temporary. For instance, you can add a new user, grant that user Read access, apply the change, and then remove the new user. The point is to make any change to force synchronization of the ACLs. When you do this, you are writing the ACLs to both the GPC and GPT. Now they’re in sync, and you’ve fixed the problem.

Remember, delegation is a very good thing but only if you trust the people to whom you’re delegating permissions. Unfortunately, you can’t always cover every base, and some deputy admins, somewhere along the line, may get themselves into trouble—whether intentionally or accidentally. But now, if you ever find that a deputy admin has hidden GPOs from the Domain Administrators, you’ll know how to restore permissions and take back control of your GPOs.