It all comes down to fear.

Fear of the Windows registry. Fear of editing its values. Fear of catastrophically destroying a user's Windows computer, along with all the pain and extra work in piecing it back together. Fear is the reason you've not invested the time to lock down your application configurations.

Even considering the benefits, that fear is understandable. Microsoft itself tries to instill a healthy fear into the registry-editing administrator. You've seen the caution built into almost every TechNet knowledgebase article, 'Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.'

Yet the Windows registry at its core is little more than a database. That database of configuration values is populated by the operating system and all the applications installed on top.

It stands to reason, then, that if you could control those values'well'then you'd control your users' application experience. On their behalf you'd check the boxes that need checking, or uncheck those you know cause problems. You might even fill out your application's dialog boxes with the correct values before the user ever launched the application.

In the end, you might never have to send out another 'How to Start Using AppABC' document again. That's great, because users always lose those documents, or misread them, and end up wasting your time with extra help desk calls. Instead, your applications are perfectly locked down for them, all by policy.

By losing the fear, you gain control.

De-Fearing Registry Manipulation

Locking down applications starts with the Windows registry. Most applications store their configuration data in various locations throughout the registry. Best practices for coding those apps suggest that entire-machine settings should be stored in HKEY_LOCAL_MACHINE, often shortened to just HKLM. Per-user settings should end up in each user's HKEY_CURRENT_USER, or HKCU, hive.

Modifying values in HKLM has never been that difficult; its hive gets loaded whenever a computer starts up. Every user operating that computer shares in the values contained within HKLM. Just powering on the computer allows you to modify its HKLM hive.

While most of us browse the registry using regedit.exe, getting to policy control of its information really starts at the command line. With a computer's Remote Registry Service turned on (these days it isn't by default), you can remotely manage its HKLM hive with the command reg.exe. Using this command, for example, one could query a remote computer's software key:

reg.exe query \\\HKLM\software

You can do the same with Windows PowerShell, although you'll need to enable and configure PowerShell Remoting first on the remote computer. The simplest form of PowerShell's remote registry query looks like this:

Invoke-Command' { dir HKLM:\software }

Figure 1: Using PowerShell to query a remote registry.

Figure 1 shows a sample response from PowerShell's remote query. You can see there that nine subkeys exist below HKLM\Software on the computer \\dc. Both reg.exe and PowerShell support additional command structures for creating and deleting keys, editing values, and all the necessary steps you need towards bringing machine settings under control.

Knowing that you can edit HKLM's contents is useful, but it gets you nowhere when the lockdowns you need reside in HKCU. Editing data can be more difficult, because each user's HKCU isn't loaded until that user logs in. That's because each user's HKCU hive is actually a file in their profile named NTUSER.DAT.

One possible way to modify a user's HKCU is through the use of a logon script. Since logon scripts run at logon, they'll have access to view and modify that user's HKCU hive. Both reg.exe and PowerShell are equipped to do this. The lines below add the AppABC subkey to the computer's HKLM\Software key, with the first using reg.exe and the second using the registry PSDrive in PowerShell. Either is intended to run locally on a computer as part of a logon script:

reg.exe add HKCU\Software\AppABC
mkdir HKCU:\software\AppABC

Setting Policy by Preference

While they'll absolutely work for setting that application configuration, logon scripts are in many ways a poor solution. They only apply as the user logs in, so different computers will be in different states at different times. Making decisions in logon scripts also requires extra coding effort, along with all the necessary testing. What you'd really prefer is some way to deploy an application lockdown everywhere, without resorting to scripting.

Third-party solutions exist to accomplish this task. Those solutions take the scripting out of logon scripting. They enable you to target registry modifications to any computer you've specified.

Microsoft also provides a rudimentary mechanism for customizing application behavior with its Group Policy Preferences. Group Policy Preferences serve a much different role than traditional Group Policies. Understanding the difference is best served by recognizing the tasks traditional Group Policies were never terribly good at.

Back in the days before preferences there wasn't a simple way to create your own custom settings changes. Doing so first required creating your own custom Administrative Template. That process required a special language crafted specifically for Group Policy. Your Administrative Template would need to address all the 'questions' the configuration required along with the range of possible 'answers'. Once authored, the template's ADM file was then attached to a Group Policy. Only then could you answer its 'question' in the way you needed and apply the policy to enact the change.

That's a lot of effort for a simple registry change. Group Policy Preferences are designed to simplify the process a bit, although they still require knowledge about the configuration you want to control.

Figure 2: Configuring a Registry preference.

Figure 1 shows an example of a Registry Preference that's been created under a Group Policy Object's User Configuration node. This preference modifies a value in the Key Path HKCU\Software\AppABC. It sets the BehaveInappropriately registry value to 0.

Not shown in Figure 1, but part of every preference, are additional parameters that might instruct the preference to 'fix' a configuration that gets changed by a user. Targeting the preference to specific users and/or computers is also possible. Once finished, apply the policy containing the preference is linked to an Organizational Unit of users. They're now under control.

'but how does this Lock Down Applications?

Good question, because the conversation so far should beg one important question: 'Now I know how to control registry keys and values, but how do I find out which ones correspond to the settings inside my applications?'

Figure 3: WinZip's wizard setting.

The answer isn't trivial, because every application is a little bit different. Some applications very obviously label which registry settings correspond to what configurations. Figure 3 shows an example of this with the popular WinZip application. Some versions of WinZip can be operated in one of two modes, WinZip Wizard or WinZip Classic. Using the Windows Registry Editor, one can browse to HKCU\Software\Nico Mak Computing\WinZip\WinZip and see a registry value named Wizard with data of 0.

'Yes' or 'no' values in the registry are commonly, though not always, seen as 1 or 0. A bit of educated guessing with Figure 3 would have one assume its 0 value means the WinZip Wizard mode will not be enabled.

This information is valuable for locking down your application behaviors. Let's assume that your users don't like the WinZip Wizard. Every time it gets turned on, they call the help desk with problems. With the information you've learned by sleuthing through the registry, you now know what lines to add to a logon script to fix the problem. Or, you could create a Group Policy Preference to fix it for every user.

Being a registry detective like this only has one rule: There are no rules. Sometimes applications aren't as overt with their registry settings, obscuring them beneath confusing values and keys. Other times, their values might be spread across the far reaches of the registry, or they might be coded in odd ways that aren't easy to figure out at a glance.

In these cases, just browsing the registry probably won't get you the answers you need. There is a class of solutions that can help. Arriving in various forms, these registry change monitoring tools will watch the registry, reporting on its 'before' and 'after' state between which you flip a switch in the application. The process with these tools has three steps:

1. Create a 'before' snapshot of the registry.
2. Make whatever selection you want to control in the application.
3. Create an 'after' snapshot and compare the differences.

Many of these tools are freeware solutions. Others that are more powerful may include this basic functionality as part of a larger software packaging solution. Often, spending the few dollars on the extra features of the packaging solution is the best idea. Some applications may store configurations in files or services that aren't well-represented in the registry. A software packaging solution can scan an entire computer ' files, registry, devices, services, and so on ' with the goal of giving you a complete understanding of what changed between Step 1 and Step 3.

Investing in Application Control

Losing your fear of the registry is only the start. Also necessary is the time and effort in locating the configurations you want to control. That won't happen overnight. That said, investing a bit of up-front time in controlling your applications pays dividends far into the future. Your applications will experience fewer problems, you'll experience fewer help desk calls, and your entire IT environment will grow just a little bit more predictable.