New Group Policy Features in Windows Vista

• Network Location Awareness

• ADMX templates

• ADMX repository

• Improved logging

Multiple Local GPOs

Some historical background will help you understand what has changed with local GPOs on a Windows Vista desktop. In previous versions of Windows, there was a single local GPO on every server and desktop. Beyond the local GPO on the individual computers, there could be many GPOs in Active Directory linked to the domain, organizational units, and sites. The local GPO had no power over the Active Directory GPOs unless nonconflicting settings were established. In such a case, the local GPO settings would make their way through the maze of Active Directory GPOs to the Resultant Set of Policy (RSoP) that molded the final policy settings on the computer.

Multiple Local GPOs were put into place in Windows Vista to solve many issues. One of the biggest problems this feature solves involves handling the ability for both users and administrators to log on to the same desktop, but be treated differently. Before Windows Vista, if local GPOs were configured to constrain the user account, both the administrator accounts and regular user accounts would receive the constraining settings. This caused some very odd results, either allowing the user to have too many privileges or restricting the administrator too severely. If the administrator needed to run elevated tasks in a restricted environment like this, he or she was forced to use “Run As” or other privilege-elevating technologies. Although this is an almost ideal situation, it can cause some issues in companies that do not want such restrictions on administrators logging on to desktops.

Windows Vista tackles all of these issues with new technology related to the local GPO. In reality, there is no longer just a single GPO on the local desktop, but three local GPOs, which Microsoft refers to as Multiple Local Group Policy objects (MLGPO). These three GPOs provide granular control over the users who log on to the desktop. Local GPOs can be used in a single-computer environment, home environment, small business environment, or even large corporate scenario.

The three local GPOs are designed to control desktop users in a hierarchical manner. This hierarchy allows control over the settings that will be configured in GPO. The three MLGPO options consist of the following, in their proper hierarchical order:

• Local Policy Object

• Administrators and Non-Administrators Local Group Policy

• User-specific Local Group Policy

Local Computer Policy Object

The Local Computer Policy Object is identical to the local GPO in Windows 2000 and Windows XP. It can be accessed by using the Group Policy Management Editor (by running Gpedit.msc from the Run dialog box) or using the Microsoft Management Console (MMC). In either case, you can control both Computer Configuration and User Configuration settings, as shown in Figure 1.

Figure 1. The local Group Policy can be opened in the Group Policy Management Editor by clicking Start, clicking Run, and then typing gpedit.msc in the Run dialog box.

Administrators and Non-Administrators Local GPOs

The Administrators local GPO and the Non-Administrators local GPO are new in Windows Vista. As their names indicate, the GPOs in this layer are designed to control two types of user accounts. The delineation is based on which users have membership in the local Administrators group.

The reason for this delineation is obvious. The settings for administrator-type accounts and nonadministrator-type accounts should be different on a desktop. Without these two options for local GPOs, it is nearly impossible to make a distinction between these two types of user accounts.

These two GPOs are not easy to access, however. To access these GPOs, you must use the MMC. This console exposes both of these GPOs so that administrators can manage them, as shown in Figure 2.

Figure 2. Both the Administrators local GPO and the Non-Administrators local GPO can be edited in the MMC.

User-Specific Local GPO

The final local GPO layer is the user-specific local GPO. This GPO offers definitive granular control because it allows you to specify an individual user account to receive special GPO settings. Do not use this GPO option very often, because individual user account settings are typically discouraged from an administrative efficiency standpoint.

This type of GPO is very useful on specialized desktops throughout the environment. Such desktops might include those functioning as a kiosk, those in a training or educational facility, or even those that have a shared user account. In such cases, the user account used to log on to these special desktops has a unique set of GPO settings, where all other user accounts are controlled by the Local Policy Object or even the Administrators or Non-Administrators local GPOs.

You do not access the administration of this type of GPO through the Group Policy Management Editor directly; rather, it is accessed through the MMC. When using the MMC to open this GPO, you select the GPO that is associated with any one of the local user accounts that are configured in the local Security Accounts Manager (SAM). After you add your GPO into the MMC, the interface will include only User Configuration settings. Because this local GPO affects user accounts only, the MMC removes Computer Configuration settings so that they do not confuse the administrator of the local GPO. This can be seen in Figure 3.

Figure 3. The local user-specific GPOs can be edited in the MMC and allow control over User Configuration settings only.

Precedence and Application

Now that there are Multiple Local GPOs to configure and choose from, it is important to understand how they are tiered in the hierarchy, in case there are ever any conflicting settings among them. The hierarchy of local GPOs is predetermined and creates the precedence for conflicting settings in different local GPOs. The most generic GPO has the least precedence, and the most specific GPO has the most precedence. Thus, the local GPO has the least precedence, the user-specific local GPO has the highest precedence, and the Administrators/Non-Administrators local GPOs fall between these two. The order of precedence from lowest to highest is summarized as follows:

• Local GPO

• Administrators/Non-Administrators

• User-specific local GPO

The hierarchy of the local GPOs must also coordinate with the GPOs that administrators link with Active Directory. The same rules apply here as before, where the local GPOs have the weakest precedence when compared to the GPOs from Active Directory.

Network Location Awareness

The Network Location Awareness technology that Windows XP delivered has been a successful solution for many aspects of the operating system and network connectivity. This technology allows the computer to be fully aware of its state and communication capabilities, thus allowing it to make intelligent decisions based on that state.

Group Policy has historically relied on dependable, yet not the most impressive, network identification technology. In the past, Group Policy has used the Internet Control Message Protocol (ICMP) to determine the state of the network, as well as network link speed. ICMP, which encompasses the PING command, is great for getting some network information, but it has not been ideal for helping Group Policy application.

Now that Group Policy relies on Network Location Awareness, the overall picture and state of Group Policy have been enhanced. Group Policy uses network location awareness in two primary fashions: it determines link speed, and it uses network location awareness to determine whether the computer needing to refresh Group Policy is connected to the domain.

For the first use of Network Location Awareness, Group Policy determines whether the link from the computer receiving GPO settings has a fast or slow connection to the domain and domain controllers. Because some GPO settings can take a long time to apply because of the amount of data being sent, determining link speed can be an indicator as to whether the data should be sent at all. Network Location Awareness provides this assistance by determining the bandwidth of a TPC connection. Group Policy can then use this information to make decisions regarding the settings that it should deliver based solely on the bandwidth available.

Group Policy also uses Network Location Awareness for background refreshes. Network Location Awareness indicates whether the computer has authenticated to a domain controller and whether the domain controller is available to the computer. This feature is important for computers that have failed to refresh Group Policy because the domain controller was not available. In the past, when Group Policy failed to apply, the computer would wait until the next refresh interval—90 to 120 minutes—to attempt to apply Group Policy. The domain controller might have been available only minutes after the failed refresh, but the system would wait the full refresh interval to apply the Group Policy updates. With Network Location Awareness, the Group Policy refresh occurs as soon as it detects the connection to the domain controller.

ADMX Templates

A change that surprised some, but was needed, was a new form of administrative template. The old ADM formatting was limiting in many ways, so a new format was developed. The new format, based on XML, has more flexibility and power than the old format. The new XML-based files have an .admx extension and have changed substantially from their predecessors. A sample of the new XML formatting is shown in Figure 4.

Figure 4. The ADMX files are now based on XML for flexibility of language and ease of administration.

The XML formatting was adopted primarily for its language flexibility. ADM formatting did not translate into other languages, forcing other countries and languages to use English, which is not always feasible. During migration to the new format, the structure of the ADM files was radically enhanced also. With the ADM structure, all settings lived in five ADM files. Now there are 132 ADMX files that contain all of the administrative template policy settings. Figure 5 shows some of these policy settings.

Figure 5. Now that the ADMX files are XML-based, 132 individual templates make up the Administrative Templates section of a GPO.

These new ADMX files reside by default on the local system drive of computers running Windows Vista and Windows Server 2008. The path to these ADMX files is %SystemRoot%\ PolicyDefinitions, which is usually the default C:\Windows folder that the operating system uses to store the system files.

ADMX Repository

In conjunction with the changes to the administrative template file structure and formatting, GPO administrators create and utilize the central store so that all ADMX files now reside in one location, instead of administrators spreading these files throughout the network on their local computers.

ADM templates were difficult to control and manage, which is one of the major reasons for the change. Another key reason involved how each GPO handled ADM templates. Every GPO that administrators created copied the entire set of default ADM templates into the location where GPO settings were maintained (referred to as the Group Policy template). The Group Policy template is located on domain controllers. Because there can be hundreds or thousands of GPOs, the space required to store these ADM templates was substantial. With each set of default ADM templates (coming in at a massive 4 MB of data) being stored on domain controllers, this could also add to replication traffic between domain controllers.

These negative aspects triggered the development of new technology for handling administrative template files. If an administrator does not create the repository, the local ADMX files will still be used to edit a GPO. This keeps the administration of GPOs consistent, even if the technology is not used. It should be noted, however, that the ADMX files are not stored in the Group Policy template. This change helps with storage of files on domain controllers, as well as the replication of those files between domain controllers.

Improved Logging

It is no secret that managing logging and documentation has been a struggle for Group Policy over the years. Obtaining information from the old Event Log entries was a bit problematic. You needed to be an expert in Group Policy and Microsoft server technologies to get much from the logging that occurred in the Event Viewer. The other logs, such as Userenv.log, were better, but still not ideal.

All of this has changed with the latest installment of GPO logging. The changes are like many of the other changes: stunning and extraordinary. The new logging is built within the updated Event Log service that is available with Windows Vista. It disposes of Userenv.log and instead stores information in a Group Policy Operational log found in Event Viewer. You can find this log in Event Viewer by opening Applications and Services Logs and then browsing to Microsoft\Windows\GroupPolicy\Operational. The resulting log view is shown in Figure 6.

Figure 6. With the new logging that is available for Group Policy, new Group Policy events can be seen in the operational logs.

These new logs also provide specific new features that help with extraction of information. The logging technology provides for forwarding events to a central location; this is called subscribing to an event. Another benefit of the new log structure is the ability to filter views of specific events, making mining information from large log files more efficient.