Executive Summary:
| You can configure and process multiple Local Group Policy objects in Windows Vista. |
| Windows Vista gives you the ability to manage multiple Local Group Policy objects for machines that aren't in an Active Directory domain. |
| In Windows Vista, you can configure Local Group Policy, Administrators Local Group Policy, Non-Administrators Local Group Policy, and user-specific Local Group Policy objects. |
Computers that aren't managed as part of a Windows Active Directory (AD) domain, such as shared lab computers, library kiosks, and demo workstations, can have security and other configuration settings defined in their Local Computer Policy. One of the main drawbacks to having these settings defined in the Local Computer Policy object in Windows versions prior to Windows Vista is that only one policy can be applied to machines that aren't connected to a domain, and that policy will affect all the users of that machine. Therefore, administrators who need to log on and manage the machine without restrictions can't easily avoid settings that apply to standard users.
However, in Vista you can process multiple Local Group Policy objects, allowing for more flexible security and configuration management of machines that aren't part of an AD domain. Let's take a look at how multiple Local Group Policy objects are processed in Vista and how to configure different settings for each of your local machine users. (Note that in this article, "policy" refers to Local Group Policy rather than AD Group Policy, unless otherwise stated.)
Multiple Local Group Policies
Windows versions prior to Vista have only one Local Group Policy object, Local Computer Policy, which contains both computer and user configuration settings. Local Computer Policy (also known as Local Group Policy) still exists in Vista and can be used the same way it is in Windows XP and Windows 2000. For example, in Vista, you can use Local Group Policy to define settings that affect all the users of a given machine.
However in Vista, you also have finer-grained capabilities. You can define a Local Group Policy, which contains both user and computer settings, and you can define an Administrators Local Group Policy and a Non-Administrators Local Group Policy, both of which can contain only user settings. You can also create any number of user-specific Local Group Policies, which apply to local user accounts and contain only user settings. Note that only one policy can be applied to a user at a time, and Vista automatically calculates which policy should be applied based on the user's local group membership. For example, Vista will apply the Non-Administrators Local Group Policy to user accounts that don't belong to the local Administrators group.
Local Group Policy Processing
With the ability to create so many Local Group Policies in Vista, the order in which Local Group Policy objects are applied is important. As with AD Group Policy, there's a processing hierarchy: Local Group Policy is the first policy to be applied, then Administrator or Non-Administrator Local Group Policy, and finally any policy that’s defined for a specific user. The last policy to be processed takes precedence over the other policies.
The following steps show how to configure multiple Local Group Policy objects and how they're processed. Before you begin configuring multiple Local Group Policy objects, create a local user account (which you'll test the Local Group Policies against) that's a member of only the local Users group.
- Log on to Vista with an account that has administrative privileges, type mmc into the Run field on the Start menu, and click OK.
- In the Microsoft Management Console (MMC), select File, then Add/Remove Snap-in. Under Available snap-ins select Group Policy Object Editor and click Add.
- In the Group Policy Object Editor dialog box, make sure that Local Computer is displayed under Group Policy Object and click Finish. Local Computer Policy should now be displayed under Selected snap-ins in the Add/Remove Snap-ins window.
- To add another Local Group Policy to MMC, make sure that Group Policy Object Editor is still selected under Available snap-ins and click Add. Then, click Browse in the Group Policy Object Editor.
- Select the Users tab, highlight Non-Administrators, and click OK, as shown in Figure 1. The Local Group Policy object will appear as Local Computer Policy\Non-Administrators in MMC.
- Repeat steps 4 and 5 to add a third Local Group Policy object to MMC, but under the Users tab, select the local user account that you created earlier. Then, click OK in the Add/Remove Snap-ins window to return to the populated MMC.
The three Local Group Policy objects that you added to MMC (Local Computer Policy, Local Computer Policy\Non-Administrators, Local Computer Policy\User) should be available for editing.
Now, let’s configure each Local Group Policy object's Hide Desktop tab setting (found under User Configuration\ Administrative Templates\Control Panel\Display, as shown in Figure 2) to set up a demonstration of how multiple Local Group Policy objects are processed. Table 1 shows how each Local Group Policy's Hide Desktop tab setting should be configured.
After you’ve configured the setting in each Local Group Policy, open a command prompt and enter the following command to force immediate processing of Local Group Policy:
gpupdate /force
Then, log on with the standard user account for which you created a user-specific Local Group Policy (Local Computer Policy\User), and open Control Panel. Although the user isn't a member of the local Administrators group, you can still see the Desktop tab and change the desktop background because Local Computer Policy\User was the last policy to be processed; therefore, its disabled setting takes precedence over Local Computer Policy\Non-Administrators' enabled setting.
Now, close Control Panel and switch back to an administrator account to modify Local Computer Policy\User so that the Hide Desktop tab setting isn't configured. Then, run the
gpupdate /force
command again, go back to the user account, and open Control Panel. This time, when you try to change the desktop background, a message should appear that says the feature has been disabled, as shown in Figure 3. This time, the Non-Administrators Local Group Policy's hide-desktop setting takes precedence because the user-specific Local Group Policy doesn’t have the setting configured. Any local machine users who are members of the Administrators group will be able to configure a desktop background, but all other users will be denied access to the desktop settings.
Removing Local Group Policy Objects
Although it's possible to remove Administrator/Non-Administrator or user-specific Local Group Policies, you can't remove Local Group Policy objects themselves. To remove Administrator/Non-Administrator or user-specific Local Group Policies, right-click the policy you want to remove, select the Remove Group Policy Object option in the menu, and click Yes.
Disabling Local Group Policy Processing
It might be useful to disable Local Group Policy processing if a domain user has local administrative rights on a machine and you want to ensure that he or she applies only domain-based policies. You can disable Local Group Policy processing when a machine is connected to an AD domain by selecting the Turn off Local Group Policy objects processing setting, which can be found under Computer Configuration\Administrative Templates\System\Group Policy.
The ability to process multiple Local Group Policy objects in Vista is handy in situations in which each user of a computer must have different security or configuration settings defined and the computer isn't connected to a domain. Multiple Local Group Policy objects are processed similarly to AD Group Policies, making the principle of Local Group Policy easy to understand. Although processing multiple Local Group Policy objects can potentially make Vista configuration more complicated, it shouldn’t affect your planning for domain-based Group Policy Objects (GPOs). Configuring multiple Local Group Policy objects lets you have greater control over security and configuration management when domain-based management isn't available or desirable.
