Windows XP Power Management and Group Policy Preferences

This scenario covers managing power on Windows XP client computers using Group Policy Preferences. Let’s cover how Windows XP manages power before we cover Group Policy Preferences Power Management.

Windows XP Power Management

Windows XP only has one active power scheme for the entire computer and that scheme is based on the current or previously logged on user—that is to say Windows XP power schemes are only user-based. This means the power scheme can change as each user logs on. Also, it means that last logged on user’s power settings are the settings that remain once the user logs off. And yes, each user has its own power configuration; however, the entire operating system only has one active power scheme.

A recently started computer at the logon prompt makes the power configuration from the .DEFAULT profile the active power profile. User X logs on to the same computer. The active power profile is now read from user X’s user profile. User X logs off the computer. User X’s power profile remains the active power profile for the computer. Windows XP does not make the .DEFAULT power profile the active power profile. User Y logs on the computer. User Y’s power settings now become the active power profile. User Y’s power settings remain the active power profile after they log off the computer. We restart the computer and, once again, the active power profile is read from .DEFAULT.



Group Policy Preferences Power Options

Understanding how Windows XP manages the active power profile helps us better understand how Group Policy Power Option preference items manipulate Windows XP’s active power profile. Let’s start with computer startup. We’ve established that Windows XP reads power settings from the .DEFAULT profile into the active power profile. A Power Option preference item applying to a Windows XP computer does two things: it changes the power settings in the .DEFAULT profile and it makes those new settings the active power profile. A Power Option preference item applying to a user does two things: It changes the power settings in that user’s profile and it makes those new settings the active power profile. Remember there is only one active power profile—it’s the profile that was last made active.




So predicting GPP Power Option precedence is trivial for computer startup and user logon. But background refresh can introduce some confusion. The computer starts up and receives GPP Power Item A. GPP Power Item A becomes the active power profile. User X logs on and receives GPP Power Item B. The active power scheme changes from A to B. Now, let’s presume that User X is a local administrator. This means User X can change the power settings, which changes the active power settings. So, User X changes the active power profile to power settings C. Now, a Group Policy background refresh occurs.

The background refresh changes the active power profile. And, as we previously covered, the last applied GPP Power item is the active power profile. When we last left our example computer, the active power profile was power settings C, which were created when the user changed their settings using the user interface. If the computer receives GPP Power Item A, and the user receives GPP Power Item B, then what is the resulting power profile? Power item B becomes the active power profile because it is the last power profile that is made active.

Let’s change the scenario. Let’s deploy GPP Power Item A to the computer and not deploy anything to the user because we want to apply a single power profile that affects all the users of the computer. Makes sense right? No, not in this case. The computer starts up and applies GPP Power Item A to .DEFAULT and makes GPP Power Item A the active power profile. User X logs on, and does not have a GPP Power item applied. The user loads their power profile from their user profile, and it becomes the active power profile. The power profile does not change until the user changes it (the need to be a local administrator) or during Group Policy refresh when the computer reapplies the GPP Power item; thus becoming the active power profile. You need combine Group Policy loopback processing (in replace mode) with GPP Power items to create one single GPP Power item that applies to all users of a computer.


I could easily add another five pages to cover all the different combinations of GPP Power items between computer and user settings. However, the main important thing to remember is there is only one active power profile for the entire computer running Windows XP. And, the active power profile is the power profile that was made active on the computer, regardless if it was done in the context of the user or computer.

— Mike Stephens

Control Extended Protection for Authentication using Security Policy

Microsoft has introduced additional security measures for authentication known as Extended Protection for Authentication, also known as channel binding token (CBT). Extended protection can cause a variety of interoperability issues including but not limited to:

  • Windows clients that support channel binding fail to be authenticated by a non-Windows Kerberos server
  • NTLM authentication failures from Proxy servers
  • NTLM authentication failures from non-Windows NTLM servers
  • NTLM authentication failures when there is a time difference between the client and DC or workgroup server

Note: Read more about Extended Protection for Authentication in Microsoft Knowledge base article 968389 and MSDN.

Administrators may want to control the state of Extended Protection to multiple client computers. This can be accomplished using security policy. Security policy is the most appropriate solution to distribute the registry setting that controls Extended Protection for Authentication because the setting is stored under the LSA key in HKEY_LOCAL_MACHINE. Also, distributing the setting using security policy increases the chance of the desired settings winning all conflicts because, by default, security settings always apply during Group Policy Processing. Once the policy is applied, any user or application that changes the registry location will be reverted back to the desired configuration during the next application of security policy.

Add the policy setting to Security Policy settings

The Extended Protection for Authentication policy setting must be added to Security Policy editor to include the policy setting in Group Policy. To accomplish this:

==== Start copy after this line ====

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SeCEdit\Reg Values\MACHINE/System/CurrentControlSet/Control/Lsa/SuppressExtendedProtection] 
“DisplayName”=”Network Security: Extended Protection for Authentication” 

==== Stop copy before this line ====
  1. Copy the above text.
  2. Open Notepad and paste the text from step one into Notepad.
  3. Click File and then Click Save As.
  4. In the File name box, type secpoladd.reg.
  5. In the Save as type list, click All Files. Remember the path to which the file is saved.
  6. Click Save and close Notepad.
  7. Locate the saved file from the path in step
  8. Double-click the secpoladd.reg file. Click Yes to the Registry Editor dialog box.

It is only required to modify the security editor on the computer used to manage Group Policy. This allows the Extended Protection for Authentication policy setting to be included in a Group Policy object. Extending this security setting to other computers is not required for client computers to receive the security setting.

Include the Extended Protection for Authentication policy setting in Group Policy


With the security editor extended, you can now include the security setting within a Group Policy object. To do this:

  1. Using GPMC, edit the Group Policy object that is to contain the security setting.
  2. Navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.
  3. In the right pane of the MMC, scroll through the list of security settings to locate Network Security: Extended Protection for Authentication. Double-click the security setting.
  4. Select Define this policy setting. Choose the desired configuration from the list and click OK.
  5. Close the Group Policy object.
  6. The Group Policy object now contains the security policy setting. Use GPMC to deploy the GPO to clients as needed.


Improving security always poses a risk with application compatibility. The long term solution is to determine why applications no longer work when security in heightened. A short-term solution during the investigation may be to reduce security to allow the application to work, pending the results of the investigation. Controlling this using Group Policy helps manage the setting for the enterprise.

— Mike Stephens

Windows 7, Windows Server 2008 R2 and the Group Policy Central Store

Today, I want to bring clarity to something we are seeing with Windows Server 2008 R2 and existing Group Policy central store. Before that discussion, let us cover some background information.

ADMX Files and the Group Policy Central Store

Microsoft introduced the ADMX file format with Windows Vista and Windows Server 2008. This XML-based file format replaced the token-based ADM file format used by earlier versions of Windows to define administrative templates. Group Policy uses administrative templates to represent registry-based policy settings that appear when editing Group Policy. The content included in administrative templates describes the user interface used by Group Policy editors and registry locations where Windows stores policy settings. Windows Server 2008 R2 and Windows 7 provide a new set of administrative template files in the ADMX format.

Windows 7 ADMX files now include support for two registry types: REG_MULTI_SZ and REG_QWORD. The REG_MULTI_SZ registry data type represents multi strings entries within a single registry value. The REG_QWORD registry data type represents a 64-bit number, which is twice the size of the 32-bit number stored in REG_DWORD. These new aspects of the ADMX syntax are only viewable when using the GPMC and Group Policy editors from Windows Server 2008 R2 or Windows 7 Remote Server Administration Tools (RSAT). Group Policy editors and the GPMC from Windows Vista cannot read ADMX files containing this new syntax.

The Central Store

Earlier versions of Group Policy that used ADM files suffered from a symptom known as SYSVOL bloat. These versions of Windows copied the set of ADM files into each Group Policy object stored on SYSVOL. Each set of ADM files required approximately 4MB of disk space. A domain can realistically have 100 Group Policy objects. One hundred Group Policy objects multiplied by 4 megabytes of disk space equates to 400MB of redundant data—what a waste. Windows Server 2008 and Vista introduced the concept of the Group Policy Central Store to overcome SYSVOL bloat. The Group Policy Central Store is a single folder on each domain controllers SYSVOL that stores one set of ADMX files for the entire domain. The central store effectively relieves the symptoms of SYSVOL bloat and reduces the amount of data transferred during SYSVOL replication when new Group Policy objects are created. Some documentation refers to the Group Policy Central Store as an alternate location to store ADMX files (the other location is the local store found in %SYSTEMROOT%\PolicyDefinitions). A more accurate description of the Central Store is the preferred location.

So what’s the Problem?

The Group Policy Management Console and the Group Policy Management Editor always use the Group Policy Central store, when it is present. The pro here is that all instances of the GPMC and GPME use the same set of ADMX files. The con is that servicing ADMX files is difficult. Also, GPMC cannot use the local store as long as a Group Policy Central Store exists. So adding a single ADMX set for a single computer is not possible when using a central store. So, when we released Windows 7 and Windows Server 2008 R2, we also released a new set of ADMX files (within the operating system). These new ADMX files expose new Windows 7 and Windows 2008 R2 policy settings as well as policy settings for previous operating systems. Therefore, you need these files to configure Windows 7 Group Policies. Here’s where the dilemma continues.

A Central Store and Windows 7

If you have a central store (presumably hosted with Windows Server 2008 ADMX files), then you have two choices: upgrade the ADMX files or remove the central store.

Updating the Central Store

Updating the Central Store affects all users in the domain that use GPMC and its editor. It is important to understand this because newer ADMX files may not be compatible with older versions of Group Policy Tools, as in the case with Windows Server 2008 R2. The screen capture below occurs in Windows Vista and Windows Server 2008 computers attempting to read a Group Policy Central store hosted with Windows Server 2008 R2 ADMX files.



Windows Server 2008 R2 ADMX file, in this example the TerminalServer-Server.adml, contains an unknown element named <multiTextBox>. This element represents the REG_MULTI_SZ implementation that is new with Windows 7 and Windows Server 2008 R2. Newer ADMX files can contain new features, which older Group Policy Tools may not understand. This is why it is always a best practice to use the latest Group Policy Tools to manage Group Policy. Backwards compatibility is an important aspect of Group Policy; however, forward compatibility is not.

Also, you may be using Windows 7, but do not see Windows 7 policy settings. Remember, GPMC prefers the Group Policy Central Store over the local store. The Windows 7 GPMC (actually RSAT) uses the Group Policy Central Store (hosted with Windows Vista or Windows Server 2008 ADMX files) over its local store that hosts the Windows 7 ADMX. If you want to see Windows 7 policy settings, then you’ll need to upgrade your central store or remove it.

I have successfully used Windows Vista RSAT with an upgraded Group Policy Central Store. However, the ADMX and ADML files were from a Windows 7 computer. Using Windows Server 2008 R2 ADMX files produces the error in the preceding image using GPMC from Windows Server 2008 or Windows Vista RSAT.



Removing the Group Policy Central Store

Removing the Central Store targets all Group Policy tools to use their local store for ADMX file. This allows Windows 7 RSAT and Windows Server 2008 R2 computer to use their ADMX files. Windows Vista RSAT and Windows Server 2008 use their local ADMX files. Windows Vista computers cannot manage or report on Windows 7 policy settings.

An Alternative to the Central Store

There is way for us to “have our cake and eat it too”. The answer is Terminal Services. I often suggest to customers that have many people managing Group Policy to setup a GPMC Terminal Server. Dedicating a single server as the means to manage Group Policy provides:

  • The concept of a central store
  • A single point of Group Policy management
  • Easy to audit and maintain

A dedicate Group Policy Terminal Server can provide the look and feel of a Group Policy Central Store without implementing a Central Store. ADMX files are located in one location, the terminal server. GPMC does not load the ADMX files from a network location. Domain controllers do not need to replicate the additional content of a Central Store—all the benefits of a Central Store, without creating one.

Group Policy is a critical part of the enterprise and yet it seems little is done to reduce its exposure. A dedicated Terminal Server running GPMC provide a true single point of management for the entire Group Policy experience. Terminal Services security can be implemented to reduce the number of people having access to GPMC. Auditing interactive logons can further assist with identifying changes made to Group Policy. Combine this with using Group Policy to prevent other computers from opening GPMC and you’ve effectively lowered the surface and exposure to Group Policy to only the people that actually need it.

Hopefully, this helps with understanding the pros and cons of using a Group Policy Central Store. Also, it should help with answer some of the common questions that arise regarding updating the central store or managing the latest Group Policy settings with Windows 7. And lastly, perhaps consolidating Group Policy Management to a Terminal Server will help limit access to Group Policy management to only the people that actually need it.

— Mike Stephens