Worklet is unexpectedly showing as "Pending Update"

A Worklet can show a "Pending Update" status in the console, indicated by a clock icon, even after it has run successfully. This status comes from the Worklet's Evaluation Code, so resolving it means looking at what that code is reporting rather than at the remediation.

Root cause

The Evaluation Code determines whether a device is compliant. Any non-zero exit code tells Automox the device still requires remediation, so a device stays in "Pending Update" for as long as the evaluation keeps exiting non-zero, regardless of whether the remediation already did its job.

Evaluation code also runs on every device scan, whether or not the policy has a schedule. An evaluation that can never return zero therefore keeps the device permanently pending and keeps the remediation permanently eligible to run.

Cause 1: the evaluation always exits non-zero

Setting the Evaluation Code to exit 1 with no logic reports every device as needing remediation, every scan, forever. Replace it with a check for the change the remediation actually makes:

$value = Get-ItemProperty -Path "HKLM:\SOFTWARE\YourKey" -Name "YourValue" -ErrorAction SilentlyContinue

if ($value.YourValue -eq "ExpectedData") {
    exit 0
} else {
    exit 2
}

Check the actual state the remediation changes wherever possible. Writing a marker file and testing for that file works, but it only proves the script reached the end, not that the change is still in place.

A note on which non-zero exit code to use

Because of how PowerShell scripts are launched for Worklets, an exit 1 from evaluation code frequently surfaces in logs as Exit Code 124, COMMAND TIMED OUT, even though the script ran to completion and produced output. Any non-zero code triggers remediation, so the behavior is correct, but the reported error is misleading and sends people looking for a timeout that did not happen.

Using a different non-zero value such as exit 2 avoids that confusion and makes genuine timeouts distinguishable from a normal non-compliant result.

Cause 2: the evaluation checks the wrong location

If your Evaluation Code is a real check and the device still reports pending, the check may be looking somewhere the remediation did not write. Worklets run PowerShell in 32-bit mode as the SYSTEM account, and both of those change what a check can see.

• 32-bit registry redirection. On 64-bit Windows, a 32-bit process reading HKLM\SOFTWARE is redirected into HKLM\SOFTWARE\WOW6432Node. If the remediation wrote to the 64-bit hive and the evaluation reads the redirected one, the value is never found and the device stays pending.
• HKEY_CURRENT_USER under SYSTEM. HKCU resolves to the profile of the account running the script. Under SYSTEM that is the SYSTEM account's hive, not the signed-in user's, so a check against HKCU will not see a change made in a user's profile.
• User-scoped file paths. The same applies to anything under a user profile directory.

Confirm the evaluation and remediation are both operating on the same view. See Requested Registry Access is Not Allowed for the 64-bit invocation pattern, and How to Test a PowerShell Script Locally for Worklets for running a script under the same conditions Automox uses.

Finding the evaluation output

Evaluation runs as part of the device scan, so it does not appear in the main activity log. To see what your Evaluation Code actually returned, open the Device Details page and expand the Device Logs section beneath the Device Snapshot, which is collapsed by default.

• policy_#####_test contains the Evaluation Code output
• policy_#####_remediation contains the Remediation Code output

where ##### is the policy ID. Reading the evaluation output is the fastest way to tell whether the check is failing or simply looking in the wrong place.

Note also that running a Worklet manually skips the Evaluation Code entirely and executes only the remediation, so a manual run will not reproduce or clear a pending status. See Why is the Evaluation Code Skipped When I Manually Run a Worklet?

Best practices

• Have the evaluation verify the end state, not that a script ran.
• Make the evaluation output say what it found, so the device log explains the decision.
• Test evaluation and remediation together on one device before deploying broadly.
• Revisit evaluation logic when the remediation changes, so the two stay aligned.

Related articles

• Why is the Evaluation Code Skipped When I Manually Run a Worklet?
• Requested Registry Access is Not Allowed
• How to Test a PowerShell Script Locally for Worklets