Automated desktop installations, whether using Setup or disk imaging, are only one part of your deployment project. Deploying default settings is another phase, and it can be more difficult than writing unattended-setup answer files or building a disk image. In this article, I'll outline some of the issues and point you to some solutions.
Documentation
The biggest and most important part of this process is documenting the settings you need to deploy. That means including settings in your deployment planning. Some settings will be IT requirements, such as enabling Remote Desktop for remote administration. IT requirements are easy to document, since you don't have to look much farther than your next staff meeting to gather them.
Other settings will be user and departmental preferences, such as shortcuts on the Favorites menu or a particular configuration for the Start menu. There are a variety of ways to gather these preferences; use the mechanisms you already have in place. For example, you can create a spreadsheet and push it down to the department heads. You can create a survey and place it on your intranet.
Keep in mind that while it's important to get users' buy-in on the settings you deploy, you should filter these settings through the IT department and help desk, who are ultimate the best judge as to whether a particular setting is useful to deploy.
Requirements
After you've documented your settings, it's time to choose a technique for deploying them. I'll start with my requirements, arranged from highest priority to lowest, and you should feel free to adjust them to your needs:
1. Elevated privileges: In locked-down environments, users can't change most computer settings. The technique I use must support configuring computer settings with elevated privileges.
2. Automation: The technique I choose for deploying settings must support automation so I can reproduce the results consistently.
3. Settings management: The technique must allow me to easily manage settings after deployment. If updating settings post-deployment is too difficult, correcting errors becomes a nightmare.
4. Centralized management: Centralized settings management in whatever form means fewer things to administer. Deploying and managing settings using a single technique is far less expensive than using different techniques for different types of settings.
5. Precise configuration: This might be my OCD (obsessive compulsive disorder) acting up again, but I prefer techniques that make precise changes to configurations rather than wholesale updates that include much more than I wanted.
Precise automation
Two of my requirements, automation and precision, require that you know where a setting is in the registry. When you manually configure settings, you can click through the user interface. When you're automating the configuration, you must know where the settings are in the registry and sometimes on the file system. You must know how to find these settings and then how to script them.
Finding settings in the registry is easier than you might think. On a lab computer, export the registry to a .reg file, change the setting in the user interface, and then export the registry to a second .reg file. By comparing the two files, you can quickly pinpoint the registry setting corresponding to the setting you changed in the user interface. Also, Sysinternals publishes two useful tools for tracking down changed settings and files: Regmon and Filemon. You can download these free tools at the Sysinternals Web site.
Default user
The default user profile is the method most people first consider when they're deploying user settings. They're easy to create. You replace the Default User folder in C:Documents and Settings with a profile that you've customized, and Windows XP uses your custom settings to create user profiles for new users. You can also create a Default User folder on in your NETLOGON share, and the operating system will use that folder before the local version.
The default user profile fails to meet most of the requirements I outlined earlier, though. First, you can't use them to configure computer settings, with or without elevated privileges. And, while deploying a default user profile is an automated process, creating it is usually a manual process. And forget about managing settings that you deploy using a default user profile; once those settings are out there, you have to use a different technique for updating settings post-deployment. The default user profile fails my last two requirements, too. There is no centralized management, and the default user profile is one of the least precise methods you can use for deploying settings, since you're deploying an entire profile and not just the settings you want to configure.
One problem is unique to the default user profile. Windows XP creates some settings well after creating users' profile folders, and you can't customize those by customizing the default user profile.
Click here to continue to part two to learn how to use logon scripts, disk imaging and third-party tools to deploy settings.
