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

Overview

Working with Group Policy isn't always a bed of roses. Sure, it's delightful when you can set up GPOs with their policy settings from upon high and have them reflected on your users' desktops. However, when you make a Group Policy wish, a specific process occurs before that wish comes true. Indeed, the last chapter discussed when Group Policy applies. Now you understand the general rules of the game and when they occur.

But what if the unexpected happens? Most specifically , it's difficult to determine where a policy setting comes from and how it's applied. Or, if Group Policy isn't working, why not, and what the heck is going on? Additionally, you're usually after whom to blame, but that's actually something that auditing (discussed in Chapter 6) can help with. For additional information on third-party tools, see the Appendix.

A user might call the Help Desk and loudly declare, "Things have just changed on my desktop! I want them back the way they were!" Okay, sure, you want things better too. But a lot of variables are involved. First, there are the four levels: Local Group Policy, site, domain, and each nested OU (so perhaps even more levels). Then, to make matters worse , what if multiple administrators are making multiple and simultaneous Group Policy changes across your environment? Who knows who has enabled what Group Policy settings and how some user is getting Group Policy applied?

Additional factors are involved as well. For instance, if you have old-style NT 4 System Policy, things can be particularly complex. Or perhaps you have a Windows 2003 forest, with cross-forest trusts to another Windows 2003 forest, and users are logging in all over the place. Not to mention a whole litany of things that could possibly go wrong between the time you make your wish and the time the client is expected to honor that wish.

Here's a foretaste of what to expect while troubleshooting GPOs:

• Disabled GPOs If the GPO is disabled or half the GPO is disabled, you need to hunt it down.

• Inheritance Troubles Between local, site, domain, and multiple nested OUs, it can be a challenge to locate the GPO you need to fix.

• GPO Precedence at a Given Level With multiple GPOs linked to a specific level in Active Directory, you might have some extra hunting to do.

• Permissions Problems Ensuring that users and computers are in the correct site, domain, and OU is one battle; however, ensuring that they have the correct permissions to access GPOs is quite another.

• Windows XP Processing Windows XP changes the way GPOs are processed . And Windows XP with SP2 changes things even more with cross-forest trusts.

• Replication Problems The health of the GPO itself on Domain Controllers is important when hunting down policy settings that aren't applying.

• Slow Links You've rolled out your RAS (Remote Access Service). Now how and when are your clients going to process GPOs?

These are just a few places where you might encounter trouble. Between various client types with different processing behavior, these problems and the occasional solar flare make things crazy. Troubleshooting can get complicated. Fast.

In this chapter, we'll first dive into where Group Policy "lives" to give you a better sense of what's going on. We'll then explore some techniques and tools that will enable you to get an even better view of why specific policies are being applied.