I used to find myself amazed at how few IT shops really use Group Policy. 'It's a ten-plus year old technology,' I'd exclaim, 'and it's free with Windows and Active Directory. Why not use it?'

Then I started really interviewing my SMB consulting clients, asking them why they didn't make more use of this no-cost management solution. The answers were surprising to me, although they probably aren't to you.

While Group Policy represents a solid solution for deploying configuration changes, the tools to manage Group Policy are a source of confusion, complexity, and consternation to those I interviewed. They told me Group Policy is great for deploying changes to every user, all at once. It fails, however, when changes must be targeted to specific individuals, or specific computers, or even combinations of users and computers based on special characteristics.

I discovered that while Group Policy is a perfect solution for getting changes deployed, it's far from perfect in validating when those changes should be made. It's simply too difficult to accomplish what should be a simple task.

Those answers got me thinking, specifically about how one might target a Group Policy Object to a set of users or computers. Turns out it really is harder than it looks. Here's what I learned:

Native Group Policy: What You Get

Most of us already know that targeting a native Group Policy Object starts by attaching that GPO to an Organizational Unit. Inside your Active Directory domain are a set of OUs, whose primary job is to segregate computers, users, and other objects for IT management purposes.

Figure 1: A common OU design for user objects.

I've found that a lot of SMB companies construct their OUs in the same way. They put most user objects into an OU named Company Users (see Figure 1), or something similar. Special users, such as those in the IT group, get dropped into a sub-OU of Company Users based on who they are. These special users tend to be exceptionally rare, because rare is the opportunity where separating them out benefits more than keeping them together.

Here's why: Consolidating users into one or two OUs is often necessary because user-focused GPOs must be targeted to OUs full of users. Further, a user object can only be in one OU at a time.

This represents a conundrum. What if I want to assign different settings to that user when they're in a conference room instead of at their desk? What about when they're using a laptop outside the office instead of their on-site desktop? With their one-at-a-time limitation on OUs, user objects aren't terribly flexible for deploying traditional Group Policy settings to users.

As a result, most SMB IT shops end up deploying user settings to their everything-for-everyone Company Users OU. They usually stop there. Any special settings then get distributed through either Computer OU objects, or some other mechanism such as a logon script. This, to me, is a kludge.

The limitation doesn't stop there. Computer objects in Active Directory have that same one-at-a-time limitation on OU placement. Just like a User object, a Computer object can only be in one OU at a time. That means that Don's laptop from the second floor can't be easily directed to the first floor printer as he walks downstairs. This is the case because maybe Don's laptop is in the Janitors OU. That OU placement doesn't change as Don changes floors.

Figure 2: Linking a GPO to a Site object.

Microsoft does provide some ways to get around these limitations. Traditional Group Policy comes with some mechanisms for applying policies in a more dynamic way. The first is by linking a GPO to a Site object. Recall that Site objects correspond to Active Directory sites, which in turn correspond to IP subnets. As you can see in Figure 2, it is possible to assign a GPO to a Site object. Once you do that, any computer or user in that site will receive the policy.

This solution is great if your AD Sites are perfectly matched with your subnets, and each Site/subnet combo is perfectly matched with the boundary for whatever GPO setting you need to apply. In Don's case, the first floor and second floor would require different subnets; each subnet would need its own Site assignment in AD. That's a lot of extra effort, particularly when you consider you're performing intensive AD design when all you really want is better validation logic.

Figure 3: Creating a new WMI Filter.

A second option is to use a WMI filter to validate some characteristic inside the computer's WMI database. Here, the GPO is only applied to objects in an OU when those objects' WMI filter validates true. Figure 3 shows a WMI filter that queries the Win32_IP4RouteTable class for a number of properties. You can see in this image that the Mask, NextHop, and Destination properties must return back correctly. When they do, the settings will get applied to whatever object receives the GPO.

At issue here, as you can easily see in Figure 3, is the sheer challenge of scoping those WMI properties correctly. For example, is the Win32_IP4RouteTable class the right place to query, or is it Win32_NetworkAdapterConfiguration? Is there GUI exposure for this WMI data that will help decide which values you need? If you're not a master at WMI query building via WQL, then you're in for a long time in studying and testing.

While both of these options indeed work for targeting, it seems to me that neither really provides a manageable solution for solving the problem.

Validation Logic: What You Want

So, let me dream for a minute about a better solution. As I dream, let's think about the kind of validation logic features you and I both want out of a perfect Group Policy solution. That perfect solution would allow me to deploy settings to users and computers, with no real limitations on the types of settings deployed. Might I want some of the following capabilities?

Easy custom configuration. Inside native Group Policy are settings for virtually every configuration of Windows. You can lock down Internet Explorer and the Windows shell, as well as pretty much every service that's on the box. Native GPO settings are limited to those that Microsoft provides, those that lock down Microsoft products. If I have software in my environment from other vendors (and who doesn't), locking down those pieces of software can be somewhat challenging. My first requirement for a perfect solution will be one that delivers an easy-to-use GUI for creating custom configurations. With one, I can lock down WinZip, or Adobe Acrobat with the same ease I can today with Internet Explorer.

Very specific targeting. A perfect solution can also target a setting down to a set of highly-specific conditions. For example, if I have a configuration for a home-grown application, I probably want my settings to be deployed only to computers where that application resides. I may also want to limit those settings to specific classes of computers (laptop vs. desktop vs. server), OSs, or other characteristics. These need to be very detailed. Any kind of data stored about a user in Active Directory or a computer in WMI should be available for targeting.

Easy targeting. Knowing I can target to specific characteristics isn't useful unless I can actually lay my hands on it. That's the problem with native Group Policy: It works, but it's just too difficult. Another feature I want is targeting that doesn't require scripting or complex query statements. I want to select from a range of useful options and insert constraints which are guaranteed to work. I want the tool to validate those constraints for me. That way I'll know beforehand if I've created targeting rules that won't work.

Dynamic targeting. I also want those settings to change as my users move about. That is similar to the Don's example above where he moves from the second floor to the first. But it can also be as users change locations, or move from their desktop to the conference room. I want all my settings to be dynamic with what's going on in my users' real-world work lives.

Multiple targeting. In a dynamic world, I also need the ability to span across multiple targeting options. I want users to be automatically redirected to a different printer when they're on a different floor, but I might also want to limit that redirection to certain times of the day. I might also want different groups to get different settings, so I can lock down certain company assets as I need.

A Better Group Policy Might Get Used

All of these represent things I want out of that better Group Policy solution, but they're not the only things in my list. I can think of a few other useful features I'd want in a complete solution. One that works for me might allow me to deploy software or updates using the same validation logic and targeting characteristics as for settings. Such a solution might also come with a library of common configurations that I will probably want configured. That way I won't install the solution, only to be greeted by an empty database and blank screen with lots of promise and little up-front assistance.

Solutions like the one I want are out there. While some of these capabilities are indeed built into Group Policy itself, using them requires advanced-level coding or scripting most SMB IT professionals don't have the time for. That's the real gap between 'Group Policy is free!' and 'We use Group Policy!' in my conundrum that started out this article. Without the management tools to deploy settings exactly where I need them, having those settings isn't terribly useful.