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 up on 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 previous 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? More 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’s going on? Additionally, you’re usually after someone to blame, but that’s a task that auditing (discussed in Chapter 8, “Implementing Security with Group Policy”) can help with.
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 (and potentially multiple local GPOs in Windows Vista and later), 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 ...