June 17, 2011, 10:12 a.m.
posted by trystan
Active Directory Group Policy Objects ( GPOs) can customize virtually any aspect of a computer or user's desktop. They can also be used to install applications, secure a computer, run logon/logoff or startup/shutdown scripts, and much more. You can assign a GPO to a local computer, site, domain, or Organizational Unit. This is called scope of management (SOM), because only the users or computers that fall under the scope of the computer, OU, site, or domain will process the GPO. Assigning a GPO to a SOM is referred to as linking the GPO. You can further restrict the application of GPOs by using security groups to filter which users or groups they will apply to.
With Windows Server 2003 servers and Windows XP workstations, 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., the client computer matches the conditions that are specified in the filter), 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, we recommend Chapter 7 of Active Directory, Third Edition, by Joe Richards et al. (O'Reilly).
Group policies are defined by a set of files that are replicated to each domain controller in a domain and a groupPolicyContainer ( GPC) object that is stored in the cn=Policies,cn=System,<DomainDN> container. GPC objects contain information related to software deployment, wireless deployments, IPSec assignments, and metadata about the version of the GPO. GPC objects are used for linking to OUs, sites, and domains. The guts of GPOs are stored on the filesystem 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. Group Policy Templates are stored in the filesystem to reduce the amount of data that needs to be replicated within Active Directory.
While the new 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 GPO settings. 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 GPO processing 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 at least version 1.1 of the .NET Framework on Windows Server 2003 or Windows XP SP1 or SP2. (Windows XP SP 1 requires hotfix Q326469 as well.) The GPMC cannot be run on Windows 2000. You can, however, manage Windows 2000based Active Directory GPOs with the GPMC as long as you run it from one of the previously mentioned platforms.
Another tool that you can download from the Microsoft web site is GPInventory. This is an incredibly useful tool that will allow you to perform a software inventory for users and computers in a domain or OU, and to track information about the rollout of GPOs in AD, such as computers that have not applied new GPO information.
> cscript listallgpos.wsf
or, if you make cscript your default WSH interpreter, by executing 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).