PowerMAN Power Management for Group Policy and Active Directory - superb control of enterprise IT energy costs and waste. Measure, control and save Find Data Synergy Partner

Troubleshooting

PowerMAN is a very reliable program but problems do sometimes happen. Most issues arise during installation and can normally be solved quickly. The following section details some of the most common issues and explains possible solutions for them:

PowerMAN does not deploy correctly using the GPO method

The PowerMAN application appears to deploy okay but the configured policy doesn’t seem to deploy consistently

PowerMAN appears to be deployed okay and the required settings are displayed in the Control Panel Power Management applet but the computer does not shutdown/hibernate/sleep as expected
OR PowerMAN reports event #2003: The computer is being prevented from entering the idle state by an unknown program


A Hard Disk (HDD) spin-down policy has been applied but doesn’t seem to do anything. The hard disk always remains powered on

After enabling a Hard Disk (HDD) spin-down policy the system may sometimes freeze momentarily

PowerMAN reports that there are fewer computers than expected in the site
OR PowerMAN reports many more computers than expected in the site
OR PowerMAN reports unexpected duplicate computer names within the same site
OR PowerMAN reports computers that seem to be on more than 24 hours a day!
OR PowerMAN is deployed using an image based Windows installation and only one client is reported. The service appears to be operating okay on each computer


PowerMAN is installed but the computers are not showing up on the reporting system
OR Power Management Event Log reports Event #6015: Downloaded XML was corrupt
OR Power Management Event Log reports Event #6032: Server failed to respond
OR PowerMAN Enterprise Server logs show frequent truncated XML uploads (typically around 1,400-1,500 bytes in size)
OR PowerMAN reporting fails to work consistently with M86 Security / Trustwave web content filter when split packet detection is enabled
OR PowerMAN reporting previously worked but the PID key expired or the workstation was turned off for a prolonged period and reporting subsequently fails to work or work consistently


The Windows power management applet reports blank or incorrect status for a power action or power timeout

The PowerMAN service (or power configuration) is applied using a logon script but does not consistently work

The "Managed" power scheme does not appear in the Windows Control Panel Power applet
OR The settings in the Windows Control Panel do not match those configured


Sleep has been configured (suspend to RAM). The power saving is not as great as expected

A scheduled wake policy has been configured but nothing happens

The computer is configured to hibernate or sleep. Sometimes the previous user leaves the workstation without logging off and this can lock the workstation for the next user

Windows displays a pop-up message during hibernation - Insufficient System Resources Exist to Complete the API

PowerMAN appears to be installed but will not start
OR PowerMAN service starts and then stops again
OR The event log reports a problem with the Terminal Services service (TermService)


PowerMAN works correctly on some computers but gives inconsistent results on others. The settings used are the same in both cases
OR PowerMAN works correctly on some computers but others have a recurring error in the Power Management event log


The power policy doesn’t work as expected. The Hard Disk / Monitor timeout is less than the idle timeout

Some computers wake-up (resume) unexpectedly

Computers pause at 'Applying computer settings' during start-up
OR Computers start-up is slower after installing PowerMAN


Shutdown scripts are ignored on Windows 2000/XP/2003

PowerMAN is installed but not in the path (64-bit systems)

Power management event log reports event #4042: The managed power policy has been repeatedly applied x successive times. This may indicate that another program (or user) is changing the policy settings. It may also indicate a problem with the policy settings. This warning may also be generated if multiple policy changes are for very quick succession.

Power management event log repeatedly record warning events #4030/4059

Power management behaviour is inconsistent after automatic wake-up (scheduled resume) or Wake-on-LAN
OR Sometimes computer unexpectedly returns to sleep/hibernate after only a few minutes


Problem: Power reporting is inconsistent or intermittent when installed alongside Faronics™ Deep Freeze™, Microsoft Steadystate or similar system restoration / system security software
OR Workstations are frequently re-imaged and this interferes with the PowerMAN reporting feature




Problem: PowerMAN does not deploy correctly using the GPO method

This can occur for a number of reasons. The following should be considered:
  1. Do other programs deploy correctly via Group Policy?
  2. Is the client computer within the correct Organizational Unit (OU)?
  3. Are there any errors in Event Log?
If PowerMAN is the first program to be deployed via GPO there may be an underlying problem with the domain or active directory configuration. The following should be checked:
  • Do other applications deploy successfully using the group policy mechanism from the same file-share? Sometimes applications are indivertibly configured to deploy from a local drive letter (on the server) and not a publicaly available share.
  • The client computer is within the correct Organisational Unit (OU). This can be checked with the Active Directory Users and Computers snap-in (dsa.msc)
  • The PowerMAN MSI is in a share accessible (read access) to the computer account of the client PC. Sometimes there may be NTFS access restrictions that are stricter than the share permissions. Both types of permission should be checked. The easiest way to achieve this is to grant a Read Access to the group Domain Computers.
  • Remember: The Windows group policy engine runs in the security context of the computer account. Therefore the share and underlying NTFS permissions must grant access to this account. The effective permissions are the lowest common denominator of the share and NTFS permissions.
  • Another policy or application may be preventing installation. This can be checked with the Resultant Set Of Policy (RSOP.MSC) tool provided with Windows. The error tab contains information about policy deployment problems.
  • Is the problem resolved by disabling Asynchronous policy deployment (see Computer Configuration\Administrative Templates\System\Logon in the Group Policy Object Editor)?
  • Is the problem resolved by restarting the computer twice? Depending upon other group policies scheduled for installation and removal it can take up to two additional reboots for PowerMAN to install. This situation can also happen if the MSI and licence settings are deployed separately because PowerMAN will not start until the product licence key is present.
Microsoft also provide some advice on debugging GPO based deployment issues:

Troubleshooting Group Policy Problems
Fixing Software Installation policy setting problems

Microsoft also documents a scenario where a network timeout problem can prevent effective Group Policy application. The following document explains this and provides links to the necessary Windows hotfix:

Group Policy application fails on a computer that is running Windows 2000, Windows XP Service Pack 1, or Windows XP Service Pack 2


In some cases it may be necessary to investigate further by enabling 'verbose' MSI logging. This can be enabled on the client computer by creating the following Registry value:

Key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
REG_SZ: Logging
Value: voicewarmup

This will create log files in the %temp% folder (\Windows\Temp for standard Group Policy MSI deployment. The users’ own temporary folder for manual MSI deployment). This following document explains this in detail:

How to enable Windows Installer logging

After this setting has been enabled, reboot the PC, and allow Windows to attempt the MSI installation again. When this process has completed (or nothing has happened) log into the machine and check the log files created in the \Windows\Temp folder.

If this technique does not reveal the cause of the problem it may also be useful to enable ‘verbose’ logging for the Windows Group Policy engine. Please remember that this is an advanced technique and it may take some time to decipher the log files. You can enable this logging by creating the following registry value. It may also be necessary to create the Diagnostics key if one is not already present.

Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
REG_DWORD: AppMgmtDebugLevel
Value: 0x4b

After this setting has been enabled, reboot the PC, and repeat the installation process described above. The Group Policy engine will create a file called Appmgmt.log in the C:\Windows\Debug\Usermode folder. This is further explained here:

Troubleshooting Program Deployment By Using Verbose Logging

NB: You may also need to create the Usermode folder if it does not already exist.

Problem: The PowerMAN application appears to deploy okay but the configured policy doesn’t seem to deploy consistently

This is commonly caused by attempting to apply invalid power settings. Please check the Power Management Event Log to determine the cause of the problem. This can also be caused by attempting to configure the majority of settings against a User object rather than a computer. The following guide lines should be applied:
  • The PowerMAN service should be deployed to computers (not users)
  • The majority of the settings should also be deployed to computers
  • If a specific user policy is required this should be deployed using a separate group policy to the users
Problem: PowerMAN appears to be deployed okay and the required settings are displayed in the Control Panel Power Management applet but the computer does not shutdown/hibernate/sleep as expected
OR PowerMAN reports event #2003: The computer is being prevented from entering the idle state by an unknown program


Some programs can inhibit the Windows idle timer and effectively force the computer to remain awake. There are many legitimate reasons for this. For instance:
  1. Microsoft PowerPoint forces the computer to remain active when displaying a slide show
  2. Microsoft Word has been seen to prevent the computer from sleeping when editing a document.
  3. Microsoft Windows will force the computer to remain awake if remote users are accessing local resources (such as printers or files) through a Windows share.
  4. Cyberlink PowerDVD (or similar) forces the computer to remain active when playing a DVD
  5. PowerMAN Power Configurator can be used to force the computer to remain active when certain other programs are running or the user has specified the system cannot sleep
When this happens too often or is undesirable it can prevent timeout driven power management from working effectively. This can be because of deliberate application behaviour, intermittent activity bursts, or because of non-power management aware application development practices. This is sometimes known as 'PC Insomnia'.. For instance:
  1. Background activity such as anti-virus scanning, system updates (for instance Symantec Endpoint LiveUpdate or Windows Update) or automatic system optimization (such as hard disk defragmentation) may cause the system to be relatively busy.
  2. Foreground activity such as a screen saver may keep the system artificially busy. Some screensavers may intermittently perform more intensive activates that result in the idle timer being periodically reset.
  3. Some (mainly optical) mice can infrequently (or worse continuously) send small movements resulting in the illusion that the user is active. This can sometimes happen in the presence of fluorescent light.
PowerMAN reports this problem in the Power Management Event Log. Typically this is reported as Event #2003: "The computer is being prevented from entering the idle state by an unknown program"

The following steps should be performed to locate the cause of the problem:

  1. Check the Event Log. PowerMAN logs to ensure that the desired policies have actually been applied (with no errors) and that no other program is keeping the system awake.
  2. Enable the Policy Enforcement settings and re-test. In most cases the system will perform the configured idle action as expected. If this option resolves the problem then one or more of the installed programs were preventing the idle action from occurring.
  3. Enable additional event logging (Advanced\All Information + Debug Log) and restart the computer or PowerMAN service. After a few minutes check the Power Management Event Log for additional information.
  4. Enable the debug log file (located in the Advanced configuration section) and restart the computer or PowerMAN service. After a few minutes stop the PowerMAN service and examine the log file (see the section below on using the debug log file for more information) to determine if the system is being prevented from entering the idle state because of hardware input (mouse / keyboard) or system activity. It can sometimes help to plot the idle time remaining field using a charting tool such as Microsoft Excel. This may help you visualise the timer behaviour and understand what is happening. Often this can result in a ‘saw-tooth’ pattern as the timer periodically resets. There is an example of this in the PowerMAN manual.
  5. Reduce the idle sensitivity (50% by default) to a much lower value. This change increases the threshold of system activity that Windows uses to reset the idle timer. Try reducing the sensitivity to 5%.
  6. Unplug the mouse and the keyboard and determine if the problem is resolved. Sometimes a faulty input device (especially an optical mouse) may be the cause of the problem.
  7. Unplug the network cable and determine if the problem is resolved. If the Wake-On-LAN (WOL) feature is not required disable it. If the network card supports wake on ‘directed packet’ (using IP address) and this feature is not actually required try disabling it.
  8. Confirm that the system will reliably sleep and/or hibernate (and resume again) on demand by using Windows Task Manager and selecting the appropriate option from the Shutdown menu.
  9. Stop all running programs (one at a time if necessary) and wait for the computer to enter the idle state. This can most quickly be done by disabling PowerMAN (stop the PowerMAN service) and manually setting the idle timeout to 1 minute.
If the above steps do not reveal the cause of the problem PowerMAN Technical Support will be able to offer further debugging steps to find the cause of the problem.

Problem: A Hard Disk (HDD) spin-down policy has been applied but doesn’t seem to do anything. The hard disk always remains powered on

Unfortunately for power conservation modern installations of Windows remain stubbornly busy even when no user is present.

Unlike earlier revisions such as Windows 95/98, Windows XP includes a number of optimization features that are designed to run in the background. Coupled with the typically large number of other background services this means that many systems are never idle long enough for the system hard disk (the one containing Windows) to switch off.

On fresh OS installation it is sometimes possible for the hard disk to spin-down. In practice however, many real-world installations do not because the required level of inactivity never occurs. It is, however, quite common for systems with multiple drives to reach a point where one drive is not being used and therefore that drive will spin-down as expected. (See the next problem below for the side effects that result from this.)

Technical Support can advise on possible actions that may improve the situation.

Problem: After enabling a Hard Disk (HDD) spin-down policy the system may sometimes freeze momentarily

If the hard disk becomes idle (see above problem) for a sufficient period it will spin down to save energy. When the system is activated again (for instance by a user moving the mouse or pressing a key) the hard disk is accessed again and usually takes several seconds to spin up. During this time the system may appear to freeze momentarily.

As noted in the previous problem it is quite unusual for the system hard disk to become idle enough to spin down. However, in systems with more than one hard disk it is quite likely that the secondary drives will power off after a period of inactivity. Therefore this symptom is usually more apparent on such multi-drive systems.

Typically this problem can be resolved by increasing the HDD policy timeout to the same value as the monitor timeout. This means that the HDD will spin-up at the same time the monitor powers on and therefore the delay will not be apparent to the user.


Problem: PowerMAN reports that there are fewer computers than expected in the site
OR PowerMAN reports many more computers than expected in the site
OR PowerMAN reports unexpected duplicate computer names within the same site
OR PowerMAN reports computers that seem to be on more than 24 hours a day!
OR PowerMAN is deployed using an image based Windows installation and only one client is reported. The service appears to be operating okay on each computer


These symptoms are commonly seen in the following circumstances:

  1. A problem is preventing PowerMAN being deployed correctly. This will reduce the number of computers registered in the site
  2. Computers containing a working PowerMAN installation are cloned using imaging software such as Symantec Ghost
PowerMAN uses a randomly generated identity (called the ClientGUID) to distinguish each computer within a site. If an image is deployed with such an identity PowerMAN is unable to determine this has happened and therefore all computers have the same identity. This can cause most computers to be ignored by the logging server.

This problem can be worked around by using the following technique:
  • Temporarily stop the PowerMAN service with ONE of the following commands:NET STOP POWERMAN or POWERMAN STOP<
  • Delete the following value from the registry: HKEY_LOCAL_MACHINE\SOFTWARE\PowerMAN\ClientGUID
  • If necessary shut down the computer
  • Create the image
  • Do not restart the computer until the image is created because the PowerMAN service will create another Client GUID
Problem: PowerMAN is installed but the computers are not showing up on the reporting system
OR Power Management Event Log reports Event #6015: Downloaded XML was corrupt
OR Power Management Event Log reports Event #6032: Server failed to respond
OR PowerMAN Enterprise Server logs show frequent truncated XML uploads (typically around 1,400-1,500 bytes in size)
OR PowerMAN reporting fails to work consistently with M86 Security / Trustwave web content filter when split packet detection is enabled
OR PowerMAN reporting previously worked but the PID key expired or the workstation was turned off for a prolonged period and reporting subsequently fails to work or work consistently


PowerMAN records and transfers log data on a daily basis. The data is not sent until the close of the day (after midnight). If the reporting feature is enabled the data is transferred to the reporting server. When the hosted PowerMAN reporting system is being used this is located at pmstats.org:8080. If a private PowerMAN Enterprise Server is being used then this address will normally be located somewhere on the enterprise network.

The upload normally happens between 00:00 and 03:00 if the computer is on or within a few minutes of the computer next starting. Therefore, if you installed PowerMAN today it will not report anything until tomorrow.

If computers do not register within 24 hours of being installed with PowerMAN then there may be a configuration problem. The following should be checked:

  1. The SiteGUID setting is correctly configured and registered on the PowerMAN reporting server. The SiteGUID should always contain the {brace} characters.
  2. The server address. This is normally pmstats.org. There is no need to prefix this with http:// or www.
  3. The server port. This is normally 8080. In some circumstances it may be necessary to use the alternate port 443. This is commonly necessary in networks which bar all HTTP traffic but permit standard SSL traffic.
  4. The proxy address and port setting. If you are using a proxy server please check that server address and port are correctly configured. The proxy should permit unauthenticated HTTP traffic to the reporting server. The proxy server logs may also indicate the cause of the problem.
  5. The Power Management Event Log. This will probably explain the cause of the problem. Some upload problems are reported using a standard Winsock error code. These are explained in the following Microsoft document: Windows Sockets Error Codes. In some cases it may be helpful to enable additional event logging (located in the Advanced configuration section) and restart the computer or PowerMAN service. This may be combined with the FORCEUPLOAD command (see below).
  6. Power Management Event #6015: ‘Downloaded XML was corrupt’ indicates that there was a problem with the response data from the PowerMAN server. This can happen when an intermediate proxy server blocks the traffic and returns a human-readable error page.
NB: The pmstats.org hosted reporting service has two redundant IP addresses. Ideally firewalls should be configured to use the DNS name pmstats.org. If this is not possible then BOTH IP addresses should be configured to ensure reliable operation. The addresses are 92.27.62.83 and 81.174.246.61.

In some circumstances it can be useful to force an upload. Please remember this will only work if more than one day of log data is present. It is never possible to force the upload of the current, incomplete, log data. To force an upload use the following commands:

   POWERMAN STOP
   POWERMAN FORCEUPLOAD
   POWERMAN START

If the above steps do resolve the problem it may necessary to investigate the network communication between the computer running PowerMAN and the server in more detail. This advanced technique may especially useful when using an intermediate proxy server. PowerMAN uses a standard Windows supplied component called WinHTTP to perform network communication. This is the same library used by most of Windows including Internet Explorer. Microsoft has incorporated a logging system into WinHTTP that can be used to examine the network traffic. Windows XP and earlier use a specific tool to enable logging. On Windows Vista and later this functionality is built-in to the operating system.

On Windows XP/2003 and earlier proceed as follows:

  • Confirm that there is some PowerMAN data to upload. The easiest way to check this is to confirm that more than one log value exists in HKLM/Software/PowerMAN/Logs
  • Obtain the WinHTTPTraceCfg tool. This is in the Windows 2003 Resource Kit
  • Enable WinHTTP tracing with the following command:

       winhttptracecfg -e 1 -d 0 -s 2 -t 1 -l c:\winhttplog

    This will create a series of files in the C:\ folder prefixed 'winhttplog'
  • Force an upload using the above technique:

       POWERMAN STOP
       POWERMAN FORCEUPLOAD
       POWERMAN START
  • Check the C:\ folder for a log file (there may be several). These show the network transaction with the (proxy) server.
  • Remember to disable logging with the command:

       winhttptracecfg -e 0

On Windows Vista and later proceed as follows:

  • Confirm that there is some PowerMAN data to upload. The easiest way to check this is to confirm that more than one log value exists in HKLM/Software/PowerMAN/Logs
  • Create a folder for the log files e.g. C:\Logs
  • Ensure that Everyone has Full Control access to the C:\Logs folder. This step is necessary because WinHttp runs in several different security contexts.
  • Open a CMD prompt and launch NETSH.EXE
  • At the prompt type: winhttp and press Enter
  • To view the current configuration use the following command and press Enter:

       show tracing

  • To view the syntax available use the command:

       set tracing /?

  • To configure logging use the command:

       set tracing output=file trace-file-prefix=c:\logs\powerman level=verbose format=ansi state=enabled

       This will create a series of files in the C:\logs folder.

  • Force an upload using the above technique:

       POWERMAN STOP
       POWERMAN FORCEUPLOAD
       POWERMAN START
  • Check the C:\logs folder for a log file (there may be several). These show the network transaction with the (proxy) server
  • Remember to disable logging with the NETSH command:

       set tracing state=disabled
Microsoft provides a reference to the NETSH commands used for WinHTTP logging here:

http://technet.microsoft.com/en-us/library/cc731131(v=ws.10).aspx

The most common proxy server communication issues are:

  • Incorrect proxy server address / port setting
  • Proxy server requires authentication – PowerMAN does not support proxy authentication. You can work around this behaviour by creating a proxy server exception for the PowerMAN server
  • The PowerMAN server address is missing from the proxy 'white-list'
Specific problems when Trustwave Web Filtering and Reporting Suite (formerly known as M86 Web Filtering and Reporting Suite) is present:

PowerMAN reporting may fail to work consistently when Trustwave Web Filtering and Reporting Suite (formerly known as M86 Web Filtering and Reporting Suite) is present. This software is commonly used in educational establishments to provide web content filtering and logging.

This problem occurs because the web filtering software truncates multipacket HTTP POST requests. This can prevent the PowerMAN reporting protocol from operating correctly when attempting to upload a backlog of multiple days reporting data. This scenario is most common when a workstation has been turned off for a prolonged period or a PowerMAN product key has expired and been updated sometime later. This scenario is less likely if no PowerMAN reporting data backlog has built-up. For this reason the problem not initially be apparent and may emerge later.

If this problem occurs the WinHTTPTraceCfg (or proxy) logs will typically show something similar to:

"Redirected by M86 Web Filter Internet access to the requested website has been denied based upon your user profile and organisation's internet usage policy" (Result code 302)

This problem can be worked around by modifying the content filter settings to disable split packet detection. The M86 documentation states that this feature is disabled by default. However, if split packet filtering is enabled the scenario described above may occur.

Customers have also reported that this problem can be worked around by adding the reprting server domain (typically pmstats.org) into a content filter category that is permitted for workstations with a currently logged on user and when there is no logged on user.



Problem: The Windows power management applet reports blank or incorrect status for a power action or power timeout

The Windows XP Control Panel Power Management applet (Powercfg.cpl) is only designed to show certain power states (it does not support power off) and certain timeout values (1, 3, 5, 10 minutes etc). PowerMAN allows other values to be specified which the applet is incapable of displaying. In most circumstances the relevant value is displayed as blank or downgraded to the nearest displayable setting. This does not alter the application of the desired policy which will function as desired.

Problem: The PowerMAN service (or power configuration) is applied using a logon script but does not consistently work

PowerMAN is a service application and therefore must be installed by an Administrator (or via GPO). Similarly, the majority of PowerMAN settings are in the HKEY_LOCAL_MACHINE area of the registry and this is not modifiable by most users. PowerMAN cannot be installed or configured from a user logon script.

Problem: The "Managed" power scheme does not appear in the Windows Control Panel Power applet
OR The settings in the Windows Control Panel do not match those configured


PowerMAN typically only refreshes power settings every 10 minutes. Therefore it may take a few minutes for recently changed settings to become active. Group Policy settings can sometimes take up to 120 minutes to propagate across the network. Please be patient.

You can force a faster update using the following commands:

   GPUPDATE /FORCE
   POWERMAN RESTART

Sometimes it isn’t possible for PowerMAN to activate the configured settings. This can happen if there is an inconsistency in the settings or (sometimes) if the hardware is not capable of configuration selected. If the desired settings do not appear in the Control Panel applet or configuration doesn’t function as expected please check the Power Management event log.

Problem: Sleep has been configured (suspend to RAM). The power saving is not as great as expected

There are several levels of sleep called (S1-S3). Each offers increased amounts of energy saving by progressively stopping additional levels of the PC hardware. All resume within a second or two and therefore the highest (S3) setting should be used wherever possible. Sometimes PC motherboards are not capable of reaching S3 (or have been configured to use S1 instead). Sometimes these are referred to as Suspend to RAM or Power On Suspend. Please check your BIOS settings to ensure that S3 support is enabled.

Windows XP / 2003 can prevent use of the S3 state when USB devices are connected (preferring the S1 state). This feature is implemented because of problems sometimes found with resume from S3 when using USB devices. Microsoft explains this in the following document:

Description of how to enable the S3 system power state for standby when USB devices are armed for wake


Problem: A scheduled wake policy has been configured but nothing happens

Unfortunately not all computers are capable of resuming from all sleep states. This functionality depends on underlying support from the PC motherboard hardware which is not always present. The following steps should be checked:

  1. Check the Power Management Event Log. A problem may be preventing the wake policy from being applied
  2. Use the POWERMAN INFO command to determine the supported wake states. Check the value of Min RtcWake State. This is the highest (S1-S5) state from which the computer is capable of waking. Sometimes this can be changed by modifying the BIOS settings.
  3. Check the BIOS Power Management settings. Different BIOS manufacturers use different terminology for the wake-up / resume feature. If the computer supports this function it is normally located in the power management settings and may be described as S1/4 Resume, Alarm Resume or similar. This setting should not be confused with the BIOS based alarm feature (with a resume time) that is present in some older BIOS.
  4. Attempt wake from different levels of sleep – some computers can wake from hibernate whilst others can only wake from the suspended state. You can test this using the POWERMAN HIBERCHECK and SLEEPCHECK commands. Remember most hardware does not support wake from the powered off state (although it is quite common for wake from hibernate to work fine). In addition, some laptop computers are designed to prevent system resume when running on battery (DC) power. To confirm this re-test the computer when the mains supply is connected.
  5. Contact the motherboard vendor to determine if the required functionality is available
Problem: The computer is configured to hibernate or sleep. Sometimes the previous user leaves the workstation without logging off and this can lock the workstation for the next user

This problem can be avoided by using the logout feature. Configure the Default User (or specific user) power settings to log the user out after the desired time period. Configure the Default User idle action to ‘Nothing’ when using the logout feature and use a suitable No User policy to save energy. Systems configured using this approach will never be locked.

Problem: Windows displays a pop-up message during hibernation - Insufficient System Resources Exist to Complete the API

This problem is caused by a known issue in Microsoft Windows XP. This problem typically occurs when the computer uses 1 gigabyte (GB) or more of RAM. The following Microsoft document explains how to obtain the required hotfix:

The computer occasionally does not hibernate and you receive an "Insufficient System Resources Exist to Complete the API" error message

Problem: PowerMAN appears to be installed but will not start
OR PowerMAN service starts and then stops again
OR The event log reports a problem with the Terminal Services service (TermService)


PowerMAN is designed for simple, single-file, deployment and does not depend on any non-Windows components or external frameworks (such as Microsoft .NET). When running on Windows XP PowerMAN requires the Terminal Services (TermService) service to be available. This service is used to provide power configuration for non-administrator users. This service is not required when PowerMAN is running on Windows 2000, Windows Vista or later.

PowerMAN will operate correctly on systems where the TermService is set to manual (the default) or automatic start. However, the PowerMAN service will fail to start if the TermService is disabled. Some organisations disable this service to reduce memory footprint or enhance system security. This configuration is unfortunately not compatible with PowerMAN when running on Windows XP.

Microsoft documents the following method to disable remote desktop access without disabling the TermService:

How to disable Remote Desktop by using Group Policy


Problem: PowerMAN works correctly on some computers but gives inconsistent results on others. The settings used are the same in both cases
OR PowerMAN works correctly on some computers but others have a recurring error in the Power Management event log


There are several reasons why this may happen:
  • Incomplete power settings / Interaction with pre-existing settings – This happens when pre-existing settings are not fully replaced by the new PowerMAN configuration. For instance, if specific user policies are used or a NoUser policy is applied this can still leave periods when no PowerMAN policy is applicable. In this case the pre-existing settings present on the computer are used. This scenario is especially likely if other power centralised-management techniques (such as EZ-GPO) have been trialled on the same systems in the past.

    This problem can be avoided by ensuring that a Default User policy is always applied. This step may not be strictly necessary but it will ensure that a known power configuration is always operational.
  • Hardware limitations / Windows Configuration – Sometimes the configured power policy may not be supported by the computer hardware or existing Windows configuration. This commonly occurs when sleep mode is not supported (or is disabled in the BIOS) or the hibernation feature is not enabled. Depending upon the cause of this PowerMAN may use alternative settings or do nothing. PowerMAN reports this in the event log.
Rarely similar problems can happen if no global settings are employed. To avoid this and ensure that the power configuration always works as intended we suggest the following guidelines:

  • Remember to check the hardware capabilities. This can be done with the POWERMAN INFO command. Only use sleep if it is supported by the hardware
  • Similarly, remember to enable the hibernate feature if you intended to use hibernate as an idle or scheduled action
  • Always configure a Default User policy (even if it does nothing)
  • Always configure a Global power policy (even if its settings are trivial)
  • Remember to check the Power Management event log. It may provide further explanation of the problem

Problem: The power policy doesn’t work as expected. The Hard Disk / Monitor timeout is less than the idle timeout

PowerMAN will reject inconsistent settings. For instance, it is not possible to configure the hard disk to spin-down or the monitor to standby after the system has already entered a low-power state. Please change the settings to ensure that the hard disk or monitor timeout is less than the idle timeout. Please check the Power Management event log for further information.


Problem: Some computers wake-up (resume) unexpectedly

There are several reasons a PC may automatically resume from a low-power state. The following steps will help isolate the cause of the problem:
  • Unplug the mouse and the keyboard and determine if the problem is resolved. Sometimes a faulty input device (especially an optical mouse) may be the cause of the problem
  • Unplug the network cable and determine if the problem is resolved. If the Wake-On-LAN (WOL) feature is not required disable it. If the network card supports wake on ‘directed packet’ (using IP address) and this feature is not actually required try disabling it
  • Study the power management event log. Is there a pattern? Does the automatic resume happen at set times or regular intervals?
  • Try a minimal software image (removing all non-essential applications). The automatic resume may be caused by another application

Problem: Computers pause at 'Applying computer settings' during start-up
OR Computers start-up is slower after installing PowerMAN


The PowerMAN service requires the [Windows] Terminal Services service (TS) in order to provide power management for restricted users. This service is also known as the Remote Desktop Service in later releases of Windows. PowerMAN waits for the TS service to start before itself completing start-up.

In some rare cases this dependency can cause the computer start-up sequence to take longer than normal. The most common symptom of this is the 'Applying computer settings' screen is displayed for longer than normal during system boot. This problem can be avoided by modifying the TS start sequence to start before PowerMAN. The simplest way to do this is to change the service start type from Manual to Automatic. In a network environment this can be easily accomplished by using a Group Policy or modifying the Default Domain Policy.

TS and RDS Default Domain Policy

Problem: Shutdown scripts are ignored on Windows 2000/XP/2003

This problem may occur on Windows 2000/XP/2003 where an idle policy has been configured to shutdown the system rather than suspend (sleep or hibernate). The built-in Windows idle timer does not correctly support system shutdown and fails to execute operating system shutdown scripts. This is a known limitation of Windows. The PowerMAN internal shutdown timer feature is available to work around this problem. When this feature is enabled PowerMAN implements the idle timer internally and shutdown scripts will execute as expected. This feature is disabled by default. This feature is available in PowerMAN v5.2 and later.

Problem: PowerMAN is installed but not in the path (64-bit systems)

This problem may occur when the 32-bit version of PowerMAN is installed on 64-bit systems. The PowerMAN client is a common executable (EXE) on all supported versions of Windows. The client software is available in both 32-bit and 64-bit formats. The 32-bit version may be used in mixed 32/64-bit workstations estates and offers identical features on 64-bit systems. The 64-bit version is provided to support 100% 64-bit environments. If the 32-bit version is installed on a 64-bit system it is located in the \Windows\Syswow64 folder. This is not in the standard command-prompt search path. This feature is available in PowerMAN v5.2 and later.

Problem: Power management event log reports event #4042: The managed power policy has been repeatedly applied x successive times. This may indicate that another program (or user) is changing the policy settings. It may also indicate a problem with the policy settings. This warning may also be generated if multiple policy changes are for very quick succession.

Occasionally other programs may interfere with PowerMAN. This event warns that PowerMAN has repeatedly configured the chosen power settings because some other process is also changing them. In some rare circumstances it may also indicate that Windows has changed the applied power settings because they are incompatible with the system hardware. If this continues please check policy settings, hardware support (PowerMAN INFO) and enable additional event logging to determine the cause.


Problem: Power management event log repeatedly record warning events #4030/4059

Events #4030 and #4059 record the pre-existing and post-configuration Windows power settings respectively. If these settings contain inconsistencies it may result in them failing to operate as expected. PowerMAN contains logic to check for such inconsistencies and warn about them both before and following a configuration cycle. The most common inconsistency is where the video or hard disk timeout is greater than the idle timeout. PowerMAN issues these warnings for both the PowerMAN ‘managed’ power scheme and the built-in Windows power schemes. Therefore you may ignore these warnings if you are not using PowerMAN for active power management (e.g. monitoring only).


Problem: Power management behaviour is inconsistent after automatic wake-up (scheduled resume) or Wake-on-LAN
OR Sometimes computer unexpectedly returns to sleep/hibernate after only a few minutes


Windows treats automatic system resume differently from manual resume. Automatic resume occurs when the system is awoken by a timer, network traffic or non-manual source. By design, Windows will return to the previous low-power state (sleep or hibernate) after a couple of minutes if no user activity occurs. Windows behaves in this way to prevent automatic resume tasks from consuming excess energy. This can sometimes be confusing because the Windows behaviour is completely independent of normal power management and is not well documented by Microsoft.

In Windows XP the automatic resume timeout is fixed at 2 minutes. In later versions of Windows it may be configured with a hidden power management setting. Programs such as updates and AV scanners can programmatically postpone this behaviour whilst they complete their task.

This Windows feature can sometimes be undesirable. PowerMAN provides the ‘Resume Configuration’ feature to override this behaviour. This feature allows the administrator to define a grace period during which automatic re-suspend will be inhibited. In PowerMAN v5.2 and later this feature is also automatically active during a protected time period. This allows scheduled maintenance tasks to complete without the system returning to a low-power state.


Problem: Power reporting is inconsistent or intermittent when installed alongside Faronics™ Deep Freeze™, Microsoft Steadystate or similar system restoration / system security software
OR Workstations are frequently re-imaged and this interferes with the PowerMAN reporting feature


Several system products exist which prevent effective write-access to the local file system. These products generally operate by re-directing all file write requests to a temporary file which is deleted upon restart. This creates a system which is effectively reset upon start-up and therefore immune to unauthorised re-configuration by users or installed software. This software is commonly used in high-turnover environments such as school computer labs or university open-access areas. Such software can interfere with the PowerMAN reporting mechanism.

This happens because PowerMAN caches reporting data in the local registry and only uploads it periodically. If the system is restarted prior to a PowerMAN upload the cached data can be lost resulting in intermittent reporting coverage. The result can be large gaps in the reported data.

This problem can be avoided by using the ‘Log Backup’ feature located with the reporting settings. This allows a parallel reporting log backup file to be stored in an arbitrary local drive/folder. This file is used by PowerMAN if the primary registry based data is missing. This PowerMAN feature may also be used as part of a frequent re-imaging strategy. There are two common scenarios:
  • System frequently re-imaged (e.g. daily) – Configure the log back up file and incorporate it into the re-imaging process. Typically this will require the file to be stored elsewhere prior to re-imaging and restored to the original location prior to system restart.
  • System security software – Configure the log backup file to be stored in a protect filesystem location (e.g. The ‘Thaw space’ for Faronics™ Deep Freeze™)