Active Directory group policy objects (GPOs) can customize virtually any aspect of a computer or user's desktop. They can also install applications, secure a computer, run logon/logoff or startup/shutdown scripts, and much more. You can assign a GPO to a specific security group, Organizational units (OU), site, or domain. This is called scope of management (SOM for short) because only the users or computers that fall under the scope of the group, OU, site, or domain will process the GPO. Assigning a GPO to a SOM is referred to as linking the GPO.
With Windows Server 2003, you can also use a WMI filter to restrict the application of a GPO. A WMI filter is simply a WMI query that can search against any information on a client's computer. If the WMI filter returns a true value (i.e., something is returned from the query), the GPO will be processed; otherwise, it will not. So not only do you have all of the SOM options for applying GPOs, you can now use any WMI information available on the client's computer to determine whether GPOs should be applied. For more on the capabilities of GPOs, I recommend reading Chapter 7 of Active Directory, Second Edition (O'Reilly).
GPOs consist of two parts. groupPolicyContainer (GPC) objects are stored in Active Directory for each GPO, which reside in the cn=Policies,cn=System,<DomainDN> container. These objects store information related to software deployment and are used for linking to OUs, sites, and domains. The guts of GPOs are stored on the file system of each domain controller in group policy template (GPT) files. These can be found in the %SystemRoot%\SYSVOL\sysvol\<DomainDNSName>\Policies directory.
So why are there two storage points for GPOs? The need for the Active Directory object is obvious: to be able to link GPOs to other types of objects, the GPOs need to be represented in Active Directory. It is necessary to store GPOs on the file system because clients currently use a file-based mechanism to process and store GPOs, and to provide legacy support for the NETLOGON share.
While the capabilities of GPOs were significant in Windows 2000 Active Directory, the one obvious thing that was lacking were good tools for managing them. The dual storage nature of GPOs creates a lot of problems. First, Microsoft did not provide a scriptable interface for accessing and manipulating GPOs. Second, there were no tools for copying or migrating GPOs from a test environment to production. In Windows 2000, the primary tool for managing GPOs was the Group Policy Editor (GPE), now known as the Group Policy Object Editor (GPOE). The main function of GPOE is to modify GPO settings; it does not provide any other management capabilities.
Microsoft realized these were major issues for group policy adoption, so they developed the Group Policy Management Console (GPMC). The GPMC is a MMC snap-in that provides the kitchen sink of GPO management capabilities. You can create, delete, import, copy, back-up, restore, and model GPOs from a single interface. Perhaps what is even better is the scriptable API that comes with the GPMC. Pretty much every function you can accomplish with the GPMC tool, you can do via a script.
You can download the GPMC from the following site: http://www.microsoft.com/windowsserver2003/gpmc/default.mspx. It requires the .NET Framework on Windows Server 2003 or Windows XP SP 1 with hotfix Q326469, and cannot be run on Windows 2000. You can manage Windows 2000-based Active Directory GPOs with the GPMC as long as you run it from one of the previously mentioned platforms.
> cscript listallgpos.wsf
or, if you make cscript your default WSH interpreter, you can execute the file directly. To make cscript your default interpreter, run this command:
> cscript //H:cscript
The complete documentation for the GPM API is available in the gpmc.chm file in the %ProgramFiles%\GPMC\scripts directory or from MSDN (http://msdn.microsoft.com/).