Under the Hood of Group Policy

As stated in Chapter 1, Group Policy scope really has four levels: Local Group Policy and then the three levels of Active Directory-based Group Policysite, domain, and OU. When troubleshooting Group Policy, one approach is to first get a firm understanding of what's going on under the hood. As a kid, I took things apart all the time. My parents went mental when they came home and the dishwasher was in pieces all over the kitchen floor. It wasn't broken; I just wanted to know how it worked. If you're like me, this section is for you.

Inside Local Group Policy

Remember that a GPO is manipulated when someone walks up to the machine, runs the Local Group Policy Object Editor ( Gpedit.msc ), and makes a wish or three. Remember that there is only one local GPO on a machine and that local GPOs affect everyone who logs on to that machine.

Where Local Group Policy Lives

Once wishes are made with Gpedit.msc and a Local Group Policy is modified, the Local Group Policy lives in two places. The first part is file based, and the second part is Registry based:

The File-Based Part of Local Group Policy The file-based part of the local GPO can be found in c:\ windows \system32\grouppolicy . The file structure found here mirrors the way the file-based portion of an Active Directory-based GPO stores its stuff. This is good news, as it makes understanding the two types of GPOs (local versus domain-based GPOs) nearly equal.

Note	Feel free to inspect the c:\windows\system32\grouppolicy folder, and then jump to the "Group Policy Templates" section later in this chapter to get the gist of the file structure. Note, however, that not all the structure may be present until the local GPO is edited.

The Registry-Based Part of Local Group Policy Nothing is particularly special about Local Group Policy in regard to the Registry. You'll see later in this chapter in the "Where Are Administrative Templates Registry Settings Stored?" section how to get more information on where the results of Group Policy reaction are seen.

Three Use-At-Your-Own-Risk Local Group Policy Tips

Here are two tips that you are welcome to trybut use at your own risk. I cannot vouch for their validity or soundness, so you're on your own.

Tip #1: Ensure that admins (and other users) avoid Local Group Policy. Perhaps you've set it up so that your users do not have access to the Start ˜ Run command. However, when you're logged in as the local administrator, you want the Run command. The JSI FAQ site has a tip ( www. jsiinc .com/subVtip5600/rh5619.htm ) that tells you how admins (and other users) can override Local Group Policy. However, this tip is valid only when the workstation isn't a domain member.

Tip #2: Reset Local Group Policy to the defaults. If you've set up a Local Group Policy and want to restore it to its default configuration, there's no easy way. However, my good pal Mark Minasi has a newsletter (#32) on the subject. Track it down at www.minasi.com/archive.htm . Even Mark admits that this solution might not be totally complete.

Tip #3: Copy a Local GPO from one computer to another. If you have the need to replicate out a Local GPO from one machine to another, it's possible (but not totally advisable). You could simply copy the files contained within %systemroot%\system32\Group-Policy from the source machine to the target machine. But note that not everything may come over. Scripts and Administrative Templates might come over, but other stuff may not. In short, if you try this trick, be sure to test the results to make sure all the stuff you want to come across does come across. As you're performing this tip, be sure that you also hand-modify the gpt.ini found in the root of this directory. In short, make sure the number present here is greater than the number found in the gpt.ini of your target machines. As you'll learn later, the gpt.ini houses the "Version Number" of a GPO. If you don't set the Version Number higher than what is already present on the target computer, the Local GPO engine doesn't know anything has changed, and hence you won't see the updated settings. You can learn more about the Version Number and gpt.ini file a bit later with regard to Active Directory GPOs.

Inside Active Directory Group Policy Objects

Here's the strange part about Group Policy (as if it weren't already strange enough). Chapter 1 discussed how creating a GPO really involves two steps. First, the GPO is written in the Group Policy Objects container, and then it is linked to a level site, domain, or OU. So, we know that GPOs don't really "live" at the level where they're linked. Specifically, all GPOs live inside the Group Policy Objects container in the domain. That is, they're always kept nestled inside this container yet are logically linked (but not stored) to the other levels to which they point. I referred to the GPOs we created as swimming around in a virtual pool within the domain.

So far in our journey, we created four new GPOs:

"Hide Screen Saver Tab," which we applied to the Default-First-Site- Name site
"Hide Desktop Tab," which we applied to the Corp.com domain
"Hide Settings Tab / Restore Screen Saver Tab," which we applied to the Human Resources Users OU
"Prohibit New Tasks in Task Scheduler," which we applied to the Human Resources Computers OU

We can check in with our concept of these GPOs as floating in a swimming pool within the Group Policy Objects container as shown here.

As you can see, the GPOs never "live" at any level in Active Directory. They aren't really stored at any particular level, although it might appear (using the old-school interface) that they are.

To reiterate, if you leverage a GPO that is supposed to affect a site, an OU, or even a domain, the GPO itself is not stored directly at that level. Rather, the GPO is simply linked to the level in Active Directory. When a GPO is called to be used, it has to request a Domain Controller to fetch it from the Group Policy Objects container and pull the information out.

Each time you create a new GPO, it's born and placed into the swimming pool within the domainready for action if linked to a level in Active Directory. You can reuse a GPO at multiple levels in Active Directory simply by linking it to another level of Active Directory.

So, when GPOs are created for use at the site, domain, or OU level, they're always created within the domain swimming pool, the Group Policy Objects container, where we just link to the GPOs we need when we need them.

Group Policy Objects from a Site Perspective

Site-level GPOs are a bit unique. If you used (or continue to use) the old-school interface via Active Directory Users And Computers to dictate a site-based GPO, you might be in for a world of pain. By default, all site-level GPOs created using the old-school interface will live in the Group Policy Objects container of the Domain Controllers of the root domainand only the root domain, that is, the first Active Directory domain brought online. Then, every time a GPO meant for a site is called for use by a client system, a Domain Controller from the root domain must fetch that information. If the closest Domain Controller from the root domain is in Singapore, so be it. You can see where the pain could get severe.

If you continue to use the old-school interface, you have two choices if you want to mitigate the pain when using site links:

Bring a replica Domain Controller from the root domain closer to your users in each site. For instance, if your root domain is in Singapore, but you have placed many site GPOs on the New York site, place a replica Domain Controller from the root domain in Singapore into the New York site. That way, when the site GPOs replicate from the Domain Controllers in Singapore to your one root Domain Controller machine in New York, a copy of those site GPOs will be present on a root Domain Controller you placed closer to the user .
The second option is a bit more roundabout, but helps guarantee speedy delivery of site-based GPOs. Indeed, in Chapter 1 this is the way the GPMC forced us to create our "Hide Screen Saver Tab" site-linked GPO. The goal of this option is to plant the GPO in the domain of your choosing, not the default location of the root domain. Follow these steps to do so:
1. Figure out from which domain users should request the GPO. For instance, if you want to create GPOs to be used on your New York site, make sure that the domain that the GPOs "live" in don't contain Domain Controllers across a WAN link. You want to select a domain with Domain Controllers that are available to service your users. You need to consider which exact domain you create a GPO in, making sure that appropriate DCs are near the physical systems and users that will implement the GPO.
2. In that domain, create a GPO linked to the domain. Call it whatever you want, and modify the GPO as you see fit.
3. Remove the link from the GPO you just created in the domain. In the old-school interface, you would do this by clicking the Delete button and then selecting "Remove the Link" from two possible options. Remember that by removing the link, you're not deleting the GPO; rather, you're just deleting the link. Once you do, the GPO is just floating freely in the swimming pool of the domain but not being used by anyone .
4. Use Active Directory Sites And Services, and add a link to a GPO. This will let you add a link to the GPO in the domain you created.

Again, the GPMC basically forces us to create site-based GPOs this way. As you saw in Chapter 1, we first create the GPO in the Group Policy Objects container. The idea is to create the GPO in the domain that makes sense and is closest to where the site-linked GPO will be used. Then, once we expose the site, we just add a link to our existing GPO, which is already in the domain swimming pool.

Warning

Remember, by default, only members of the Enterprise Administrators group (or members of the Domain Admins group in the root domain) can create new site-level GPOs or link to existing GPOs from the site level. Optionally, this right can be delegated.

Group Policy Objects from a Domain Perspective

Since we know that all GPOs are just hanging out in the Group Policy Objects container waiting to be used, we can take this one step further. That is, even those GPOs linked to the domain level aren't exempt from having to be " fetched ." When clients use domain-linked GPOs, they have to make the same requests and "ask" the Domain Controller for the GPOs that apply to them.

This is usually not a problem; the Domain Controller doesn't have far to go to get the GPO in the swimming pool to apply it to the domain. But this is precisely why doing cross-domain GPO linking is so slow and painful (see the following sidebar). For instance, in an environment with multiple domains, it might appear to be easier to recycle an existing GPO that lives in another domain. But when it comes time to grab the information inside the GPO, it needs to be brought back all the way from Domain Controllers in the originating domain. Again, this cross-domain GPO linking is very, very painful and should be avoided at all costs. In the Appendix, I describe how to copy GPOs from one domain to another. This avoids the problem altogether because there's no "penalty" for creating a copy from a source domain and then having the copy live in your domain.

Group Policy Objects from an OU Perspective

Since GPOs live in the Group Policy Objects container at the domain level, a distinct advantage is associated with the way Group Policy does its thing: It's tremendously easy to move, link, and unlink GPOs to the domain and/or its OUs. You could, if you desired, simply unlink a GPO in the domain or OU and link it back to some other OU. Or you could link one GPO to the domain and/or multiple OUs.

It's typical and usual that you'll use OUs to apply most of your GPOs. If GPOs live in the Group Policy Objects container swimming pool, it's easy for multiple, unrelated OUs to reuse the same GPOs and just create new links to existing GPOs.