|This chapter excerpt from Microsoft Windows Vista Management and Administration, by Andrew Abbate, James Walker, Scott Chimner and Rand Morimoto, is printed with permission from Pearson Education, Copyright 2007.
Step 2 of 2:
What Are Group Policy Objects (GPOs)?
Group Policy describes the Microsoft implementation of a methodology of managing computers and users in a centralized fashion in an Active Directory environment. Group Policy Objects (GPOs) are the collections of various application and Registry settings that have been defined by an administrator to enforce a particular behavior on a user or computer object.
This concept was initially introduced back in the Windows NT 4.0 days when an administrator was able to use Policy Enforcement to force a workstation to conform to particular behaviors. This was usually limited to restricting a user's local rights to prevent the user from changing things like the UI or locally installed applications. It was initially a clunky way of doing things, but it set the stage for the introduction of Group Policy Objects in Windows 2000 with the advent of Active Directory (AD).
In Windows 2000, administrators were given the capability to easily configure hundreds of common settings in the area of application publishing to security settings to Internet Explorer settings. This was done through a provided editor that utilized ADM files that contained definitions for the user and computer objects to interpret. The drawback to these ADM files was that the format was somewhat cryptic, and it made it difficult for administrators to create their own ADM files for modifying custom applications or to modify applications for which Microsoft had not yet released ADM files. This situation didn't change much with the release of Windows 2003, but it did introduce a new tool called the Group Policy Management console.
This tool allowed administrators to more easily view and manage Group Policy Objects as well as to back them up and even port them from one domain to another. It was not until the release of Vista that Microsoft fundamentally changed the way that GPO settings were stored. With Vista came the new ADMX format of files. ADMX is based on XML, or Extensible Markup Language. XML is an open standard for data formatting that is meant to put data into a more human-friendly format. The result is that ADMX files are much easier to create than their ADM predecessors.
Why Administrators Should Use Group Policy Objects
GPOs are designed as a way to globally modify user and computer settings through a controllable and manageable central interface. This is to say, GPOs are meant to replace manual intervention on systems and custom logon scripts.
Take, for example, the implementation of a new web proxy server in an environment. In the old days, you would either go from system to system, logging in as the user and setting the Proxy configuration in Internet Explorer, or if you were adept at scripting, you might write a custom script that would modify the Proxy settings and set it to run in the user's logon script. This situation is very easily handled by GPO. In fact, it can be done with much greater granularity with a GPO.
Imagine that in our example there are multiple Proxy servers, and the goal is for users to use the Proxy server that is closest to them. Although this could be accomplished manually, it wouldn't account for users who travel. If a user in the United States was configured to use the Proxy in the U.S., it would result in poor performance if the user were to visit an office in Japan that had a local Proxy server. If the user was well versed in scripting, he or she might be able to write a subroutine that was "location aware" and modify the Proxy settings when the system was in another location, but that would really be reinventing the wheel.
If the administrator used Group Policy, the administrator could create a GPO for each Proxy server and link the GPOs to the sites defined in AD. This would result in systems using the closest Proxy server no matter where they were. The term linking in this context refers to tying an Organizational Unit (OU) or a site to a particular OU so that only objects in that site or OU will attempt to use the GPO. This will be explained in further depth later in this chapter.
As you can see from the preceding example, GPOs should be used in situations where an administrator wants to push a setting or configuration to multiple systems and needs the flexibility to limit which systems or users receive the settings.
GPOs are also extremely useful for enforcing the rules of an environment. For example, if a company changed its policy to require computers to be locked after a period of inactivity, this setting could easily be configured via GPO. Although many companies may configure a setting like this when deploying a system, the advantage to doing it by GPO is that no one can "forget" to make the setting. As soon as a computer is joined to the domain, it will inherit the domain-level GPOs and automatically conform the system to your rules.