Almost every organization has a standard configuration for setting up new computers that is often built into an image file and deployed according. While this approach works, the downside is an organization's standard configuration evolves over time.
Certain Group Policy settings can be helpful in deploying computers that use a standardized configuration since they allow changes to be applied in a uniform manner and ensure each computer is running the currently approved configurations.
The pitfalls of image-based configurations
Typically when deploying a computer, an administrator first installs Windows and then manually fine tunes the deployment. SYSPREP is used to strip away anything unique to that machine (like SIDs or the computer name), and an image is made of the machine's hard drive and deployed to other machines.
The first time the image is booted, Windows runs a mini setup consisting of basic configuration questions (this is because the image is generalized). It is possible to get around this process by providing Windows with an answer file. However, remember that the answer file is normally for automating the setup process, and it is assumed that any configuration customizations not directly related to setup will be manually applied before the computer is imaged —and therein lies the problem.
Windows offers hundreds of different configuration settings that can be fine-tuned. While some of these settings are global, others are applied at the user profile level and thus, are user-specific.
For example, before imaging a PC, you change the power management settings and you disable the Windows Vista sidebar. You then SYSPREP the machine, create an image and deploy the image onto another computer. The first time a user logs on to that computer, the customized power management settings will remain in effect, but by default, the Windows sidebar will be enabled. This is because the Windows sidebar configuration resides in the user profile. The first time that a new user logs on, a new profile is created and the Windows default settings are applied.
Another problem with image-based configurations is that the standard configuration evolves over time: the configuration deployed today will probably be different from the configuration deployed a year from now.
Because of this, try to avoid making manual configuration changes to computers before running SYSPREP. Instead, implement as many configuration settings as possible with the computer's local security policy.
Implementing the local security policy
I have found many administrators do not bother using the local security policy because it gets overwritten when users log on to the network. Regardless, the local security policy has its place.
For starters, Group Policy (including the local security policies) allows almost every aspect of Windows to be customized. For example, Microsoft offers administrative templates to custom configure Microsoft Office.
Specifically, the local security policy is designed to protect computers not attached to the network. Therefore, creating a local security policy ensures the standard configuration is maintained, even if a user logs on locally.
Of course, local security policies are local to a computer and cannot be centrally managed. As your approved configuration evolves over time, the local security policies on your workstations will eventually become outdated.
Fortunately, group policies are hierarchical in nature. Network-level Group Policy Objects (GPOs) offer the same settings as local security policies, and in the event of a conflict, the local security policy has the lowest priority level of the GPOs. This means if a policy setting becomes obsolete, the new setting can be entered into a network-level policy, which will override the local security policy.
All of this raises a very important question: If the local security policies are overwritten by network-level group policies at logon, why even bother to use them if they are going to eventually become outdated anyway?
Well, as your approved configuration evolves, only a few settings will change at one particular time -- it is very rare for every Group Policy setting an organization uses to become obsolete over night.
With that in mind, let's pretend a computer has an outdated local security policy but an up-to-date network-level policy. If someone logged on locally, the local security policy would still offer some degree of protection, and it would enforce the machine's standardized configuration as it existed at one time. This is usually far better than relying on the Windows defaults.
The argument could be made that configurations manually applied to the SYSPREP image behave the same way. Since manual configurations remain in effect unless overwritten by settings enforced through Group Policy, why create a local security policy?
The reason is a local security policy allows you to apply all of your customizations in one place. When the SYSPREP eventually becomes so outdated that it needs to be replaced, you can modify the existing local security policy to match your currently approved configuration rather than having to manually modify a variety of different system settings.
Overall, although a SYSPREP image can be manually configured, whenever possible it is better to implement configuration changes through Group Policy settings.
ABOUT THE AUTHOR
Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal Web site at www.brienposey.com.
This was first published in December 2009