Group Policy, Profiles, and IntelliMirror for Windows2003, WindowsXP, and Windows 2000 (Mark Minasi Windows Administrator Library)

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:

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:

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:

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.

Категории