Tag Archives: AskDS

Blog posts formerly from AskDS Directory Services blog

Removable Storage, Group Policy and Windows Server 2008 and Windows Vista

Posted on by
Reply

“I don’t want my users copying data to removable drives. How can I prevent this?”

Today I want to answer this common question asked to our team. Removable drives are widespread. Current mobile devices can now store up to 8 GB of data on a micro-SD card, which is no bigger than your thumb nail. Eight gigabytes is a huge amount of data and it could be your company’s Intellectual Property (IP) going out the door. There is a need to protect your company’s sensitive information from being transferred to removable storage devices; Group Policy in Windows Server 2008 and Windows Vista can help you.

You can control access to six removable storage categories (actually seven but the seventh category controls access to ALL removable storage devices). These categories include CD and DVD, Floppy Drives, Removable Disks, Tape Drives, and WPD devices.00-storageToday’s computers usually do not included a floppy drives because the amount of data that fits on a floppy disk seems trivial in the age of one terabyte drives—regardless, you can restrict access to floppy drives, which includes USB floppy drives. Removable drives included classic USB thumb drives. WPD devices include media players, cell phones, CE devices, and some auxiliary displays. There is a custom category that allows you to identify the unique identifier of a device and control access of that device based on the unique ID.

Each device category provides two types of access control—deny read and deny write. These policy settings apply to Windows Vista or later (to included Windows Server 2008) and can co-exist in GPOs applying to clients earlier than Windows Vista; however these older operating systems ignore the policy settings.

You can find these policies under the Removable Storage Access category, under User or Computer Configuration\Policies\System\Removable Storage Access

These policy settings change the security descriptor on the removable objects. Changing the security descriptor requires a computer reboot. Window’s does not reboot the computer when the policy changes these security descriptors. However, Removable Storage provides a policy setting to which you can enable to force a reboot. Enable the Time (in seconds) to force reboot policy setting and provided value (in seconds) for which Windows waits before rebooting the computer to apply the new security descriptors for removal drives.01-storageSo, keep your Intellectual Property secure by controlling access to removable storage devices. Delegate write permissions to a limited user set, or limit removable storage write access to a single workstation. You can do your part to keep your company’s sensitive data where it belongs.

– Mike Stephens

Event Logging policy settings in Windows Server 2008 and Vista

Posted on by
Reply

Today I’m focusing on policy settings for the Event Logging Service.

For clarity, these settings control the Event Logging service; the service responsible for capturing and writing events throughout Windows. These policy settings do not affect the Event Viewer application.

These are some powerful policy settings that allow you to configure five settings for Application, Security, Setup, and System event logs. These categories and their policy settings are located under Computer Configuration\Policies\Administrative Templates\Windows Components\Event Log Service.

The Log File Path policy setting, when enabled, allows you to provide a specific location where the Event Log service writes its log file. You must provided path and filename when relocating where Windows writes the log file.

Next is the Maximum Log file size policy. When enabled, this policy allows you to specify the maximum size of the event log. It supports sizes between one megabyte and two terabytes and uses one-kilobyte increments.00-eventLogThe next two policy settings are related. The Event Logging service uses the Retain old events and Backup log automatically when fullpolicy settings when the event log reaches the maximum file size (defaults to 20 MB or the value specified in the Maximum Log size policy setting). With the Retain Old Events policy setting enabled, the Event Logging service stops writing new events to the event log when the log file reaches or exceeds the maximum value and you lose all new events. With this policy setting disabled, new events overwrite old events. When you enabling the Backup log automatically when full and the Retain old events policy settings, the Event Log service closes the current event log, renames it, and then creates a new log. The Backup log automatically when full policy setting works only when you enable Retain old events policy setting.01-eventLogThe last setting and one that I think is the most beneficial is the Log Access setting. Enabling this setting allows you to enter a security descriptor for the log file. The security descriptor controls who can read, write, or clear the event log. You enter the security descriptor using Security Definition Description Language (SDDL), which is document on MSDN(http://msdn.microsoft.com/library/en-us/secauthz/security/security_descriptor_string_format.asp). Also, my esteemed colleague Jim provides a two-part blog series about SDDL (http://blogs.technet.com/askds/archive/2008/04/18/the-security-descriptor-definition-language-of-love-part-1.aspx and http://blogs.technet.com/askds/archive/2008/05/07/the-security-descriptor-definition-language-of-love-part-2.aspx).

Finally, I should mention that these new policy settings have precedence over the older Windows Server 2003 and Windows XP security policy setting that manage Event Logs. Both settings can exist in the same Group Policy object and apply only to the respective operating systems for the policy setting.02-eventLogThese new policy settings for the Event Logging service provide more flexibility and control from earlier versions. Using Group Policy to control where event logs are written, how large they can grow, how they are preserved, and who can manage them are key to change control and security auditing. You can implement these policy settings in your existing Group Policy objects and they will not affect operating systems earlier than Windows Vista.
– Mike Stephens

Enabling Group Policy Preferences Debug Logging using the RSAT

Posted on by
Reply

Sometimes you need to enable additional logging when you are troubleshooting a particular component in Windows. Group Policy Preferences includes the ability to create verbose debug logging for each included client-side extensions. You activate Preference debug logging through Group Policy. Preference debug logging policy settings are located under the Computer Configuration\Policies\Administrative Templates\System\Group Policy node when editing a Group Policy object.00-gpp-debugYou can individually enable each preference client-side extension. Logging and tracing entries provide you with a several configuration options including what type of data to write to the event logs (Informational, Errors, Warnings, or all), enable trace logging and the location of the trace log file, and the size of the file.01-gpp-debugYou can configure the location of the trace files; however, keep in mind that file system permissions changed on Server 2008 and Windows Vista. Make sure permissions do not interfere with creating the log file. You’ll notice the default location for all three log files is
%COMMONAPPDATA%\GroupPolicy\Preference\Trace. The variable
%COMMONAPPDATA% is not recognized by Windows, however; it is meaningful to Preference client-side extensions. Preference client-side extensions recognize this variable and expand it according to operating system on which the client-side extension is installed. For Windows Server 2003 and Windows XP, %COMMONAPPDATA% expands to
%SYSTEMDRIVE%\Documents and Settings\All Users\Application Data. The equivalent path for Windows Server 2008 and Windows Vista is %SYSTEMDRIVE%\ProgramData (this folder is hidden by default, but you can manually type the path in Windows Explorer).

Logging and tracing missing from RSAT

You’ve installed Windows Vista Service Pack 1; you’ve downloaded and installed RSAT. You try to enable Logging and tracing, but it’s not there. Well, there is a reason for this.02-gpp-debugAdministrative Templates show in the user interface because of two files: an .ADMX and an .ADML. Logging and tracing does not appear because the GroupPolicyPreferences.admx and .adml files are not included with RSAT. You need to copy these to your local or central store.

You have two options as to how to get a copy of the Group Policy Preferences ADMX files. You can download the entire Windows Server 2008 ADMX file set, or you can download just the Group Policy Preferences ADMX file set. You can download the installer for either of these file sets from http://www.microsoft.com/downloads/details.aspx?FamilyID=927fc7e3-853c-410a-acb5-9062c76142fa&DisplayLang=en. These MSI applications install their contents to the default location of %PROGRAMFILES%\Microsoft Group Policy.

The Group Policy Preferences ADMX installation creates an additional folder named Preferences, which contains a single ADMX file with multiple locale folders. You want to copy the GroupPolicyPreferences.admx file into your policydefinition folder. If you are using a central store, then you must copy the file to the policydefinition folder on SYSVOL, otherwise; copy the file to your local store. You’ll then want to copy the .ADML file to the corresponding locale folder located in your policydefinition folder. See the Managing Group Policy ADMX Files Step-by-step guide for more information on managing ADMX Files and creating a central store. After you’ve copied both the .ADMX and .ADML file into the proper store, then close all instances of GPMC and its editor. Restart GPMC and edit the GPO in which you want to add Logging and tracing policy settings. Expand the nodes under Computer Configuration and you should now see Logging and Tracing options.

– Mike Stephens

Installing GPMC on Windows Server 2008 and Windows Vista Service Pack 1

Posted on by
Reply

For some time now, we’ve had inquiries about where the Group Policy Management Console (GPMC) is located in Windows Server 2008 or Windows Vista SP1. It’s well documented that Server 2008 includes GPMC but, it does not appear in the administrative tools.

The Group Policy Management Console is included in Windows Server 2008; however, you must install it before you can use it. The domain controller promotion process installs GPMC on the server, in addition to adding the domain controller to the domain. Additionally, you can install GPMC on a member server as long as it’s a member of the domain. Let’s look at two ways to install GPMC on Windows Server 2008 (other than through DCPROMO).

Installing GPMC using Server Manager (Windows Server 2008)

The Group Policy Management Console is a Feature in Windows Server 2008. You install Features using Server Manager. Once installed, you can access the feature using Server Manager or you can the specific management console (like gpmc.msc).

  1. Open Server Manager by click Start and then point to Administrative Tools. Click Server Manager
  2. Click Features in the console tree. In the Features pane, click Add Features
  3. Select Group Policy Management from the list of available features in the Add Feature Wizard. Click Install.
  4. Start using GPMC or close Server Manager.

There’s another way to install GPMC using Server Manager, which usually installs quicker that using the Server Manager user interface. Server Manager includes a command line utility for installing Features and Roles named ServerManagercmd.exe.

Installing GPMC from the Command Line

  1. Open an elevated command prompt.
  2. In the command prompt, type ServerManagercmd –install gpmc
  3. Start GPMC from the command prompt by typing start gpmc.msc
  4. Close the command prompt.

Installing GPMC on Windows Vista Service Pack 1

Installing GPMC on Windows Vista Service Pack 1 can be a little confusing. First, you must download the Remote Server Administration Tools for Windows Vista Service Pack 1 before you can install GPMC. You may remember that GPMC was included in Windows Vista RTM; however Service Pack 1 removes it. After installing RSAT, you then want to install GPMC. Installing RSAT simply includes the Remote Server Administration tools on the Windows Vista SP1 computer but does not deploy for use—you’ll want to choose which RSAT tools you want used on the computer.

  1. Download and install the Remote Server Administration Tools (http://go.microsoft.com/fwlink.?LinkID=95703).
  2. After the installation is complete, then click Start, click Control Panel, and then click Programs.
  3. Click Turn Windows Features on or off from Programs and Features.
  4. Click Remote Server Administration Tools and then click Feature Administration Tools from the Windows Features dialog box.
  5. Click Group Policy Management Tools and click OK to complete the installation.

You’ll now see Group Policy Management included under the list of Administrative Tools (On Vista, you may need to actually show the Administrative Tools on the start menu – this can be done through Control Panel –> Taskbar and Start Menu –> Start Menu –> Customize–> System Administrative Tools). You can also start GPMC from the command line or run/search menu by typing gpmc.msc.

– Mike Stephens

User Profile Policies in Windows Server 2008 and Windows Vista

Posted on by
Reply

Windows Vista made numerous changes with how user profiles work. In fact, the changes are too numerous to describe here (you can read more about the changes with user profiles in the Managing Roaming User Data Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=73435). However, the policy settings for user profiles from earlier versions of Windows remain and Windows Vista introduces five new policy settings.

Four of the five new policy settings for user profiles exist under Computer ConfigurationAdministrative TemplatesSystemUser Profiles (the remaining policy setting uses the same path under User Configuration). These five policy settings apply only to computers running Windows Server 2008 or Windows Vista, however; these policy settings can co-exist in GPO’s applicable to clients earlier than Windows Vista. Operating systems other than Windows Vista ignore the policy settings. Let me begin with the policy settings under the computer configuration and then close with the single user setting.

The first of these policy settings is Delete user profiles older that a specified number of days on system restart. This policy setting accepts a numeric value, represented in number of days. Windows uses this value to determine the how long it retains dormant user profiles. When you enable this policy, Windows deletes all user profiles older than the value provided. This policy setting measures one day as 24 hours since the last time Windows loaded the profile.

NOTE: Microsoft released a hotfix to correct problems specific to this policy setting. You can view more about the issue and related fix from Microsoft Knowledgebase article 945122 (http://support.microsoft.com/?kbid=945122).

Sometimes, in earlier versions of Windows, the registry portion of the user profile fails to unload. Many times this failure prevents the user from subsequent logons to the same computer. Windows Server 2008 and Windows Vista always unload the registry portion of the user profile, even if it must forcefully do so. The policy setting Do not forcefully unload the user registry at user logoff counters the default behavior of Windows Vista. When enabled, Windows Vista does not forcefully unload the registry and waits until no other processes are using the user registry before it unloads it.

The policy setting Set roaming user profile path for all users logging onto this computer provides you a way to create a shared user profile path for a specific computer. When you enable this policy, all users use the profile path specific in the policy when logging onto a computer receiving the policy. There is a small catch-there is an order of precedence. Windows reads profile configurations in the following order and uses the first configured setting.

  1. Terminal Services roaming profile path specified in the Terminal Services policy setting.
  2. Terminal Services roaming profile path specific in the user object.
  3. Per-computer roaming profile path specified in the above described policy setting.
  4. Per-user roaming profile path specified in the user object.

For example, if you configure the Terminal Services roaming profile path using the Terminal Services policy settings and, you also configure the per-computer roaming user profile policy setting, then Windows uses the roaming profile path from the Terminal Services policy. This result is due to the order in which Windows reads the roaming user profile path.

The last policy setting for user profiles under the Computer configuration is the Set maximum wait time for the network if a user has a roaming user profile or remote home folder. At logon, Windows Vista typically waits 30 seconds for an active network connection, when you configure the user with a roaming user profile or remote home directory. In cases such as wireless, VPN, or NAP-protected networks, it may take more time before the network connection becomes active. When enabled, Windows waits up to the number of seconds specified in the policy setting for an active network connection. Windows immediately proceeds with logging on the user as soon as the network connection is active or the wait time exceeds the value specified in the policy setting. Windows does not synchronize roaming user profile or use the remote home folder if the logon occurred before the network connection became active.

One policy setting for user profile exists under the User Configuration category. Actually, it is more of an Offline Files/ Folder Redirection policy setting. Windows Vista automatically marks all redirected folders as available offline. Windows Vista keeps track of all folders marked offline and synchronizes the contents of these folders between the local computer and the network location where you store the files. This synchronization process occurs at logon, periodically throughout the user session, and at logoff. You configure the policy setting by entering network paths that you only want synchronized during logon and logoff. Windows then places these specified network paths offline during the user session.

Windows Server 2008 and Windows Vista Service Pack 1 provide several new Group Policy settings that affect User Profiles. Many of these new policies settings help overcome profile limitations with earlier versions of the operating system. Be sure to evaluate these settings to see how can help with your environment.

– Mike Stephens

Bulk exporting and importing WMI filters for Group Policy

Posted on by
Reply

Here is an updated version of the blog post which was originally published on the Group Policy blog. Check it out!

Did you know you can import/export WMI filters using GPMC? However, your export is limited to one filter at a time – filter to a single .mof file. You then take the exported .mof file to a different domain and use GPMC to import each file. This is great when you only have one or two WMI filters. What about if you have 15 or 20? No worries! You can do this using the LDIFDE utility. (This is a long but detailed explanation).

First, you need to find the WMI Filter you want to export (and eventually import). GPMC writes WMI filters in the Domain partition at:

CN=SOM,CN=WMIPolicy,CN=System,DC=contoso,DC=com.

The LDAP filter you use to return all WMI filters is (objectclass=msWMI-Som). You can narrow the number of returned items if you know the name of the WMI Filter by using
(&(objectclass=msWMI-Som)(msWMI-Name=filtername)). You can lean more about LDAP search filter syntax from MSDN (http://msdn2.microsoft.com/en-us/library/aa746475.aspx). The following sample command line gives you and idea of how to export the WMI Filter:

LDIFDE -f output.txt –d “dc=contoso.com” –r ”( objectclass=msWMI-Som)” –p subtree

In the example above, -f designates the name of the output file that stores the exported WIM filter objects. Next, -d designates the based distinguished name; that is, where the search for objects starts. In this example, it starts at the beginning of the domain. The –r is an inclusive LDAP search filter. In this example we only want objects of the class
msWMI-Som returned by the query. Lastly, the –p designates that type of search we want to use. A subtree search means the search begins at the designated base distinguished name and searches the entire depth of the tree for objects matching the designated filter—similar to using dir /s on a directory when searching for a file.

Your options may vary. If you have problems exporting the items then add –j . (one dash, the letter J, a space, and one period) to the command line to create a log file in the current folder. A successful output.txt file looks similar to the following:

dn: CN={1154EFFC-0090-4F23-8865-C8D555BF696E},CN=SOM,CN=WMIPolicy,CN=System,DC=contoso,DC=com
changetype: add
objectClass: top
objectClass: msWMI-Som
cn: {1154EFFC-0090-4F23-8865-C8D555BF696E}
distinguishedName:
CN={1154EFFC-0090-4F23-8865-C8D555BF696E},CN=SOM,CN=WMIPolicy,CN=System,DC=con
toso,DC=com
instanceType: 4
whenCreated: 20070808151246.0Z
whenChanged: 20070808151246.0Z
uSNCreated: 40979
uSNChanged: 40979
showInAdvancedViewOnly: TRUE
name: {1154EFFC-0090-4F23-8865-C8D555BF696E}
objectGUID:: EPDEbOIaGEWyX3Z/b+eiKw==
objectCategory: CN=ms-WMI-Som,CN=Schema,CN=Configuration,DC=contoso,DC=com
msWMI-Author: Administrator@CONTOSO.COM
msWMI-ChangeDate: 20070618142622.740000-000
msWMI-CreationDate: 20070618142257.735000-000
msWMI-ID: {1154EFFC-0090-4F23-8865-C8D555BF696E}
msWMI-Name: Imported WMIFilter2
msWMI-Parm1: This is the description for the filter
msWMI-Parm2:
1;3;10;45;WQL;root\CIMv2;Select * from win32_timezone where bias =-300;

Once you successfully export the WMI Filters; you then need to prepare the output file for import.

Prepare the output file for importing:

  1. First, save the file as another file name.
  2. Then, you need to download the GUIDGEN utility (this is not so important when importing the WMI filter into a different domain). As a reference, this is a guid: {DF380E6C-DB23-44ed-9BF6-435559503347}.
    • You MUST change the guids to import into the same domain or it will NOT import.
  1. Change the guid (to include open and closing curly braces) in the DN, CN, distinguishedname, name, and msWMI-ID attributes (use the same guid in each of these attributes).
  2. If importing into a different domain, change the LDAP path to reflect the new domain in the dn, distinguishedName, and objectCategory attributes. Only change the domain portion of the LDAP path.
  3. Next, you need to remark out the whenCreated, whenChanged, USNcreated, USNChanged, objectguid, msWMI-ChangeDate,  and msWMI-CreationDate attributes. Do this by inserting the # character and a space at the beginning of the line for each of the listed attributes.
  4. Optionally, you can change the text displayed in msWMI-Name, msWMI-Author, and msWMI-Parm1 attributes.
    • msWMI-Name is the display name of the WMI Filter shown in GPMC.
    • msWMI-Author is the UPN format for the person creating the WMI filter.
    • msWMI-Parm1 is the description text shown for the WMI filter in GPMC.

The final file should look similar to the following.

dn: CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
changetype: add
objectClass: top
objectClass: msWMI-Som
cn: {4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
distinguishedName:
CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
instanceType: 4

whenCreated: 20070618142257.0Z

whenChanged: 20070618142622.0Z

uSNCreated: 26483

uSNChanged: 26485

showInAdvancedViewOnly: TRUE
name: {4464D2C2-9063-4953-AE6F-A0D231EBF3CD}

objectGUID:: 7sA6lK0PVE2fGNOSDTS5Kw==

objectCategory: CN=ms-WMI-Som,CN=Schema,CN=Configuration,DC=fabrikam,DC=com
msWMI-Author: Administrator@fabrikam.COM

msWMI-ChangeDate: 20070618142622.740000-000

msWMI-CreationDate: 20070618142257.735000-000

msWMI-ID: {4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
msWMI-Name: Imported WMIFilter2
msWMI-Parm1: This is the description for the filter
msWMI-Parm2:
1;3;10;45;WQL;root\CIMv2;Select * from win32_timezone where bias =-300;

You’re almost ready to import the WMI filters. However, importing or adding a WMI Filter object into AD is a system only operation. You need to enable system only changes on a domain controller for a successful LDIFDE import. To do this, on the domain controller you are using for importing, open the registry editor and create the following registry value.

Key: HKLM\System\CurrentControlSet\Services\NTDS\Parameters
Value Name: Allow System Only Change
Value Type: REG_DWORD
Value Data: 1 (Binary)

Next, you’ll need to reboot the domain controller to activate the new setting. Once the domain controller is rebooted, you can use LDIFDE to import the file into AD. Use the following command:

LDIFDE  -i –f input.txt

If you have problems then add –j . (one dash, the letter J, a space, and one period) to the command line to create a log file in the local folder. Once the import is complete you should delete the System Only Registry key and reboot the domain controller to deactivate the setting. A successful import looks similar to the following.

Connecting to “hq-con-dc-01.fabrikam.com”
Logging in as current user using SSPI
Importing directory from file “import-wmi.ldf”

Loading entries
1: CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
Entry DN: CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
changetype: add
Attribute 0) objectClass:top msWMI-Som
Attribute 1) cn:{4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
Attribute 2) distinguishedName:CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
Attribute 3) instanceType:4
Attribute 4) showInAdvancedViewOnly:TRUE
Attribute 5) name:{4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
Attribute 6) objectCategory:CN=ms-WMI-Som,CN=Schema,CN=Configuration,DC=fabrikam,DC=com
Attribute 7) msWMI-Author:Administrator@FABRIKAM.COM
Attribute 8) msWMI-ID:{4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
Attribute 9) msWMI-Name:Imported WMIFilter2
Attribute 10) msWMI-Parm1:This is the description for the filter
Attribute 11) msWMI-Parm2:1;3;10;45;WQL;root\CIMv2;Select * from win32_timezone where bias =-300;

Entry modified successfully.

1 entry modified successfully.

The command has completed successfully

And there you go: you’ve successfully exported and imported WMI filters.

-Mike Stephens

Managing Power with Group Policy: Part 3 of 3

Posted on by
Reply

It’s time we wrap up our discussion on managing power using Group Policy. The previous blog posts discussed managing power on Windows Vista (and Windows Server 2008). Today, I’ll cover how we can achieve the equivalent for Windows XP.

The key to managing power on Windows XP is Group Policy preferences. The Group Policy Management Console (GPMC) included with Windows Server 2008 and (soon to be released) Remote Server Administration Tools contains the management portion of portion of preferences. Next, you need preference client side extensions that allow Windows XP to process Group Policy objects that contain preference configuration data. Group Policy preferences client side extensions are available from Microsoft for Windows Vista, Windows Server 2003, and Windows XP.

Preferences provide two preference items you can use to configure power on Windows XP (or Windows Server 2003 and Windows Server 2003 R2). The first of these items is the Power Option item. Figure 1 shows you the properties on a Power Option preference item. This is one of the great features with preferences—the configuration screen closely resembles the screen you actually use on the operating system.00-manage-power-p3The Power Option preference item gives you the ability to configure hibernation, prompting for password when the computer resumes. Also, you can configure the Power button action when you close the lid of the computer (laptop), press the power button, or press the sleep button.

One of the cool things about preferences is you have control over which settings you want to configure and ones that you do not. Figure 1 shows each setting in the preference item underlined with a single green line. This means the setting in the item is enabled and the setting applies as configured. Using Figure 1 as an example, the Always show icon on the taskbar is enabled but, the checkbox is not selected. During Group Policy processing, this preference item configures Always show icon on the taskbar, Prompt for password when computer resumes from standby, and Enable Hibernate as off. This result is because the setting in the item was enabled (green underline) and the checkbox is cleared (off). This is a very powerful feature because it allows you full control over the setting you want to configure and the setting that you do not. Let’s look at another example.01-manage-power-p3The above image shows another configured Power Options preference item. In this example, Always show icon on the taskbar has a red dashed underline, which means the setting is disabled. This means when Group Policy applies this preference item, Prompt for password when computer resumes from standby and Enable hibernation are enabled and, Always show icon on the taskbar is ignored. You enable and disable a setting by using the function keys on the keyboard.

  • F5 enables all the settings in a preference item
  • F6 enables the currently selected setting in a preference item
  • F7 disables the currently selected setting in a preference item
  • F8 disables all the setting in a preference item

NOTE:
Preference items are not policy settings, which means they are not enforced—just applied. Users with the proper privileges may have the ability to change the preference setting to another selection. However, preference item settings return on the next Group Policy refresh, unless configured otherwise.

The other power preference item is Power Scheme. The Power Scheme preference item allows you to create, modify, and delete power schemes. This allows you to configure a Windows XP computer to use one of the pre-existing power schemes or modify the settings included in one of the pre-existing power schemes or, just you create your own—it is your choice. Each power scheme has settings for two options: Plugged in or Running on batteries. From there, you define the time out settings for turning off monitors, hard disks, system standby and system hibernate. The Power Scheme preference item has the same enable/disable feature as the Power Option preference item and behaves in the same fashion.

The one difference with the Power Schemes preference item is the Action field. The action field determines the action Group Policy processing applies to the specific preference item. Configuring a Power Scheme preference item to Create; does just that—it creates a new power scheme. However, if, on the computer applying the preference item, a power scheme with the same name exists, the preference item does nothing. Delete and Update do just what they describe—delete and update. However, Update does provide additional functionality other than updating an existing power scheme with new settings. If you configure your Power Scheme preference item to update a power scheme that does not exist on the applying computer, then a new power scheme is created with that name. Lastly, configuring the preference item with Replace has similar results to using Update. When using Update, the Power Scheme preference item only updates the enabled settings within the preference item on the existing named power scheme—leaving all other settings as they are. Replace, however; actually deletes the named power scheme from the computer and then creates a new power scheme based on the settings configured in the Power Scheme preference item.

Other things to remember with power management preference items:

  • You can configure power management preference items in both computer and user configurations. Understand, user configuration apply after computer configuration. This results in the user settings replacing the current power settings, which could have been from another preference item.
  • Local Administrators are Administrators. This means they can change their power configuration. Standard users cannot.
  • When Group Policy applies power management preference items; those items become the current power management scheme—even after the user logs off.
  • Power management preferences item support background refresh—your settings can change.

That wraps up Managing Power with Group Policy. Three blog entries, six categories, 34 policy settings, and two preference items later, it should be easy to see how combining these Group Policy features could save your company significant resources. It may be a good time to review how you could implement some of these features and savings you may gain.

Managing Power with Group Policy: Part 1 of 3
Managing Power with Group Policy: Part 2 of 3
Managing Power with Group Policy: Part 3 of 3

-Mike Stephens

Managing Power with Group Policy: Part 2 of 3

Posted on by
Reply

Last time, I introduce new Power Management policy settings included in Windows Vista. In the first of a three parts, I wrote about Button, Hard Disk, and Notification policy settings. Today, I continue to review Power Management by writing about Sleep and Video and Display power management policy settings.

As a reminder, these categories and their policy settings are located under Computer Configuration\Policies\Administrative Templates\System\Power Management. These policy settings are Windows Vista policy settings and apply only to computers running Windows Vista. Also, these policy settings can co-exist in policies applicable to clients earlier than Windows Vista. Operating systems other than Windows Vista will ignore the settings.00-manage-power-p2I’ll start with the Sleep power management category and its policy settings. As I wrote in part one, Windows divides most Power Management policy settings into Plugged In or On Battery policy settings (Plugged In or On Battery actually appears in the name of the policy setting). This gives the category 12 policy settings total; 6 for Plugged In and 6 for On Battery. These policy provide the means to adjust how Windows Vista behaves prior to entering, during, and waking from sleep mode. I’ll begin by providing the name of each policy setting and a summary of its intent.

The policy setting Turn on Applications to Prevent Sleep Transitions, when enabled, provides application and services a way to prevent Windows Vista from entering sleep mode (including but not limited to Hybrid Sleep, Stand By, or Hibernate).

Enabling the policy setting Specify the System Hibernate Timeout allows you to enter a value, in seconds, to indicate how much idle time elapses before Windows enters into hibernate. Another related policy setting is Specify the System Sleep Timeout, only the value entered (in seconds) indicates how much idle time elapses before Windows enters sleep mode.

The policy setting Require a Password when a Computer Wakes works exactly as it is written—it prompts the user for password when the computer wakes. It is also important to know this is the default behavior for Windows Vista, even when you set this policy setting to Not Configured.

Windows Vista includes a Hybrid Sleep mode. Hybrid sleep saves the system state and additional information to a hiberfile. Windows uses this file when it wakes from Hybrid Sleep mode. When enabled, the policy setting Turn Off Hybrid Sleep prevents Windows from creating the hiberfile, which disables Hybrid Sleep mode.

The last setting in this category controls the behavior (or state) of a computer running Windows Vista while in sleep mode. Recently manufactured computers conform to the specification know as Advanced Configuration and Power Interface, or ACPI. This specification is the most popular standard for computer power management. The ACPI specification describes standby states when a computer is sleeping. A portion of the specification labels these standby states as S1, S2, S3, and S4 (you can find more information on ACPI and the specifics to these states at http://www.acpi.info/). When you enable the policy Allow Standby States (S1-S3) when sleeping, Windows Vista may use standby states S1 – S3 while in sleep mode. If you disable the policy, Window Vista only allows the computer to use hibernate (standby state S4) as a sleep state.01-manage-power-p2The last category in Power Management is Video and Display Settings. This category has four policy settings total, two when Plugged In and two when On Battery. The first policy setting controls a new feature included in Windows Vista– Adaptive Display. Adaptive Display Timeout, on by default, extends the time Windows waits to turn off the display if you repeatedly turn on the display using the keyboard or mouse. Enabling Turn Off Adaptive Display Timeout disables Adaptive Display timeout resulting in Windows turning off the display once the idle timeout time is exceeded, which is controlled by the remaining policy in this category. The Turn Off the Display policy settings, when enabled, allows you to enter a value in seconds indicating the maximum allotted idle time before Windows turns off the display.

Two blogs complete and one more to go. Next time, I’ll conclude Managing Power with Group Policy by discussing how to use Window Server 2008 to manage power on Windows XP workstations.

Managing Power with Group Policy: Part 1 of 3
Managing Power with Group Policy: Part 2 of 3
Managing Power with Group Policy: Part 3 of 3

-Mike Stephens

Managing Power with Group Policy: Part 1 of 3

Posted on by
Reply

This post was originally published in the Group Policy Team blog.

Many of you probably know about the power management improvements included in Windows Vista and that you can manage power using Group Policy. However, did you know that you can manage power on Windows XP using Group Policy as well? I decided to update the “Power” blog series to show you how Windows Server 2008 can help you manage power at the desktop for both Vista and Windows XP.

Windows Vista provides a tremendous amount of power management support through Group Policy. Power management is comprised of 34 policy settings grouped in 6 different categories. The categories I will write about this week include Button, Hard Disk, Notification, and base Power Management settings.

These categories and their policy settings are located under Computer Configuration\Policies\Administrative Templates\System\Power Management. These policy settings are new with Windows Vista and apply only to computers running Windows Server 2008 or Windows Vista or. Also, these policy settings can co-exist in policies applicable to clients earlier than Windows Vista. Operating systems other than Windows Vista ignore the settings.00-manage-power-p1Power management Group Policy settings target computers therefore; the majority of the settings are under the Computer Configuration. The main category, Power Management, contains two settings, one settings allows you to deploy one of the standard power management configurations and the others allows you to specific a GUID of a customer power management configuration.

Under Power Management is the Button Category. This category has eight policy settings. You can further categorize these policy settings into two categories of four: policies for when the computer is plugged-in and for when the computer is on battery. The four settings allow you to define the actions performed when the user presses the power or sleep button or, when the user closes the lid of the computer. The last setting controls the power button located on the Start menu. Enabling any of these policy settings gives you a choice of Hibernate, Shut down, Sleep, or Take No Action.01-manage-power-p1The next category is Hard Disk. This category has two policy settings. As with the other power management categories, it categorizes these policy settings for when the computer is plugged-in and when the computer is on battery. You use this policy setting to shut down the user hard drive after a specified amount of inactivity. Enabling this policy setting allows you to provide the number of seconds before Windows reduces power to the hard drive.02-manage-power-p1The last category for the blog entry is Notification. These five policy settings allow you to configure the notification levels and actions for Low Battery and Critical Battery events. Also, you can disable Low Battery user notification. Low Battery and Critical Battery level policy settings allow you to set the level where Windows will trigger Low Battery or Critical Battery actions. You determine each level by entering a percentage of remaining battery power. Your choice of settings for Low Battery and Critical Battery actions include: Hibernate, Shut down,Sleep, and Take No Action.

Don’t ignore power management; sure, it is only a small amount of money saved per client. But add that amount up over time and across multiple computers and you could save a substantial sum of cash from reduced power usage, less wear-and-tear, as well as environmental cooling benefits.

Managing Power with Group Policy: Part 1 of 3
Managing Power with Group Policy: Part 2 of 3
Managing Power with Group Policy: Part 3 of 3

-Mike Stephens

Windows Logon Options in Vista/2008: Part Two of Two

Posted on by
Reply

Previously, I wrote about two of the policy settings under the computer configuration. Today, I’ll finish writing about the Windows Logon Options policy category by covering the remaining policy setting under the computer configuration and all of the policy settings under the user configuration.

All operating systems based on Windows NT (Windows Vista, Windows XP, Windows 2000, Windows Server 2003, and Windows Server 2008) have a security feature named Secure Attention Sequence (SAS). The purpose of the SAS is to alert the operating system that a user is ready to perform a secure action, such as logging on the computer. You see the results of SAS when you press CTRL+ALT+DEL to logon to Windows or when prompted to insert your smartcard. Both are results of a Secure Attention Sequence.

Sometimes, software must simulate a Secure Attention Sequence. Most commonly, software designed for accessibility or ease of access have this requirement. Windows Vista has a policy setting that allows you to control what software can simulate a Secure Attention Sequence name Disable and enable software Secure Attention Sequence.

This policy setting has four options, when enabled. These options are:

  • None—disallows any user mode software from simulating a Secure Attention Sequence.
  • Services—allows software running as a service to simulate a Secure Attention Sequence.
  • Ease of access applications—allows software specifically designed for ease of access to simulate a Secure Attention Sequence.
  • Services and Ease of access applications—allows both service and ease of access applications to simulate a Secure Attention Sequence.

Disabling this policy, which is the same as leaving it not configured, allows only Ease of access application running on the secure desktop to simulate a Secure Attention Sequence.

This concludes the computer policy settings, which leaves three remaining user policy settings. The first of these policy settings is the Set action to take when logon hours expire.

You can configure permitted logon hours for each user in their respected user account. Enabling this policy allows you to configure the action Windows should perform when the user’s logon hours expire. For more information about configuring logon hours read “Assigning Logon Hours” from Microsoft TechNet. These options include:

  • Lock—locks the current session and prevents the user from unlocking the session outside of their permitted logon hours.
  • Disconnect—disconnects the user from the current session and prevents the user from reconnecting to the session outside of their permitted logon hours.
  • Logoff—logs the user off the computer and prevents further logons outside of the user’s permitted logon hours. Choosing this setting can result in possible data loss.

00-logon-p2
By default, Windows does not enforce user logon hours. However, once enabled, Windows warns the user before their logon hours expire and then performs the action you configured when the user’s logon hours expire. When setting this policy setting, you should consider the Remove logon hours expiration warnings.

The Remove logon hours expiration warning, when enabled, allows you to configure Windows not to notify the user of the pending action before their logon hours expire, By default, Windows does not enforce user logon hours. Therefore, enabling this policy setting does not display warning unless the Set action to take when logon hours policy setting is enabled.

The last user policy setting is equivalent to the computer configuration setting Report when logon server was not available during user logon. Windows displays a notification to the user explaining they have logged on using cached credentials because the logon server was not available. Enabling this policy could expedite the reporting of logon problems. And, as with the other policy, serves as an excellent way to further troubleshoot logon problems. Use this setting when you want to apply the policy setting to a specific user and not to the entire computer.

Sufficed to say, these policy settings can help you secure your corporate environment during off hours as well as assist with detecting possible logon problems earlier rather than later.

-Mike Stephens