Geek of All Trades: The Curiosity that Killed the App

There are plenty of free tools out there that help you control your infrastructure, so why aren’t you using them?

Greg Shields

“Free tools.” That phrase is bound to get your attention. If you’re like most average IT pros, you’re constantly on the hunt for no-cost solutions to do your job. That saves hard-won budget bucks for your other projects.

The search makes sense. Management tools can be expensive. They’re sometimes hard to justify when the only person clearly and quantifiably benefitting is you as the admin. Yet even as most of you constantly covet the next best free tool, it’s nothing short of amazing how few of you actually use the ones you already have.

Take for example Group Policy and its younger sibling Group Policy Preferences. These are quite possibly the most powerful tools already at your disposal. Introduced with Active Directory nearly 12 years ago, traditional Group Policy has changed surprisingly little in more than a decade. Group Policy Preferences, which came along with Windows Server 2008, helps you customize the user experience across a range of preference options.

True, these tools aren’t without their idiosyncrasies. However, with them you can control just about every configuration in your Windows domain. For free.

Group Policy Templates

There’s an almost universal requirement to control application configurations. Apps like Microsoft Office and WinZip are often part of standard new computer builds. They generally start their lives enhancing productivity, but don’t stay healthy for long. Over time, as settings and configurations change, these apps degrade into a less-than-healthy status—one that ultimately requires your troubleshooting attention.

The source of these problems is often the tinkering user—clicking checkboxes they should never touch and replacing critical settings with nonsense values. It’s the curiosity that killed the app.

So if Group Policy and Group Policy Preferences can control “just about everything,” why not use them to control these applications? Some believe application control is more effort than reward. If that sounds like you, head over to the Microsoft Download Center and you’ll be amazed at how much control you’ll have over an application like Office 2010.

With very little effort, these administrative templates automatically add new Group Policy configuration options for just about every setting imaginable for Office 2010. There are somewhere around 4,000 options.

Let’s get started. Create a Group Policy Central Store by copying the C:\Windows\PolicyDefinitions folder in its entirety from any Windows Server 2008 R2 SP1 server (so you’ll get the most recent policies) to \\<yourDomainName>\SYSVOL\<yourDomainName>\Policies. Figure 1 shows the path I used for a test domain.

Figure 1 Creating the Group Policy Central Store.

Now unpack those downloaded Office 2010 templates. Copy the ADMX files you find in the ADMX subfolder into this new Policy Definitions folder. Then, copy the appropriate language files to the equivalent subfolder in your domain.

Once you’ve copied those, launch the Group Policy Management Console. Then create and edit a new Group Policy Object (GPO). You should see a long list of Office 2010-specific configurations that are now under your control (see Figure 2). Good riddance to bad tinkering.

Figure 2 Group Policy settings for Office 2010.

You should notice some settings under Computer Configuration. These will adjust the configuration for every user on that computer. These settings adjust the registry’s HKEY_LOCAL_COMPUTER hive. You apply other settings on a per-user basis. These are in User Configuration, which means they’ll modify registry settings in HKEY_CURRENT_USER.

This separation is important because of how Windows applies Group Policies. Remember the Computer Configuration portion of a GPO only applies to a computer when that GPO is linked to an Organizational Unit (OU) containing that computer. The same holds true for users. A GPO’s User Configuration only applies when the GPO is linked to an OU containing that user.

It’s that behavior that trips up most IT pros inexperienced with Group Policy. Often, these people find themselves creating OUs for the wrong reasons. They may group users or computers by department or function. OUs have two roles in Active Directory: delegating administration and Group Policy application. Most don’t use delegation, so subdividing users or computers for reasons other than Group Policy rules might hurt you more than help you.

Other Apps Don’t

Some applications come with their own administrative templates. With a single download, you can immediately expose this type of app to a dizzying array of configurations that you control. Microsoft does this frequently. The reality, however, is that other vendors aren’t always so forthcoming. Rare is the vendor that supplies an ADM or ADMX file for controlling their software. With those other apps, you’ve got a bit more work ahead of you.

That effort breaks into two steps. First, you’ll need to identify what actually happens on the computer when you make an app configuration. Often, that “thing that happens” is a change to the registry. As discussed previously, user-specific settings are generally stored in HKEY_CURRENT_USER, most often in its Software subkey. Machine-specific settings are stored in HKEY_LOCAL_MACHINE, also usually in its Software subkey.

What happens next takes a bit of detective work. Let’s use a real-world example like WinZip, a common application on many Windows desktops. The current version is 15.5. In this version, WinZip supports two different UIs. The first is the “legacy” interface that has remained unchanged for many versions; the second is a newer Office 2010 Ribbon-like interface.

People already using Office 2010 have been exposed to its Ribbon interface, so being familiar with the it, they’re likely to appreciate the WinZip Ribbon-like interface. If you haven’t yet upgraded to Office 2010, you might find the WinZip Ribbon confusing and may prefer the legacy interface.

At the bottom the WinZip screen and after selecting Options | Configuration (see Figure 3), you can see where a user may select either interface: Legacy menus/toolbar or WinZip Ribbon interface.

Figure 3 TheWinZip Configuration control panel.

This setting can be the source of never-ending Help Desk calls. You know the story: One day, a tinkering user clicks the wrong radio button. The next time they launch WinZip, they’re presented with an entirely new experience. To the user, you’re to blame. That’s why you want to prevent that call from ever happening.

With a little sleuthing, you’ll find this setting can be different for different users on the same computer. Therefore, you may find it stored in HKEY_CURRENT_USER. Digging through KEY_CURRENT_USER, you’ll find the path \Software\NicoMak Computing\WinZip\WinZip. And there you’ll find a group of values that determine some of the behaviors of WinZip, including a REG_SZ (or string) value called OfficeRibbon (see Figure 4).

Figure 4 TheWinZip OfficeRibbon value.

Every piece of software stores registry values differently. Still it’s common to see a “1” used to signify “yes,” while a “0” signifies “no.” Change the OfficeRibbon value from Figure 4 from 1 to 0, restart WinZip, and you’ll find that it launches with its legacy interface.

Let’s go one step further with this sleuthing. Bring up the WinZip control panel you saw in Figure 3. Move the radio button, click OK and then F5 to refresh the Registry Editor. You’ll see the OfficeRibbon value change in the registry to correspond with the selected radio button in the WinZip control panel. For this setting, you’ve determined what actually happens.

Control What Happens

You now know what you need for the second step in this process: Encoding what actually happened into a GPO. The power of Group Policy Preferences becomes evident here. Unlike a traditional Group Policy that requires uploading a custom ADM or ADMX file to make this change, a Group Policy Preference gives you custom control without coding.

Create and edit a new GPO. Then, in the Group Policy Management Editor, navigate to User Configuration | Preferences | Windows Settings | Registry. Right-click to create a new Registry Item. You’re about to control your first application setting (see Figure 5).

Figure 5 Controlling WinZip with a registry Group Policy Preference.

The HKEY_CURRENT_USER hive is set along with the key path, value name, value type and value data. You discovered all this in your earlier sleuthing. There are four options available: Create, Replace, Update and Delete (you can read more about what these options control here). Select Update to control the OfficeRibbon value. Click OK to create the preference. Link it to an OU of users and you’re controlling your applications.

You’ll have one more task if you don’t have WinZip installed on every computer in your domain. This GPO will be linked to an OU full of users. That means it will apply as they move across computers within that domain. You probably only want it to apply when the user logs onto a computer where WinZip is installed, so select the Common tab, check the box for Item-level targeting and then select the Targeting button. This launches the Group Policy Preferences Targeting Editor (see Figure 6).

Figure 6 The Group Policy PreferencesTargeting Editor.

The Targeting Editor lets you set the conditions in which a Group Policy Preference should apply. In Figure 6, you’ll see a File Match item that checks whether WINZIP32.EXE is present on the computer. If WINZIP32.EXE doesn’t exist, the Group Policy Preference won’t apply.

Determine What Happened

WinZip is the perfect example for talking about this level of control. Most of its customizable settings are exposed in the appropriate places. Sleuthing through other applications isn’t always as easy. In fact, the more apps you have to control, the more you’ll appreciate those that are truly well-coded.

Poorly written applications frustrate this process for many reasons. Some store user settings in HKEY_LOCAL_MACHINE. Others don’t store settings in the registry at all. They may store settings in INI files, environment variables, ODBC files or other wild-and-wooly offbeat spots.

Thankfully, Group Policy Preferences can handle just about any alternative. Take a spin through the list of Preferences in the Group Policy Management Editor and you’ll find almost any setting you need. What you won’t find, however, are the tools you’ll need to determine what happens when applications misbehave.

While Windows PowerShell includes a few comparison cmdlets, you might need to look outside the OS. There are both freeware and commercial solutions that can help you identify misbehaviors. One notable free option that’s surprisingly full-featured is WinInstall LE from Scalable Software.

Software packaging solutions like WinInstall are particularly well-suited for this. These take a reference computer snapshot that looks at the computer’s file system, registry and other elements. After making a change, it takes a second snapshot. The tool then analyzes both snapshots to identify differences. That represents what actually happened.

Use What You Have

Dealing with user-inflicted application problems is one of those time-wasting activities you can often fix with application control. While it used to be difficult, the Group Policy and Group Policy Preferences tools are at your disposal and are well-equipped to quickly disable the tinkering user. The best thing is that they’re free, and they’re already available in your Active Directory domain.

Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields’ Jack-of-all-trades tips and tricks at ConcentratedTech.com.

Related Content

• Geek of All Trades: Configure Remote Management with Server Manager
• Geek of All Trades: Automatically Deploying Microsoft Office 2010 with Free Tools
• Geek of All Trades: How to Extend your Applications and Data to…Everywhere!