Change Power Scheme

What the Power Scheme Changer does

This Automox Worklet™ changes the active Windows power profile to a scheme you specify. Windows includes built-in power profiles that control CPU performance, display timeouts, hard disk spin-down, and other power-related settings. The Worklet uses WMI (Win32_PowerPlan class) and powercfg.exe to query and modify the active profile.

The three standard Windows power profiles are Power Saver (reduces performance to save energy), Balanced (adjusts performance based on demand), and High Performance (maximizes performance at the cost of power consumption). Some systems may have additional OEM-defined profiles or custom profiles created by administrators.

The Worklet validates that the specified power profile exists on the endpoint before attempting to activate it. If the profile name does not match exactly (power profile names are case-sensitive), the Worklet lists available profiles in the error output to help with troubleshooting.

Why manage power schemes through Automox

Power settings affect both user experience and energy costs. Users on workstations running Power Saver may experience sluggish performance during demanding tasks. Servers running Balanced may not deliver consistent performance under load. Standardizing power profiles based on endpoint role eliminates these issues.

High Performance mode is often required for endpoints running time-sensitive applications, audio/video production software, or real-time data processing. These applications may experience glitches or performance issues if the CPU throttles down during periods of low load.

Conversely, laptops used primarily on battery benefit from Power Saver or Balanced profiles that extend battery life. Managing these settings centrally through Automox lets you apply appropriate profiles to different endpoint groups without relying on users to configure settings correctly.

How power scheme changes work

1. Evaluation phase: The Worklet queries Get-CimInstance for Win32_PowerPlan objects in the root\cimv2\power namespace, filtering by ElementName matching $pwrProfile. If the profile exists and its IsActive property is true, the endpoint is compliant. If the profile exists but is not active, the endpoint is flagged for remediation. If the profile does not exist, the Worklet outputs available profiles for troubleshooting.

2. Remediation phase: The Worklet extracts the power profile GUID from the InstanceID property, formats it for powercfg.exe, and executes powercfg.exe /s {GUID} to activate the profile. After a brief delay, it re-queries Win32_PowerPlan to verify the profile is now active. Success or failure is reported based on the IsActive property value.

Power scheme configuration requirements

• Windows 7 or later

• PowerShell 2.0 or later

• Configure $pwrProfile with exact profile name (case-sensitive): 'Power Saver', 'Balanced', or 'High Performance'

• FixNow compatible for immediate execution

• Custom or OEM power profiles may have different names (check powercfg /list output)

Expected power behavior after configuration

After successful remediation, the specified power profile becomes active immediately. Power Saver mode reduces CPU frequency, dims displays sooner, and spins down drives more aggressively. High Performance mode keeps the CPU at higher frequencies and prevents aggressive power-saving behaviors. Balanced mode adjusts dynamically based on workload.

Users can still change the power profile manually through Windows settings unless restricted by Group Policy. If the Worklet detects drift back to a different profile on subsequent runs, it will remediate again. For persistent enforcement, consider complementing this Worklet with Group Policy settings that restrict power plan changes.

How to validate change power scheme changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for change power scheme.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as Get-CimInstance, Select-Object, Write-Output.

4. Validate remediation effects from script operations such as Get-CimInstance, Select-Object, Write-Output, then rerun evaluation for compliance.