Chapter 12. Managing Group Policies
AS A CONSULTANT, I'M CONSTANTLY MADE AWARE of corporate policies. For instance, if I park too close to a building, someone hurries out to tell me, "Those spaces are reserved for employees. You contractors have to park over there." Or if I make a suggestion that veers too far out of a client's comfort zone, a manager usually points at a set of thick, three-ring binders and patiently explains that "things just don't work that way here."
I'm a child of the sixties, so I grouse at being bound by rules and policies, but I recognize their necessity. Any organization with more than two people needs policies to define roles and guide behavior. The same is true for computers. Users have certain expectations for their computers and we in IT can't meet those expectations unless we enforce a measure of uniformity on the desktops and servers that support those users.
Microsoft recognized this need and introduced policy-based desktop management way back in Windows 95 with a feature called system policies. These policies were essentially pre-packaged Registry updates. Clients downloaded a file containing the updates when they logged on and applied the updates to their local copy of the Registry. That was that.
Classic system policies were a step in the right direction, but they have several serious limitations:
System policies permanently change the local Registry on a client.
Microsoft calls this tattooing. If you've ever made a mistake in a system policy setting and unwittingly deployed the policy file, you know how difficult it can be to recover because of the changes made to the clients' Registries.
System policies can only manage a limited range of processes.
The number of Registry entries included in a standard set of system policies is very small, and system policies cannot be used to control processes that do not rely on Registry settings.
System policies can only be distributed from a single file.
For NT, the file is Ntconfig.pol. For Windows 9x, it is Config.pol. This requirement to package all changes into a single file makes system policies inflexible and difficult to manage. It's possible to target a specific group within a .pol file, but this creates a large file that is cumbersome to maintain and takes a while to download.
Starting with Windows 2000, Microsoft changed policy-based management considerably. It tossed out the clumsy, static, Registry-only system policies and introduced a new feature set called group policies. Windows Server 2003 includes all the group policies in Windows 2000 plus additional policies that help take advantage of the new features in servers running Windows Server 2003 and XP desktops.
This chapter explains how to create, distribute, and manage group policies. The focus is on operational features: How do policies do their work? What requirements must be met to use them? How could they break down in production, and how are they best fixed? For comprehensive coverage of group policies including lots of examples and specific recommendations for implementing individual policies, I highly recommend Windows 2000: Group Policy, Profiles, and IntelliMirror by Jeremy Moskowitz.