Editing Local Policies

Editing Local Policies

Policies are different from preferences, and comparing the two helps you better understand how Windows uses policies. Users set preferences, such as their desktop wallpaper, and they can change preferences any time. Administrators set policies, such as the location of the My Documents folder, and these policies take precedence over the equivalent user preference. Windows stores policies in the registry separately from user preferences. If a policy exists, the operating system uses the setting specified by that policy. If a policy doesn't exist, the operating system uses the user's preference. In the absence of a user preference, the operating system uses a default setting. The important thing to know is that a policy does not change the equivalent user preference, and if they coexist, then the policy takes precedence. Also, if the administrator removes the policy, the user's preference is once again used. In other words, Group Policy does not tattoo the registry. (See the sidebar “Tattoos on the Registry,” later in this chapter.) Table 7-1 summarizes this behavior.

Table 7-1 Policies Compared to Preferences

Policy defined?	Preference defined?	Behavior
No	No	Default
No	Yes	Preference configures
Yes	No	Policy configures
Yes	Yes	Policy configures, ignoring the preference

Windows combines policies together in a Group Policy Object (GPO). In Active Directory, there are multiple GPOs, which apply to users and computers, depending on where they are in the directory. In Windows, you have only one GPO, and that's the local GPO. Settings in this GPO apply to the local computer and to every user who logs on to it. Because the local GPO is the first GPO that Windows applies when it starts and when users log on to it, network GPOs can overwrite settings in it. For example, if you define a local policy that enables you to install Windows Installer–based (.msi) programs with elevated privileges, but the network administrator sets a network policy that disallows that, then the network policy takes precedence, and you won't be able to install these programs unless you're a local administrator for that computer. If there is no network policy to prevent it, you can install Windows Installer–based programs regardless of the group in which your account is a member.

NOTE
If you edit a policy setting without using Group Policy Editor (such as by using Registry Editor), you won't see that policy setting in the Group Policy Editor. You must manually change or remove the setting.

GPOs include settings for both computer configurations and user configurations, so GPOs contain branches for each:

• Computer Configuration.

  These are per-computer policy settings that specify operating system behavior, desktop behavior, security settings, computer startup and shutdown scripts, computer-assigned applications, and application settings. Windows applies per-computer policies both when the operating system starts and at regular intervals.

• User Configuration.

  These are per-user policy settings that specify operating system behavior, desktop settings, security settings, assigned and published applications, folder redirection settings, user logon and logoff scripts, and application settings. Windows applies per-user policies both when the user logs on to the computer and at regular intervals.

You edit the local GPO using Group Policy Editor, shown in Figure 7-1. To open Group Policy Editor, type gpedit.msc in the Run dialog box. The left and right panes that you see in the editor are similar to those in Registry Editor (Regedit), so I won't explain how to use them here. Immediately under Local Computer Policy, you see Computer Configuration and User Configuration. Computer Configuration contains per-computer policies, and User Configuration contains per-user policies. Registry-based policies, this chapter's focus, are in Administrative Templates under both branches.

Typing gpedit.msc in the Run dialog box is the quickest way to load the local computer's GPO, but you can create your own console in Microsoft Management Console (MMC) to edit a remote computer's GPO. Editing local policies on a remote computer is useful if your organization isn't using Active Directory, but it's too cumbersome to use as a general management tool, so I'd use it only in relevant scenarios:

1. In the Run dialog box, type mmc, and press ENTER.

2. On the File menu, click Add/Remove Snap-In.

3. In the Add/Remove Snap-In dialog box, on the Standalone tab, click Add.

4. In the Add Standalone Snap-in dialog box, select Group Policy Object Editor, and then click Add.

5. In the Select Group Policy Object dialog box, click Browse. In the Browse For A Group Policy Object dialog box, on the Computers tab, select the Another Computer option, type the remote computer's name in the space provided, and then click OK.

Figure 7-1 The Extended and Standard view tabs are new for Windows. Click the Extended view tab to display help for the selected policy setting.

NOTE
Windows doesn't allow you to specify security settings in a remote computer's local GPO. Thus, when you open Security Settings for a remote computer, you don't see these settings. However, even though you can't apply these settings to remote computers, you can include them in a disk image for deployment, which you learn more about in the section “Deploying Registry-Based Policy,” later in this chapter.

Tattoos on the Registry

Group Policy and System Policy, policies used by versions of Windows earlier than Windows 2000, handle changes differently from each other. Windows automatically removes a GPO's settings from the registry when the GPO no longer applies to the user or computer. Also, Group Policy doesn't overwrite users' preferences. So if you delete a GPO from Active Directory, Windows removes that GPO's settings from the registry and reverts back to following users' preferences. Likewise, if you remove an individual policy from a GPO, Windows removes that setting from the registry and restores users' existing preferences. Group Policy doesn't make permanent, irreversible changes to the registry.

System Policy does make permanent, irreversible changes to the registry, though. In other words, it tattoos the registry. When you remove System Policy, all the policies that it contained remain in the registry. The only way to restore users' preferences, assuming that these policies don't overwrite their preferences, is to manually remove the policy from the registry or explicitly change the setting in System Policy. This is one of the scenarios you learn to grapple with in Chapter 18, “Fixing Common IT Problems.” One of the nastier incarnations of this behavior can occur when you upgrade from an earlier version of Windows to Windows XP or Windows Server 2003. When you upgrade, policies in the registry are permanent, so you must manually remove them from the registry; Windows doesn't remove them automatically.

Group Policy Extensions

Group Policy has several extensions that you can use to configure GPOs. In fact, each of the different nodes that you see in Group Policy Editor is an extension. By default, the editor loads all the available extensions when you start it. Computer Configuration and User Configuration contain different extensions, and you see more extensions when you're editing a network GPO in Active Directory than you see when you're editing a local GPO. The following list summarizes some of the extensions that Group Policy provides in a local GPO. (Network GPOs provide more.)

• Scripts.

  You can assign to users scripts that run when they log on to or log off Windows. You can assign to computers scripts that run when Windows starts and when it shuts down. You see this extension in the Windows Settings folder.

• Security Settings.

  You can manage security settings, including password, audit, and lockout policies. You can also manage user rights and restrict the applications that users can run. You see this extension in the Windows Settings folder.

• Administrative Templates.

  Group Policy creates a file containing registry settings that are written to HKCU or HKLM in the registry. Windows loads settings from this file as the operating system starts and when users log on to the computer. These are registry-based policies.

Registry-Based Policy

Registry-based policies and administrative policies are two names for the same thing. They're registry settings that overwrite users' preferences, and there are good reasons that users can't change them, which you'll learn about in this section. Other policies, including security settings, might or might not be registry settings. In Group Policy Editor, you find registry-based policies in the Administrative Templates folder under Computer Configuration and User Configuration.

Figure 7-2 shows the workflow of using registry-based policies. Administrators use Group Policy Editor, which you saw in Figure 7-1, to define policies. Administrative templates, files with the .adm extension, define the policies that administrators can set. Administrative templates and policy templates are the same thing, and you frequently see these referred to as ADM files. These templates describe the user interface for collecting settings from the administrator and the locations of these settings in the registry. When the administrator defines policies, the editor stores them in a file called Registry.pol. Windows loads the settings contained in Registry.pol when the operating system starts, when users log on, and at regular intervals. The next section, “Group Policy Storage,” describes where in the registry Windows stores policies and where you find Registry.pol.

The following extensions work together to implement registry-based policy:

• The Administrative Templates extension, which you use to edit policy settings. This extension is the Administrative Templates folder in Group Policy Editor. It creates the Registry.pol file based on settings that the administrator defines.

• A built-in registry client-side extension (available only in Windows 2000 or later), which processes policies and creates their corresponding values in the registry. Although the client-side extension is responsible for reading settings from Registry.pol and writing them to the registry, Windows and other applications must look for and use these settings to give them meaning.

Windows comes with administrative templates that define all the policies that the operating system supports. If you want to use policies for an application, such as one in Microsoft Office 2003 Editions, you must load the administrative templates for it. In fact, the Microsoft Office 2003 Editions Resource Kit comes with many administrative templates that help IT professionals better manage the entire productivity suite. Windows provides the following administrative templates:

• System.adm.

  Core settings and primary template file, defining most of the settings that you see in Administrative Templates

• Wmplayer.adm.

  Windows Media settings

• Conf.adm.

  NetMeeting conferencing software

• Inetres.adm.

  Microsoft Internet Explorer

All registry-based policies are set to one of three states: Enabled, Disabled, or Not Configured. Figure 7-3 shows these settings on a sample policy. Enabled explicitly turns on the setting by adding the setting to the registry with a value of 0x01. Disabled explicitly turns off the setting by adding the setting to the registry with a value of 0x00 (or removing the value altogether). The Not Configured option removes the setting from the registry altogether, which then yields to the user's preference. Many policies collect additional settings, as shown in the figure.

Figure 7-2 Registry-based policies start with administrative templates, which define the settings that are available and the location where they are stored in the registry.

Figure 7-3 Each policy has three states, Enabled, Disabled, or Not Configured, and some policies collect additional information.

When setting a policy, pay particular attention to the explanation to ensure that you get the result that you want. Some policies are positive, so enabling the policies turns on the features. Other policies are negative, however, so turning on those policies actually disables those features. To make things more confusing, outside of Windows, you frequently see policies that you have to enable, and then you have to turn the setting on or off. In other words, to turn on a setting, you have to enable the policy and then select or clear a second check box to turn the setting on or off. The Office 2003 Editions policy templates are notorious for this extra level of indirection. All this just illustrates that you have to pay close attention to the names of policies when setting them. Read their names out loud, prefixing the sentences with the words “enable” or “disable”–just to be sure.

Group Policy Storage

Where does Windows store policies in the registry and on the disk? The branch \Software\Policies is the preferred branch for storing registry-based policies. In HKLM, this branch contains per-computer policies, and in HKCU, this branch contains per-user policies. Another branch, inherited from earlier versions of Windows, is \Software\Microsoft\Windows\CurrentVersion\Policies. Policies in this branch tend to tattoo the registry, which means they make permanent changes to the registry; you must explicitly change these policies. Access control lists (ACLs) prevent users from changing these keys and thus the policies that they enforce. The Users and Power Users local groups do not have permission to change values in these keys, but an administrator can overwrite these keys directly to change the policy.

Now that we've covered the location of policies in the registry, we'll move on to covering their location in the file system. The local GPO is in %SystemRoot%\ System32\GroupPolicy. This is a super-hidden folder. To show it in Windows Explorer, click Tools, Folder Options; on the View tab of the Folder Options dialog box, select the Show Hidden Files And Folders option, and then clear the Hide Protected Operating System Files check box. This folder contains the following subfolders and files. (Our focus is the file Registry.pol.)

• \Adm.

  Contains all the ADM files for the local GPO.

• \User.

  Includes the file Registry.pol, which contains registry-based policies for users. When users log on to the computer, Windows applies these to HKCU.

• \User\Scripts.

  Contains the local GPO's per-user scripts. The scripts in \Logon run when users log on to Windows, and the scripts in \Logoff run when they log off the operating system.

• \Machine.

  Includes Registry.pol, which contains registry-based policies for the computer. When Windows starts, it applies these settings to HKLM.

• \Machine\Scripts.

  Contains the local GPO's per-computer scripts. The scripts in \Startup run when Windows starts, and the scripts in \Shutdown run when the operating system shuts down.

TIP
You can copy the %SystemRoot%\System32\GroupPolicy folder from one computer to another to replicate the local policies it contains. Test before using this tip in a production environment.

If you're familiar with System Policy and the file Ntconfig.pol, you're probably wondering whether the files Registry.pol and Ntconfig.pol use similar formats. They don't. Both are binary files, but Registry.pol is much simpler. It contains a simple list of settings, including their value names, type, and data, in a binary format. Ntconfig.pol is actually a registry hive file that you can load and browse in Regedit. Unfortunately, you can't do the same with Registry.pol.

NOTE
Domain GPOs are more complicated than local GPOs are. Active Directory stores policies in \\Server\Sysvol\ Domain\Policies, where Server is the name of the domain controller, Sysvol is a share name, and Domain is the name of the domain. Each GPO is in a subfolder, and the name of the subfolder is the GPO's GUID. (See Chapter 1, “Learning the Basics.”) The structure of each GPO's subfolder is similar to the structure of the local GPO described in this chapter. In the domain GPO, though, the \User and \Machine folders have additional subfolders, and the various Group Policy extensions create these.