Group policy in Windows Vista

Windows Vista makes a number of changes to the implementation and management of group policy objects (GPOs) and, as group policy is something that I haven’t worked with for a while, I figured it was time to take another look. A week or so back, I spent the morning at Microsoft, where Steve Lamb presented a session on using Group Policy in Windows Vista to control user behaviour and network security.

Policy has existed in various versions of Windows for a long time but group policy was introduced in Windows 2000 (enforced by Active Directory) and many group policy settings are also available as local computer policies (used when a machine is not authenticated by an Active Directory domain controller). Each new version of Windows brings more control over what can be controlled using policies and Windows Vista is no exception with a significant increase in the available options (Microsoft quotes various figures but they all indicate at least 2000 new settings). The new areas covered include removable device management, power management and user access control. There are also new management tools the group policy management console (GPMC) is now included with Windows (previously, it was a separate download ) and the group policy editor (gpedit.exe) now supports filtering of administrative template policy settings via a context-sensitive option on the view menu to show, for example, only those settings that apply to at least Windows XP Professional with SP2.

Windows Vista also makes improvements to policy control around network awareness, detecting changes in network conditions (e.g. connecting to a new network) and enforcing new policy settings accordingly. There are also improvements to the application of policy (with fewer requirements for synchronous application of policy).

It’s important to note the difference between a policy – stored in a subfolder (machine or user) on the domain controller under %systemroot%\sysvol\sysvol\domainname\policies\guid\ – and policy definition files – stored at the same location but simply defining the available settings.

Although Windows Vista will still act on legacy (.adm) policy definition files, policy definitions created under Windows Vista use a new XML-based file format with an .admx extension. Furthermore, Windows Vista group policy uses separate .adml files to provide the language-specific textual components of each policy.

When editing policy on a Windows Vista computer, the policy definition files are stored at %systemroot%\policydefinitions\ with one .admx file for each area of control and associated .adml files in each language subfolder (e.g. en-us).

These can be copied to the central store (really just a grand name for the policies folder that is replicated as part of sysvol) in order to make them available for administration from multiple locations. Central store copies of policy definitions will then take precedence over local copies (but legacy clients will be unaffected by the new settings).

Although legacy clients will simply ignore policy settings that they do not understand, Microsoft recommends that once Windows Vista policies are implemented, then no further policy edits should be made from pre-Vista computers. The reasoning for this is that even opening the policy definition on a pre-Vista computer will cause the legacy .adm files to be created on the sysvol and this leads to a phenomenon known as sysvol bloat. By using only Windows Vista clients for group policy management, this bloat can be avoided. It’s also worth noting that GPO reporting should be performed within the Windows Vista version of the GPMC (rather than using the resultant set of policy MMC snap-in) and that new policy backups should be taken using the Windows Vista GPMC to avoid issues when restoring policy backups taken from GPMC running on Windows XP/Server 2003. Further details for managing group policy administrative template (.adm) files can be found in Microsoft knowledgebase article 816662.

For bringing forward settings from legacy (.adm) policy templates, Microsoft has licensed the ADMX Migrator utility (from Full Armor).

Another new feature with Windows Vista group policy is the ability to define multiple local policies (administrator, non-administrator and per-user) and even to disable local policy altogether on domain-joined computers. Whilst the local computer policy remains (and is created by default), further local policies may be created using the group policy editor. This is useful for computers over which some control is required but which fall outside the scope of management for Active Directory (e.g. kiosks or computers deployed in a DMZ).

Troubleshooting group policy is aided with Windows Vista’s improved event logging (with more useful events and links to support information on the Internet) as well as the ability to view events in friendly (human-readable) format or XML (for analysis/processing). The new event viewer also supports the ability to create subscriptions. Actions can also be associated with events (e.g. send an e-mail, or execute a script).

Filters can be used to view just group policy events and by drilling down into the appropriate logfile, an activity ID can be extracted from a failure event to further filter events, or to view with the group policy log view (gplogview.exe) – another free download from Microsoft. This allows for step-by-step group policy processing to identify the failure point and any error codes, after which changes can be made and gpupdate.exe used to apply the new settings for re-analysis.

For enterprise customers, Microsoft has a new tool for advanced group policy management – GPOVault is part of the desktop optimisation pack for software assurance (DOPSA), gained as part of Microsoft’s acquisition of DesktopStandard.

Further information

Microsoft resources:

MVP and community resources:

3 thoughts on “Group policy in Windows Vista


  1. Great article, but… one clarification. PolicyMaker isn’t part of MDOP – the Desktop Optimization Pack. GPOVault == the Advanced Group Policy Management piece, but no PolicyMaker.


  2. Hi Glenn,
    Steve Lamb should take most of the credit for this article – it’s based on his presentation; however the mistake about PolicyMaker was mine.

    Thanks for the correction (I’ve updated the post).

    Mark

Leave a Reply