Overview

Windows policy constraints come in a dizzying array of forms. Traditional Group Policies can be constrained through Organizational Units and WMI filters. Group Policy Preferences have a much different look-and-feel, relying on OU assignment in combination with Item-level Targeting.

Complicating the landscape even further are the policy tools used by third party solutions. Call them policy permissions or validation logic, the end-goal is the same: Locking down a policy to a specific set of users and computers.

Each method of constraint comes with its own instances, items, or validation types. Group Policy can be constrained by (nearly) any value that can be addressed in a target computer's WMI store. Group Policy Preferences adds 24 additional targeting items to WMI queries for limiting where a GPP gets deployed.

With so many options available, finding the useful ones can be the hardest part. With an entire database of WMI characteristics at your disposal, the challenge is in pairing constraints with the policies you intend to deploy. In this article, I'll show you five especially-useful constraints for policies you'll want to implement. I'll leave creating the actual policies to you, but I'll show you how to tailor their targeting to just the right users and computers.

Constraint #1: Adjusting Power Options based on Time of Day

Limiting the power consumption of Windows computers is a task that hasn't been easy in the past. Most of this difficulty hasn't been directly related to the power options themselves. Rather, figuring out ways to apply different power options at different times of day is where the real challenge lies.

Why? Limiting Windows' power usage is best done using a stepped approach. Turning off monitors after a few minutes of activity is one initial and obvious tactic; although today's LCD monitors limit the efficacy of this practice. They're already low in power consumption, particularly in comparison with the power-hungry CRT monitors of yesteryear. Layering additional steps presents greater power savings, such as spinning down hard drives, altering power options, and ultimately sleeping the computer.

Yet these additional steps can create user impacts if they're invoked too quickly. While sleeping a user's computer reduces its power to near-zero, doing so also requires a multi-second restart (with associated user complaints) every time a sleep is invoked. Even spinning down a hard drive adds a couple of seconds, and a bit of user irritation.

Figure 1: Targeting Items for Power Options.

Reducing the user impact of power-reducing tactics requires adjusting how quickly each invokes for different times of day or days of the week. Figure 1 shows an example of targeting items for a Power Options GPP that's designed to accelerate the move to lower power states. That accelerated move is targeted to occur only between the hours of 5:00PM and 8:00AM during the week and all day on weekends. This GPP might, for example, set computers' power options to Power Saver and adjust the number of minutes until the computer sleeps to only a very few.

A second GPP is necessary during business hours. That second GPP would return power options to High Performance and adjust the sleep timeout to a much larger value, essentially reversing the settings of this first policy.

Constraint #2: Mapping Drives by Group Membership

Mapping drives has been a login script pain since the invention of logon scripts. While scripts work well when drive mappings remain static, they get more complicated when drives require dynamic attention via Active Directory Global Groups.

The Drive Maps GPP helps you get rid of those nasty logon scripts. Using a drive map in combination with a targeting item enables you to link mapped drives with, for example, group membership. Figure 2 shows an example of that linkage. In it, a GPP has been created and targeted only to those users in the COMPANY\Finance group. Pointing this GPP to an OU of users delivers a dynamically-mapped drive to just those in the appropriate group.

Figure 2: Drive Maps by Global Group

Constraint #3: Direct Application Installs to the Proper Processor Architecture

Both GPPs and traditional Group Policy use the data in WMI to build constraints. GPPs and their Targeting Editor might look different, but each targeting item is in fact a WMI query in disguise. Traditional Group Policies don't have the same easy-to-use interface. If you want to constrain a Group Policy, you're forced to build that WMI query yourself.

If the Targeting Editor with GPPs has you confused, plan on an even greater challenge with Group Policies and their WMI queries. The reasons are many: WMI queries must be entered in syntactically-correct textual format, similar to Figure 3 above. Validating that WMI queries actually work also requires careful sleuthing. When queries aren't properly created, their associated GPOs simply won't deploy. Figuring out why is left to you.

Figure 3's WMI filter instructs the GPO to look in WMI's Win32_OperatingSystem class for the Version, ProductType, and OSArchitecture properties. If a targeted computer's WMI data corresponds to an x64 version of Windows 7, then the policy will apply.

Figure 3: A WMI Query for a Group Policy.

That first policy will get you started. If it's the x86 version of Windows 7 you're looking for, you might update the WMI query to look like this. Notice the strategic addition of the NOT operator:

select * from Win32_OperatingSystem WHERE Version like "6.1%" AND ProductType="1" AND OSArchitecture = "64-bit"

Constraint #4: Adjusting Internet Explorer Behaviors when Outside the Office

Internet Explorer is an application that's great to use and horrible to centrally manage. The reason for that difficulty lies with the native Windows' tools for central configuration. IE's configurations are spread across Group Policy's modules, its administrative templates, and now also GPPs. Some settings are found in each, while none have an entirety of control over all IE's settings.

This scattering of settings means locking down IE requires a lot of up-front planning. One place you might start is the User Configuration GPP called Internet Settings. Configuring Internet Settings exposes a mock-up of Internet Explorer's Internet Options screen. Configuring options in this mock-up will do the same when the policy is applied on a targeted computer.

Unfortunately, not every IE experience is the same. Many of Internet Explorer's settings should be different depending on what network the user connects from. You know the problems: A user whose IE home page is set to your company's intranet web server will experience an irritating timeout when IE gets launched outside the LAN. Proxy server and other settings should also be adjusted so IE can operate without delay whether users exist inside the LAN or outside.

Figure 4: An IP address range targeting item for IE.

A pair of GPPs assists with this reconfiguration. The first GPP can be built to configure IE with the on-the-LAN settings, with the second being used only when that machine leaves the LAN. Figure 4 shows how subnets are identified for an example on-the-LAN GPP. In it, an private range of 192.168.0.1 through 192.168.0.254 has been entered to target the on-the-LAN GPP. Like with the others in this article, configuring a second GPP with different targeting selections will complete the configuration when the computer leaves the network.

Constraint #5: Limiting App Lockdowns and Environment Variables to Installed Applications

Smart IT pros know that most applications store their configuration data in the registry and within environment variables. They also know that it is possible with many applications to set those environment variables and registry entries using GPPs. By setting these configurations via a GPP, applications can be locked down to exactly the settings your users need.

The hard part is in finding the mapping between buttons you click in the application and their resulting registry keys and values or environment variables. Using a registry scanning or application packaging tool can assist, as can manually watching the registry as you make configuration changes. Once you've found the registry value or environment variable to change, enforcing it is easy via an Environment or Registry GPP.

Any time you're using GPPs to enforce application configurations it's a good idea to ensure that GPP only applies when the application is actually installed. You won't want to create registry values or environment variables on computers that don't need those changes. Thus, limiting your GPPs via a File Match targeting item can often be a smart idea.

Figure 5: A File Match targeting item.

Figure 5 shows what an example File Match targeting item might look like. In it, the GPP is told to look for the file abcApp.exe. If that file exists, then the GPP is applied. When the file doesn't exist, the GPP gets ignored and the computer remains unmodified.

Wouldn't Unified Targeting be Great?

While Group Policies and GPPs both use WMI information as their basis for targeting, these two technologies were implemented separately. You can't use a targeting item with a Group Policy, though you can use a WMI query with a GPP. Even so, WMI queries with GPPs still look much different than do they inside regular Group Policies. This unnecessary complexity should beg the question, 'Wouldn't a single and unified solution for targeting configurations be a much better idea?' You're not alone in thinking this. Third party solutions available on the market today provide the same level of configuration control as Group Policies and GPPs, but with a much better targeting experience.

If it's a unified solution for defining, managing, and auditing your configuration's validation logic, look outside Windows for additional functionality.