Group Policy is designed to simplify administration by allowing administrators to configure user and computer settings in the Active Directory directory service and then have those policies automatically applied to computers throughout an organization. Not only does this provide central management of computers, it also helps to automate key administrative tasks. Using Group Policy, you can accomplish the following tasks:
Configure security policies for account lockout, passwords, Kerberos, and auditing
Redirect special folders such as My Documents to centrally managed network shares
Lock down computer desktop configurations
Define logon, logoff, shutdown, and startup scripts
Automate the installation of application software
Maintain Microsoft Internet Explorer and configure standard settings
Some of these features such as security policies and folder redirection have been discussed in previous chapters. Other features are discussed in this chapter. The focus of this chapter, however, is on the management of Group Policy, which is the most challenging aspect of implementing Group Policy in an organization.
You can think of Group Policy as a set of rules that help you manage users and computers. Like any set of rules, Group Policy is effective only under certain conditions. You can use Group Policy to manage servers running Microsoft Windows 2000 and Windows Server 2003 and client workstations running Windows 2000 and Windows XP Professional. You cannot use Group Policy to manage Windows NT, Windows 95, or Windows 98.
Note
Like Active Directory, Group Policy has gone through several revisions. As a result of these revisions, some policies work only with a version of the Windows operating system that is compatible with a particular revision. For example, some group policies are compatible with Windows 2000, Windows XP Professional, and Windows Server 2003, while others are compatible only with Windows XP Professional and Windows Server 2003.
Two types of group policies are available. The first type is local group policy, which is stored locally on individual computers in the %SystemRoot%System32GroupPolicy folder and applies only to a particular computer. Every computer running Windows 2000 or later has one local group policy. For a computer in a workgroup, the local group policy is the only group policy available. A computer in a domain also has a local group policy, but it is not the only group policy available, and this is where the second type of group policy called Active Directory group policy (or more commonly just "group policy") comes into the picture.
Active Directory group policy is stored in the Sysvol folder used by Active Directory for replicating policies and is represented logically as an object called a Group Policy Object (GPO). A GPO is simply a container for the policies you configure and their settings that can be linked to sites, domains, and organizational units (OUs) in your Active Directory structure. You can create multiple GPOs, and by linking those objects to different locations in your Active Directory structure, you can apply the related policy settings to the users and computers in those Active Directory containers.
When you create a domain, two Active Directory group policies are created:
Default Domain Policy Used to configure domain-wide settings
Default Domain Controller Policy Used to configure baseline security for domain controllers
Inside Out: Create additional GPOs rather than editing the default GPOs
The Default Domain Policy and Default Domain Controller Policy GPOs provide the baseline policy for a domain. These policies are vital to the health of Active Directory in that domain. You should edit the Default Domain Policy only to set account policy. For other types of policy, you should create a new GPO and link it to the domain. You should edit the Default Domain Controller Policy only to set users rights and audit policies. Otherwise, it is recommended that you do not make other changes to the Default Domain Controller Policy. If for some reason these policies become corrupted, Group Policy will not function properly. To resolve this, see the section entitled "Fixing Default Group Policy" later in this chapter.
You can create additional GPOs as necessary and link them to the sites, domains, and OUs you've created. Linking a GPO to Active Directory structure is how you apply Group Policy. For example, you could create a GPO called Technology Policy and then link it to the Technology OU. The policy then applies to that OU.
Group Policy applies only to users and computers. Although groups can be used to specify to which users a particular policy applies, the actual policies are applied only to member users. Group Policy settings are divided into two categories: Computer Configuration and User Configuration. Computer Configuration contains settings that apply to computers. User Configuration contains settings that apply to user accounts.
Figure 38-1 shows the Default Domain Policy for a computer. As you can see in the figure, both Computer Configuration– and User Configuration–related settings are divided into three major classes, each of which contains several subclasses of settings:
Software Settings Allow you to install software on computers and then maintain it by installing patches or upgrades. You can also uninstall software.
Windows Settings Allow you to manage key Windows settings for both computers and users including scripts and security. For users, you can also manage Remote Installation Services, folder redirection, and Internet Explorer maintenance.
Administrative Templates Allow you to control Registry settings that configure the operating system, Windows components, and applications. Administrative Templates are implemented for specific operating system versions.
Within the Windows operating system, the components of Group Policy have separate server and client implementations (see Figure 38-2). Each Group Policy client has client-side extensions that are used to interpret and apply Group Policy settings. The client-side extensions are implemented as dynamic-link libraries (DLLs) that are installed with the operating system. The main DLL for processing Administrative Templates is Userenv.dll.
The Group Policy engine running on a client triggers the processing of policy when one of two events occurs: either the system is started or a user logs on to a computer. When a system is started and the network connection is initialized, computer policy settings are applied and then a history of the Registry-based settings that were applied is written to %AllUsersProfile% Ntuser.pol. When a user logs on, user policy settings are applied and then a history of the Registry-based settings that were applied is written to %UserProfile%Ntuser.pol.
Note
Any errors that occurred during processing of the Registry-based settings in the Administrative Templates are written to a log file called Gptext.log in the %SystemRoot% DebugUsermode folder. Warnings and informational events can also be written to Userenv.log if verbose logging is enabled. This log is also stored in the %SystemRoot% DebugUsermode folder.
Administrators use the Group Policy Object Editor to manage Group Policy. This snap-in for the Microsoft Management Console (MMC) provides the three top-level classes (Software Settings, Windows Settings, and Administrative Templates) that can be managed and makes use of a number of extensions. These extensions provide the functionality that allows you to configure various Group Policy settings. Some client-side extensions don't have specific implementations on the server because they are Registry-based and can be configured through Administrative Templates.
Although GPOs are represented logically in Active Directory and replicated through normal replication, most server-side Group Policy components are represented on the Sysvol as physical files. The default location for the Sysvol folder is %SystemRoot%Sysvol with the subfolder %SystemRoot%Sysvolsysvol shared as SYSVOL. Within the shared Sysvol folder, you'll find subfolders organized by domain and the globally unique identifier (GUID) of each GPO created in a particular domain.
In these subfolders are files that are used to store the actual settings as implemented for a particular client-side extension on a per-GPO basis. The files available depend on the extensions that you use and include those summarized in Table 38-1.
Table 38-1. Essential Files Stored on the Sysvol
Client-Side Extension/Sysvol File | Description |
|---|---|
Administrative Templates | |
Admfiles.ini | Initialization file for Administrative Templates that tracks the available template files. |
System.adm | Provides policy settings for the operating system. Available for Windows 2000, Windows XP Professional, and Windows Server 2003. |
Inetres.adm | Provides policy settings for Internet Explorer. Available for Windows 2000, Windows XP Professional, and Windows Server 2003. |
Conf.adm | Provides policy settings for Net Meeting. Available for Windows 2000, Windows XP Professional, and Windows Server 2003. Not available for 64-bit Windows editions. |
Wmplayer.adm | Provides policy settings for Microsoft Windows Media Player. Available for Windows 2000, Windows XP Professional, and Windows Server 2003. Not available for 64-bit Windows editions. |
Wuau.adm | Provides policy settings for Windows Update. Available for Windows 2000 Service Pack 3 or later, Windows XP Professional Service Pack 1 or later, and Windows Server 2003. |
Software Installation | |
AppGUID.aas | Stores the actual settings for a specific application installation according to the GUID of the application and includes the location of the application installation package. Although the .aas file is stored in the Sysvol, the actual application installer is not. |
AppName.msi | A software installation package that is stored on disk separately from the related .aas file. |
Security Settings | |
Gptmpl.inf | Stores the actual security settings that apply to event auditing, Registry values, and privilege rights assignment. |
Folder Redirection | |
Fdeploy.ini | Stores the folder redirection settings for the GPO. |
Other Settings | |
Registry.pol | Stores miscellaneous Registry-based settings for Administrative Templates, Disk Quotas, EFS Recovery, QoS Packet Scheduler, and so forth. |
Sysvol files are replicated using the File Replication Service (FRS). Although FRS uses Active Directory replication to distribute the Sysvol files, there is a separate database for replication (see Figure 38-3). This database uses the Microsoft JET database technology. The base location of this database is %SystemRoot%NtfrsJet and the primary data file for replication, Ntfrs.jdb, is stored in this folder.
The FRS storage engine uses transactional processing to manage the database. Any data that is modified in a transaction is copied to a temporary database file. If FRS finishes processing changes without errors occurring, the transaction can be committed. A record of the transaction is written to the transaction log and then to the database. The primary log file, Edb.log, has a fixed size of 5 megabytes (MB). FRS uses the reserve log files to reserve space on disk for additional log files that might need to be created. Because several 5 MB reserve files are already created, this speeds up the transactional logging process when additional logs are needed.