Logon scripts are passé.
Their text-based configurations are ripe for syntax errors, the "everything for everyone" targeting they employ requires special coding if you want certain users to get special settings, and the fact that they only run at logon means you're never really sure when they've fully deployed.
Problematic beasts that they are, logon scripts just aren't really necessary anymore these days -- at least that's what I wrote in my last article on eliminating logon scripts with Group Policy preferences (GPPs). There I presented three common configurations that not long ago were only possible with logon scripts: configuring drive mappings, creating printer connections, and customizing applications for users.
That article gave you the step-by-step process to yank printer assignments out of your logon scripts. Using Group Policy preferences, you can accomplish the same task, but in a much more manageable fashion. In this follow-up, I want to show you how to get that same manageability when you're customizing user applications.
To begin, think for a minute about the application behaviors that you hate in your environment. Does WinZip annoy you when it opens up in Wizard Mode instead of Classic Mode? What about WS_FTP's restriction on only allowing a single instance to run at a time? Do you hate it when Adobe Acrobat Reader launches inside your browser to view a PDF instead of just running inside its own window?
You can adjust these and many other application behaviors by tweaking their registry configurations. While not every application's configuration is easily exposed in the registry, some are fairly easy to spot and fix yourself. All you need is a solution to spread those changes out through your network. That mechanism can be a logon script, or you can manage it through a Group Policy preference.
Eliminating Acrobat Reader's browser integration
Let's look at an example of how to use Group Policy preferences to manage one aspect of Acrobat Reader's behavior. In this example, we want it to stop viewing PDF files within our browser. Instead, we want it to launch its own Acrobat Reader window when we click a link on a webpage.
The first step in this process involves a little sleuthing. In order to instruct Acrobat Reader to stop behaving in a certain way, you first need to figure out how to speak its language. In this case, the language of Acrobat Reader is the language of the registry. With a little Google searching, you can quickly zero in on an Adobe knowledgebase article that tells you the exact registry key and value that must be modified to turn off browser integration.
That registry path, at least for the version currently installed on our example computer, is HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\9.0\Originals. The key, which is not present and must be created, is bBrowserIntegration. Assign the REG_DWORD value of 0 to turn off browser integration.
Knowing this exact registry path and key location is the most difficult part. Modifying behaviors like this can only happen when the application is coded to look for the right values. That's why the sleuthing is sometimes necessary; when the values don't exist and must be created by you.
Once you've figured out the keys and values you want, spreading them around your network through a Group Policy preference is honestly the easy part. Start by launching the Group Policy Management Console (GPMC) and creating a new policy. Once created, open that policy in the Group Policy Management Editor (GPME) and navigate to Computer Configuration | Preferences | Windows Settings | Registry. Simply right-click Registry and select New | Registry Item to create a new preference.
The New Registry Properties console looks a bit like Figure 1. Clicking the ellipsis (…) button next to Key Path brings forward a tree view of your local registry, enabling you to find and enter the correct key path. You could also simply enter the correct path into the dialog box.
Also needed is the Value name, which in this case is bBrowserIntegration, as well as the REG_DWORD value of 0. Selecting an Action is required as well, with four possible options available.
Just like in the example from my previous article, the Common tab (Figure 2) presents five options. You may wish to set the Group Policy preference to Remove this item when it is no longer applied. Configuring this setting ensures that the registry update is removed when the policy no longer applies to the targeted user or computer, handily doing away with any trace of your modification when you no longer need it.
If your network is like most, then it's likely that each application is not installed everywhere. While Acrobat Reader might be common across desktops, you should still want the assurance that you're only adjusting its behaviors when it's actually installed to the targeted computer.
It is for this reason that item-level targeting is so important with registry modifications. With item-level targeting, you can restrict the registry modification to only those computers that have Adobe Reader installed. This can be accomplished by creating a New Item of type File Match in the Targeting Editor (Figure 3). We can then enter in the name of a file that is associated with the application we wish to configure. Figure 3 shows how the AcroRd32.exe file is checked for existence. If it exists, then the Group Policy preference is applied.
That's all there is to it. Making even large-scale registry changes with Group Policy preferences is ridiculously easy, especially when compared to the management nightmare of logon scripts. Your only hurdle in this entire process involves discovering the correct registry keys and values you need to fully control all your applications' behaviors.
ABOUT THE AUTHOR
Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Greg's Jack-of-all-Trades tips and tricks at www.ConcentratedTech.com.