To some extent, this has been a result of the design philosophy that defined Active Directory's characteristics (in particular, its dependency on Group Policy-aware applications and services). On one hand, this ensures consistent behavior; on the other, it restricts its scope. To address this limitation, Microsoft decided to provide an alternative approach, which offered completely new range of possibilities, although not without some negative consequences. This new methodology has evolved into Group Policy Preferences, which are the subject of this article.
Group Policies were designed in the manner intended to ensure their deterministic outcome, allowing you to enforce a desired configuration of a target user or computer. This premise is contingent on availability of a managed software component that is aware of registry-based mechanism employed by them. This enables their settings to take precedence over locally applied configuration and prevent its modifications by disabling appropriate options in graphical interface.
The software component checks for the presence of Group-Policy-specific entries within designated registry branches. As long as they are present, it processes them accordingly. This arrangement not only ensures consistent user experience, but it also facilitates rollback if a target object gets removed from their scope, reverting automatically to its original state after the relevant registry entries are deleted by the Group Policy engine. While the dependency on Group Policy aware software severely limited the variety of settings that could be administer this way, the resulting framework (including management tools and Client Side Extensions) made it possible to deploy other registry-based settings. These are not included in standard policies and reside outside of designated Group Policy specific registry locations.
Such deployments involved applying settings (known as "preferences") defined in custom Administrative Templates (
.ADM files) to Group Policy objects linked to Active Directory containers hosting target objects. Although this method was identical to the one used to deploy Group Policies, the results differed due to lack of "preference-awareness." It yielded changes that persisted after policy removal and were not integrated with applications or services affected. As the result, they were not subject to the same level of protection from user-initiated changes as policies).
Group Policy Preferences constitute a significant improvement over those custom registry modifications. Not only is it no longer necessary to deal with Administrative Templates, for which edits tend to be fairly cumbersome, but there is also an additional set of options that control deployment specifics. For example, you can choose not to tattoo registry (although this simply means that target registry entries are reset to their defaults, which still might be different from their original values) or decide how their refresh will be handled. More importantly, you also have access to rich filtering capabilities (by far exceeding those available with Group Policies), allowing you to define wide variety of conditions that determine whether individual preferences should be applied.
However, despite a fairly common misconception, Group Policy Preferences can be used in Windows Server 2003-based domains, as long as managed computers are running Windows XP SP2 or newer (although they will require additional client software and you will need at least one Windows Server 2008 or Vista computer to configure them).
Group Policy Preferences are accessible via two folders (labeled
Preferences), appearing under
User Configuration nodes in the Group Policy Management Editor while viewing a domain-based Group Policy Objects (invoked via Group Policy Management Console on a computer running Windows Server 2008 or Vista with Remote Server Administration Tools installed). Within both folders, you will find two nodes, labeled
Windows Settings and
Control Panel Settings, containing collections of individual preference extensions. In this article, we will focus on the first of them. The next installment of this series will focus on the latter.
Windows SettingsApplications One of a few user-specific extensions without its computer equivalent, it allows you to configure user settings of applications with their own Group Policy Preferences plug-ins installed on a computer on which you are running the Group Policy Management Editor console. Unfortunately, so far, neither Microsoft nor any of the independent software vendors have provided support for this functionality.
Windows SettingsDrive Maps Another user extensions without its computer equivalent, it allows you to create, replace, update or delete drive mappings. For each of them, you can specify location (with the
Find Custom Searchdialog box facilitating querying Active Directory for published shares), label (
Label astextbox), persistency (
Reconnectcheckbox), drive letter (
Use first available starting at:or
Use:), and optional
Connect ascredentials (passwords you specify are encrypted 256-bit AES algorithm prior to being stored in an XML file residing within GPO-specific folder hierarchy under
In addition, you also can control whether the currently configured drive mapping (or all of them) will be hidden (individual drive settings take precedence over those configured for all drives). Note that the
Locationfield supports preferences variables, invoked by pressing
F3key that accommodate creating mappings to shares which path contain
%username%or other environment variables. While this extension is not a subject to background processing (it requires for a target user to re-logon to take effect), its existence underscores importance of Group Preferences as a viable replacement of user logon or computer startup scripts - especially considering wide range of capabilities exposed through all extensions we will present here.
Windows SettingsEnvironment Creates, replaces, updates or deletes arbitrary system environment variables. A special provision (represented by
Partialcheckboxes) allows you to modify content of the
PATHsystem environment variable. You have an option of either replacing its content entirely (with create or update option), or deleting as well as creating its individual semicolon-separated segments (exclude the semicolon when typing in an entry).
Computer Configurationnode you can define user environment variables that affect programs and services running in the security context of the Local System account (stored within the
.DEFAULTregistry hive). The equivalent entry under the
User Configurationnode affects standard user accounts (residing in their respective
HKEY_CURRENT_USERregistry hives). Environment variables also play an important role in item-level targeting, which we will discuss in more details in our upcoming article.
Windows SettingsFiles Creates, replaces, updates or deletes files using target and, if appropriate, source file paths that you specify. Both environment variables and wildcards are permitted, allowing you to copy groups of files sharing common characteristics, such as name or extension without the need for hard-coding their location. You can also assign attributes of files at their destination (Read-only, Hidden or Archive). This extension exists in both
Computer Configurationnodes. Hence the decision that the one chosen would depend primarily on whether you want to target a specific set of users or computers.
Windows SettingsFolders Creates, replaces, updates or deletes folders using an arbitrary target path, which can include subfolders and environment variables. Delete action has a number of additional, configurable options, allowing you to handle nested folders (along with their content), read-only attributes, and run-time errors, as well as to remove all files while leaving the folder structure intact. This might be useful when implementing disk clean up as part of routine maintenance procedures. Just as with Files extensions, the same settings are available under
Windows SettingsIni Files Creates, replaces, updates or deletes individual entries within a designated section (specified in the
Section Nametextbox without enclosing brackets) of arbitrarily chosen configuration files that comply with standard
INFformat. As expected, the update action either adds a new entry to an existing section or creates a new one. Deletions can target individual entries, sections, or entire files. Again, the same settings exist in both
Windows SettingsRegistry Configurable via second-level context-sensitive submenus labeled
Collection Item, and
Registry Wizard. The first of them allows you to create, replace (which, in this context, is equivalent to update), or delete arbitrary registry keys or entries of
REG_BINARYdata types (it is worth noting that the last two of these are not supported via Administrative Templates).
The second one facilitates grouping multiple registry changes together (into containers called collections), typically to apply the same targeting rules to all of them (we will cover this topic in an upcoming article) or to organize their layout in a manner reflecting their actual registry location. The third one simplifies configuration of registry settings by extracting them from either a local or remote computer (eliminating the need to type them in manually), creating also a corresponding collection hierarchy (the resulting entries can be altered afterwards). While both
User Configurationnodes contain the same sets of options, the latter is intended primarily for modifications to
Windows SettingsNetwork Shares The only
Windows Settingscomputer extension without its user equivalent, creates, replaces, updates, or deletes shares on a target computer. For each share, you have an option to set its user limit or enable Access-based Enumeration, which restricts visibility of its content based on the underlying NTFS permissions. This feature requires at minimum Windows Server 2003 SP1. Note, however, that you cannot modify their share-level permissions or automatically create underlying folders. In the context of this extension, replacement constitutes a change to shared folder path or modifying its user limit and Access-based Enumeration characteristics. The Update action lets you apply equivalent changes across multiple targets (all regular shares, all hidden non-administrative shares, or all administrative drive-letter shares). The same collections can be used in combination with Delete option, giving you the power to disable all shares, with exception of such default shares as
FAX$. These can still be managed via individual updates.
Windows SettingsShortcuts Creates, replaces, updates or deletes shortcuts pointing to file system objects, URLs, or shell objects (special folders that do not correspond to actual file system locations, such as Computer, Network, Control Panel, Printers, or Recycle Bin, as well as their content). You have an option of deploying the resulting shortcuts to all users (by targeting
All Usersitems) or limiting their scope to individual profiles. You can also assign a unique icon to each shortcut (via
Icon file path:and
Icon index:properties). Since this extension contains the same set of settings in both
Computer Configurationnodes, choosing the appropriate one should be based on whether you intend to deploy shortcuts to users or computers as well as dependencies on other extensions, such as, user-specific drive mappings.
In the next article of our series, we will continue the coverage of Group Policy Preferences, starting by taking a closer look at the Control Panel-based user and computer extensions.