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