Group Policy Objects Starting with Windows NT 4.0, Microsoft introduced System Policy, a mechanism for using the registry to "lock down" specific portions of user desktops to prevent users from tweaking the configuration. System Policy was a significant step forward in centralized administration. However, it didn't completely address most enterprise issues related to reducing the Total Cost of Ownership (TCO), such as:  Software distribution  Configuration management  Security management Because of this, Microsoft continued its research and developed Group Policy Objects (GPOs), which, starting with Windows 2000, have replaced System Policy. Note Group Policy is implemented only on Windows 2000 and later. Windows NT 4.0 doesn't support the storage or processing GPOs. However, Windows 2000 and its successors can process the old-style Windows NT 4.0 System Policies (such as Ntconfig.pol) when a user logs on to a Windows NT 4.0 domain from a computer running Windows 2000, Windows XP, or Windows Server 2003. A local GPO exists on every workstation or server running Windows 2000, Windows XP, or Windows Server 2003. By default, a local GPO is stored in the folder %SystemRoot%\System32\GroupPolicy. The local GPO is a standalone object; you must manage it on each computer running Windows 2000 or later using the MMC Group Policy snap-in. Except for its prominence on individual computers, Group Policy shows its power in the AD infrastructure. For example, some of the GPO capabilities available in an AD-based domain environment (centralized software deployment, folder redirection, etc.) are not available on local GPOs. For GPOs to fulfill their real promise, it is necessary to deploy Active Directory and start migrating all workstations and servers to Windows 2000 or later. One of the key features in Microsoft's Change and Configuration Management (CCM) strategy is the ability to use AD as a kind of application repository. For example, in AD infrastructure you can "advertise" applications such as Word, Excel, or Visio as AD objects. These can be distributed to and installed by end users, depending upon where the objects related to the users or their computers reside in the directory. The name of the feature you use for this advertisement function is Software Installation. Specifically, Software Installation is defined within a Group Policy Object (GPO). GPOs are AD objects that can be applied to a local machine, site, domain, or organizational unit (OU). Similarly to Group Policy in Windows 2000, Group Policies in Windows Server 2003 can be applied to "containers": entire sites, domains, or OUs. A GPO is linked to a container and applied only to the computers or users whose accounts exist within it. It is rarely efficient or practical to implement site policies, so most policies will be implemented at the domain or OU level. In addition to domain policies, a local Group Policy is configured and can be adjusted on individual workstations or servers. Note The acronym LSDOU (Local, Site, Domain, OU) is used to describe the cumulative order in which GPOs are applied to users and machines. Each policy is applied during boot or logon. The local policy is applied first, then the domain policy, then the OU policy. Even within these containers, GPO application is cumulative. For example, if we have three OUs — OU1, OU2, and OU3 — the policies linked to OU1 are applied to the users and computers listed in OU2. Policies in OU1 and OU2 are applied to OU3. If a setting is not configured in a previous GPO, the new GPO's setting will be applied. If the new GPO and the old GPO have a conflicting setting, the conflict is resolved by applying the new GPO's setting. But if this setting is not configured, the previous one will remain. It is important to understand the affect GPOs have on the system registry and how they interrelate and interact with it. GPOs are multifunction AD objects, which comprise multiple "nodes" (Fig. 11.4 ). Each node within a GPO provides a different kind of control over computers (Computer Configuration node) or users (User Configuration node). Figure 11.4: GPOs are multifunction AD objects composed of multiple "nodes", each providing a different control over computers or users. Table 11.1 summarizes the most common per-computer and per-user nodes available in GPOs. Table 11.1: Available Functionality Nodes in Group Policy Objects Computer or user: Node name Description Computer: Software Settings: Software Installation Computer-based deployment of applications Computer: Windows Settings: Security Settings Computer-based configuration of security (includes items such as account policy, audit policy, and event log configurations) Computer: Windows Settings: Scripts-Starup & Shutdown Specification of computer startup and shut down scripts Computer: Administrative Templates Windows NT 1.0-style System Policy: which enforces changes to the KHLM registry key User: Software Setting: Software Installation User-based deployment of applications User: Internet Explorer Maintenance Used to set Internet Explorer preferences and "branding" settings per user User: Windows Settings: Security Settings Configuratin of user-specific IP Security and public-key usage policies User: Windows Settings: Scripts-Logon and Logoff Specification of user-specific logon and logoff scripts User: Remote Installation Services Configuration options for people using Remote Install Service to install Windows 2000/XP or Windows Server 2003 User: Administrative Templates Windows NT 4.0-style System Policy, which enforces changes to the HKCU registry key Concerning our discussion of AD and Group Policy interrelationship with the registry, the most interesting nodes to us are Software Installation and Administrative Templates. Note GPOs are applied to user objects and computer objects only. They are not applied to security groups. However, the effect of a GPO can be filtered by security groups. That is, you can have a GPO assigned to a particular OU (all of its users and computers) but restrict how that GPO is applied based on the particular security group to which those users or computers belong. One more thing to note about GPOs is their physical makeup. As outlined in Chapter 10 , GPOs are composed of two physical "pieces": the Group Policy Template (GPT) and the Group Policy Container (GPC). The first piece, the GPT, is composed of a set of files and folders that are replicated to all domain controllers in an AD domain. By default, GPOs are replicated as part of the SYSVOL share, which is created automatically on all Windows 2000 and Windows Server 2003 domain controllers. Files contained in the SYSVOL share are automatically replicated on the same schedule as the Active Directory replication. The NT File Replication Service (NTFRS) is responsible for replicating SYSVOL. The SYSVOL share resides in %SystemRoot%\sysvol\sysvol for a given domain controller. The source files for SYSVOL, however, are kept in the %SystemRoot%\sysvol\domain folder. If you expand this folder, you see a Policies subfolder. In this Policies subfolder, you see several folders with names that look like GUIDs (Globally Unique Identifiers) which they are — for the corresponding GPOs in the directory. To view a GPO's GUID using the Group Policy MMC snap-in, right-click the required GPO name and select the Properties command from the context menu. The GUID is listed as the "Unique name" for that GPO on the General tab or the GPO properties window (Fig. 11.5 ). Figure 11.5: The GUID is listed as the "Unique name" for a specific GPO on the General tab or the GPO properties window. There are a couple of ways to bring up the Group Policy tool, but perhaps the easiest is to load the Active Directory Users and Computers MMC snap-in. Right-click on a Domain or OU name and select Properties from the context menu. You'll see a Group Policy tab (Fig. 11.6 ), which lists all available GPOs at that level and lets you edit them. You can also load the Group Policy tool by typing gpedit.msc from a command line. However, when you launch the tool this way, it is automatically focused on the local GPO for that computer, rather than a domain, OU, or site-based GPO. Figure 11.6: The Group Policy tab of the GPO properties window The example illustrating a directory structure for one of the GPOs in the SYSVOL folder (Fig. 11.7 ) shows that a typical GPO contains a lot of nested directories. Files in each of these nested directories are replicated to each domain controller within a given domain. For the purposes of this chapter, we'll explore only those pieces of GPO that directly relate to registry, namely, the following subdirectories and their contents:  \Adm  \Machine\Applications\*.*  \User\Applications\*.* Figure 11.7: The example directory structure for one of the GPOs stored in the SYSVOL folder In addition to the Group Policy Template, a GPO is composed of a Group Policy Container (GPC). The GPC, in contrast to the Group Policy Template, represents the part of the GPO that resides in Active Directory itself. Thus, the GPC is a set of Active Directory Objects that are generated when you first create a GPO. To view the GPC structure within Active Directory, proceed as follows: 1. Start the Active Directory Users and Computers MMC snap-in, and select the Advanced Features command from the View menu. 2. Expand the console tree, drill down to your Active Directory domain, and it locate the folder named System within. The System folder contains a subfolder named Policies, within which you will find GUID-based folders corresponding to Group Policy Objects existing within your domain (Fig. 11.8 ). Figure 11.8: Viewing Group Policy Containers using the Active Directory Users and Computers MMC snap-in Windows Server 2003 Improvements to Group Policies As might be expected, computer-specific nodes and their settings are applied to computer objects only when the computer processes the GPO — usually at system startup and periodically thereafter. (These can be configured via Group Policy.) However, user objects process user-specific settings only at time of user logon. These settings also can be updated manually in intervals configured via Group Policy. Hence, a user could log on to a particular computer processing different GPOs — if the computer account is in one OU and the user is in another. Note You also can trigger computer and user policy manually. In Windows 2000, this could be done by using the secedit.exe command with the /refreshpolicy option. However, note that secedit.exe does not trigger any software installation policy you may have defined. In Windows XP and Windows Server 2003, use the gpupdate command to refresh Group Policy. This command replaces the Windows 2000 secedit /refreshpolicy command. If you choose not to use the gpupdate command, Group Policy will still refresh; it will just take longer. . GUID-based folders corresponding to Group Policy Objects existing within your domain (Fig. 11 .8 ). Figure 11 .8: Viewing Group Policy Containers using the Active. Figure 11 .4: GPOs are multifunction AD objects composed of multiple "nodes", each providing a different control over computers or users. Table 11 .1