Audit Windows laptop battery health and capacity metrics to surface degraded batteries before they fail
This Automox Worklet™ runs a battery diagnostic on Windows laptops and mobile endpoints, then writes a structured report into the Automox Activity Log. The Worklet uses Get-CimInstance against the Win32_Battery class to enumerate every battery present on the endpoint, including secondary batteries in dual-battery laptops, and reports each one in its own labeled block.
The report covers three sections per battery. Battery Details lists Caption, Description, and Device ID. Battery Health lists Availability, Battery Status, Battery Health Status (the WMI Status property), Battery Health Percentage (FullChargeCapacity divided by DesignCapacity, multiplied by 100), Time on Battery in seconds, Estimated Run Time in minutes, and Estimated Charge Remaining. Battery Specifications lists Battery Type (Chemistry), Design Capacity in mWh, Full Charge Capacity in mWh, Design Voltage in mV, Expected Life in months, and Cycle Count.
Integer return codes from Win32_Battery are translated to readable labels before they reach the Activity Log. BatteryStatus 3 becomes Fully Charged; Chemistry 6 becomes Lithium-ion; Availability 10 becomes Degraded. Indeterminate EstimatedRunTime values (the 71582788 sentinel Microsoft returns during charging) are replaced with a charging-state explanation. The result is a report a support engineer can read directly, with no manual lookup against MSDN tables.
Battery degradation is the most common hardware failure in a remote workforce, and it almost always surfaces as a user complaint rather than a managed alert. A laptop drops to two-hour runtime, the user blames Windows Update, and the ticket bounces around until someone runs powercfg /batteryreport on the affected endpoint. By then the user has already missed work or ordered a replacement at retail price.
Refresh-cycle planning normally starts from a half-populated spreadsheet that asks each user to check About This PC and report battery age, and the response rate is rarely above 40%. Schedule this read-only Worklet against the laptop endpoint group so Win32_Battery, EstimatedChargeRemaining, and DesignCapacity values are pulled directly from WMI on every endpoint. The next hardware refresh meeting starts with current per-endpoint cycle and capacity data instead of self-reported estimates, and the output lands in the Activity Log for export into asset planning systems alongside warranty status.
Evaluation phase: Reads Win32_ComputerSystem.PCSystemType. If the value is not 2 (Mobile Device), the endpoint is not a laptop and the script exits 0 without flagging. Desktops and servers are filtered out at this stage so policy runtime is not spent on hardware classes that cannot have a battery. Laptops and mobile endpoints are flagged for remediation and the script exits 1.
Remediation phase: Re-confirms the endpoint type, then queries Win32_Battery. If no battery is present (undocked tablet, removed pack), the script logs the condition and exits 0. For each battery detected, the Get-BatteryStatus function extracts the property set, translates the integer enums into readable labels, and writes the three-section report to standard output. The report appears verbatim in the Automox Activity Log for the policy run.
Windows 7, Windows 8, Windows 10, or Windows 11 endpoint classified as a laptop or mobile device (PCSystemType 2)
PowerShell v3 or higher
Local administrator or SYSTEM context to query Win32_Battery (the Automox agent runs at this level by default)
A working battery; an undocked tablet or laptop with the pack removed reports no battery and exits cleanly
Some endpoints may require an up-to-date BIOS or firmware revision to populate every Win32_Battery field; unknown values surface as Unknown rather than failing the report
After the Worklet runs, the Activity Log contains one BEGIN BATTERY N DIAGNOSTIC REPORT block per battery present on the endpoint. The most actionable lines for a refresh decision are Battery Health Percentage and Cycle Count. A health percentage below 80 paired with a cycle count above 500 is the industry signal for a battery near end-of-life. The Estimated Run Time line confirms what the user would see at the OS level.
To validate the Worklet on a pilot endpoint, run powercfg /batteryreport from an elevated Command Prompt and compare the generated HTML report against the Activity Log output. The DesignCapacity, FullChargeCapacity, and CycleCount values should match between the two sources. Schedule the Worklet quarterly to feed a refresh-planning dashboard, or run it on demand against a single endpoint when a user reports degraded runtime.


Loading...
Consider Worklets your easy button
A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

AUTOMOX + WORKLETS™
Uncover new possibilities with simple, powerful automation.
By submitting this form you agree to our Master Services Agreement and Privacy Policy
By submitting this form you agree to our Master Services Agreement and Privacy Policy.
Already have an account? Log in