Understanding Group Policy Technologies for Desktop Deployment
By Eric Voskuil
.jpg)
The Microsoft Windows Active Directory directory service provides a powerful technology for centralized desktop management. While the idea of policy-based management is not new, Microsoft's Group Policy system provides a pre-deployed implementation on all computers running Microsoft Windows 2000 or later operating systems. Even better, the system is extensible, meaning that it is actually a development platform. Over time, Microsoft development platforms tend to attract a substantial community. I've spent five years designing software for this platform and have helped hundreds of organizations leverage it.
Because Group Policy requires Active Directory, its adoption has understandably lagged behind new platform deployments. However, after you've deployed Active Directory, you have a rich distributed desktop management framework ready for action. As Jerry Honeycutt pointed out in his recent article, "Using Virtual Server 2005 in Desktop Deployment," Microsoft has a way of introducing life-changing technologies. Group Policy is definitely one of these technologies.
Reduce Imaging and Minimize Scripting
The complexity of a new desktop rollout can be overwhelming. Often, organizations must create several base platforms, some differing significantly, others only slightly. Imaging tools, such as Symantec Ghost, can speed the actual distribution of such platforms, but with each unique image, project complexity multiplies. Change requirements are bound to pop up so soon that you may not even be done with the original deployment before you have to start adjusting. Will you modify the original image and redeploy the entire platform again? How will you manage per-user differences and configurations for roaming users?
If you could deploy a single image to all desktops and dynamically apply templates of changes to that image, wouldn't life be easier? Consider it "late binding" of the environment to the platform. You could create a base operating system image and then apply the various templates to the image after it's deployed. You could test your changes by running Microsoft Virtual Server 2005 with the base image installed, then applying the templates. (By templates I mean everything from software applications and updates to security settings and user profile configuration.)
Prior to Group Policy, organizations had to attempt this type of solution using custom scripts or script-generating utilities. Most information technology (IT) managers had to learn the five rules of scripting projects:
Scripts quickly get long and complex.
Changing deployed scripts can wreak havoc in an environment.
You support your own scripts; Microsoft supports only individual calls.
Scripts don't include reporting, which makes determining what a script has done difficult.
Scripting is custom development with all the associated costs and uncertainties.
In contrast, Group Policy allows you to collect settings into Group Policy Objects (GPOs) and apply those objects to collections of computers and/or users. GPOs are effectively templates that you can link to organizational units (OUs), sites, and domains. You apply the policy settings in a GPO to users or computers in the collections to which the GPO is linked. Policy is applied to computers at logon, at startup, and at variable intervals.
The Group Policy system also provides graphical editing and reporting against individual policy settings as well as a planning mode for predicting which individual settings will win out when more than one template applies the same setting to a computer or user. You can access these features using Microsoft's Group Policy Management Console (GPMC), through which you can manage all aspects of Group Policy centrally.
In the event that Group Policy does not provide capabilities that you need, a custom scripting capability is available. However, you should always remember that this is scripting, not policy. The scripts extension in Group Policy simply launches scripts. In other words, the policy setting is the path to the script file, not what's in the script. This capability serves as a catch-all for the features that aren't provided as policy settings but also takes you back to the five rules above.
So, life is good: You can standardize on fewer images, secure and configure your desktops, and provide the dynamic behavior of scripting without writing custom code. You can have supported settings and complex logic, you can have reporting and planning, and you can easily make changes without breaking all your other settings. In short, you can have your cake and eat it, too!
Limitations of Group Policy
Because Group Policy is extensible, you can (in theory) manage everything. That said, the most basic limitation is that you can use Group Policy to manage only those computers running Windows 2000 or later that are joined to Active Directory domains and only those users logged on to Active Directory via those computers. Other devices and platforms are not supported.
Group Policy's extensibility is based on the specification for plugging functionality into the policy editor, client-side processing, and the reporting system. These plug-ins are called extensions, and they determine everything that you can actually manage using Group Policy. Microsoft Windows XP ships with 11 extensions, including one for deploying software packages and several for managing security settings. Each extension has its own limitations, some of which I discuss in the following sections.
You may also encounter organizational limitations. Desktop administrators may need to obtain a higher level of access to manage GPOs. Group Policy includes a granular delegation model that may mitigate this issue, and third-party products are also available for enforcing a change-control process, including a free add-on to GPMC. Because centralized management has the ability to affect a large number of users very quickly, these are generally wise precautions. For smaller organizations, the backup and restore capability of GPMC may prove sufficient for reverting policy changes.
Deploying Software Packages and Updates
Group Policy includes a capable Software Installation extension, and some of the largest organizations using Active Directory take full advantage of it. However, to the extent that Group Policy has a reputation for being a technology limited to small- and medium-sized organizations, it is because of the limitations of software-installation policy. These limitations include a lack of scheduling, centralized reporting, inventory, checkpoint restart, and bandwidth throttling.
Additionally, Group Policy does not include a native extension for managing patch deployment. Smaller organizations may be satisfied with configuring Automatic Updates to automatically pull updates directly from Microsoft to target platforms, but this setup may encounter trouble with access through a proxy, doesn't allow for any centralized discretion regarding which patches to deploy, and doesn't support all Microsoft updates or allow for third-party updates. Through the Administrative Templates Group Policy extension, you can enable Automatic Updates by using a template file (wuau.adm) available by download from Microsoft. (See the Microsoft Knowledge Base article "How to configure and use Automatic Updates in Windows XP" for more information.)
If your network includes more than 500 computers, you should consider a dedicated package such as Microsoft Systems Management Server 2003 for software and patch deployment, as well as hardware and software inventory. Organizations that do not employ Systems Management Server may want to consider Microsoft Windows Server Update Services (WSUS) for patch management. WSUS is a standalone application that pulls updates from Microsoft into a Microsoft Internet Information Services (IIS) Web service and deploys them using an upgraded version of the Automatic Updates client. This system provides administrator discretion and reporting, but cannot deploy third-party updates.
Managing Security, Registry, and Other Settings
The scalability of Group Policy has no upper or lower limit, and the settings for managing security attest to this. It is commonplace-practically a requirement-to use Group Policy to manage security settings across all computers in an Active Directory domain. Several extensions are available that specifically manage security, including Security Settings, Administrative Templates, IP Security (IPSec), and Wireless. These extensions contain well over a thousand predetermined settings, and a description of these settings is beyond the scope of this article. For more information about them, read the Microsoft TechNet article "Managing Windows XP Service Pack 2 Features Using Group Policy."
The Administrative Templates extension is a template file-driven extension for setting registry values, a common configuration management task. The predefined template files (ADM files) provided by Microsoft contain a large number of settings. You can also create custom files to deploy custom settings, although this method has several drawbacks, especially if the settings are not "true policies" (and most custom registry settings won't be). For more information about ADM files, see the Microsoft TechNet article "Using Administrative Template Files with Registry-Based Group Policy."
A Group Policy extension designed specifically for deploying custom registry extensions is available free of charge on the CD included with the new Microsoft Windows Group Policy Guide from Microsoft. This extension eliminates the complexity and other drawbacks of customizing templates. You can simply browse to settings and then deploy them.
Getting Started with Group Policy
Where native Group Policy falls short, several free add-ons and commercial products are available that provide integrated capabilities, including patch management, software deployment, security solutions, user profile configuration, and GPO change control. Most of these are listed on the Group Policy Wiki. And then there's always scripting, which you can initiate from Group Policy. But unless you like managing open-ended development projects, keep your scripting to a minimum.
A substantial amount of information is available about Group Policy, but hopefully I've given you an understanding of its potential. The TechNet Group Policy home page should be your next stop. While Group Policy has some limitations, it's an essential component of desktop deployment. If you aren't using it to its potential, it's time to get started!
For More Information
About the Author
As CTO of DesktopStandard, Eric Voskuil and his team have produced some of the most innovative and forward-looking enterprise desktop-management products on the market. His overriding philosophy-namely, that management products exist solely to make management tasks easier-has guided development to produce easy-to-use, powerful, standards-driven, integrated products that leverage pervasive technologies. You can reach Eric at eric@desktopstandard.com; his full bio is available at https://www.desktopstandard.com/ExecutiveBios.aspx.
.gif)
.gif)