Using Group Policy Preferences

  • Article

Applies To: Windows 7

Ben has identified a number of settings that he wants to configure with Group Policy for applications that do not support Group Policy settings. He also wants to configure a number of Windows features that do not provide Group Policy settings. For example, he wants to configure shared computers so that they automatically log on by using the ByaGuest account.

To do that, Ben can use Group Policy preferences in the Group Policy Management Console. In Figure 8, you see how Ben uses registry items in Group Policy preferences to configure Autologon in Windows 7. (LGPOs do not support Group Policy preferences.) By using Group Policy preferences, Ben can configure settings for applications that do not support Group Policy. Also, he can configure these settings and allowing users to change them, or he can enforce them each time Group Policy refreshes. To learn more about Group Policy preferences, see Group Policy Preferences Overview.

Figure 8  Using Group Policy preferences to configure shared computers

The key difference between Group Policy settings and Group Policy preferences is enforcement. Group Policy strictly enforces policy settings. Group Policy writes settings to the Policy branches of the registry, and the access control lists (ACLs) on those branches prevent standard users from changing them. When an application or operating system feature that is compatible with Group Policy looks for a potentially managed setting, it first looks for the policy setting. If the policy setting does not exist, it looks for the setting elsewhere in the registry.

Applications and operating system features that are compatible with Group Policy typically disable the user interface for settings that Group Policy is managing, which prevents users from changing them. Group Policy refreshes policy settings every 90 minutes, by default, but this time can be configured by a Group Policy administrator.

In contrast to Group Policy settings, Group Policy preferences are not strictly enforced. Group Policy does not store preferences in the Policy branches of the registry. Instead, it writes preferences to the same locations in the registry that the application or operating system feature uses to store the settings. The implications of this include:

  • Group Policy preferences support applications and operating system features that are not compatible with Group Policy.

  • Group Policy preferences do not cause the application or operating system feature to disable the user interface for the settings they configure.

The result is that when you deploy Group Policy preferences, users can change the settings. By default, Group Policy refreshes preferences at the same interval as Group Policy settings. However, you can prevent Group Policy from refreshing individual preferences by choosing to apply them only once. Doing so configures the preference one time and allows the user to change it.

Group Policy filtering is substantially different from Group Policy preference item-level targeting. You filter GPOs using WMI filters, and those filters determine whether Group Policy applies to the entire GPO. You cannot filter individual policy settings within a GPO. Of course, you can create GPOs based upon your filtering requirements to work around this limitation, but that might lead to a large set of GPOs to manage. On the other hand, Group Policy preferences support item-level targeting—you can target individual preference items within a GPO. For example, a single GPO can contain two preference items, both of which configure power policies. You can target the first preference item at desktop PCs and the second at mobile PCs. Additionally, whereas Group Policy filtering requires you to write sometimes complex WMI queries, item-level targeting provides a friendly user interface.