One-Time "Set-ExecutionPolicy" Iteration in a Worklet

Issue

A Worklet or policy fails on a Windows device with an error similar to:

File C:\Program Files (x86)\Automox\execDir...\execcmd....ps1 cannot be loaded because
running scripts is disabled on this system. For more information, see
about_Execution_Policies at https://go.microsoft.com/fwlink/?LinkID=135170.
    + CategoryInfo          : SecurityError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : UnauthorizedAccess

A related variant reports that the script "is not digitally signed," which occurs when the effective execution policy is AllSigned (or RemoteSigned for scripts flagged as downloaded from the internet).

In other cases, a Worklet that calls Set-ExecutionPolicy completes with exit code 0 but logs a warning that the setting "is overridden by a policy defined at a more specific scope." This warning is informational, not a failure, as long as the effective policy still allows scripts to run.

Environment

• Automox (current agent release)
• Windows devices
• Worklets and policies that execute PowerShell scripts
• Environments where PowerShell execution policy is managed by Group Policy (GPO)

Overview

PowerShell evaluates execution policy across five scopes, in this order of precedence (highest wins):

1. MachinePolicy — set by Group Policy (Computer Configuration)
2. UserPolicy — set by Group Policy (User Configuration)
3. Process — the current PowerShell session only
4. CurrentUser
5. LocalMachine

Two consequences matter for Worklets:

• The Automox agent launches its Worklet PowerShell sessions with a Bypass execution policy, and Worklets run as NT AUTHORITY\SYSTEM. In most environments no Set-ExecutionPolicy call is needed inside a Worklet at all.
• Because MachinePolicy and UserPolicy sit above Process in the precedence order, a GPO-enforced execution policy overrides anything a script can set — including Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass. No command inside a Worklet can override a Group Policy-enforced execution policy; the fix in that case is in the GPO itself.

See Microsoft's about_Execution_Policies for the full precedence and scope reference.

Resolution

1. Add a one-time, session-scoped policy change to the Worklet (happy path)

Place this at the top of the Worklet code:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force

• -Scope Process limits the change to the current PowerShell session; it reverts automatically when the session ends and never touches machine-wide settings.
• -ExecutionPolicy Bypass allows scripts to run without restriction for that session.
• -Force suppresses confirmation prompts.

Avoid calling Set-ExecutionPolicy without -Scope. That attempts to change the machine-wide (LocalMachine) policy, which a GPO can block — producing the "overridden by a policy defined at a more specific scope" warning.

2. Verify the effective policy

Run the following on an affected device (or in a Worklet) and review all five scopes:

Get-ExecutionPolicy -List

Run it in the same architecture the script executes under. The Automox agent runs scripts in a 32-bit PowerShell session, so also check from a 32-bit (x86) PowerShell window when comparing results.

3. If MachinePolicy or UserPolicy shows anything other than "Undefined," the policy is Group Policy-controlled

A process-scoped Bypass cannot override this. Fix it at the GPO level:

1. Run gpresult /h report.html (or gpresult /r) on the device to identify which GPO applies the setting.
2. In that GPO, review Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on Script Execution. The corresponding registry values live under HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell (and HKCU\... for user policy).
3. Set it to Enabled with Allow local scripts and remote signed scripts (equivalent to RemoteSigned), or another value that permits the scripts in your environment. Setting it to Disabled, or to Allow only signed scripts without signing your Worklet content, blocks execution.
4. Because Worklets run as SYSTEM, confirm the computer-side (MachinePolicy) setting in particular.

4. If the error mentions "not digitally signed"

The effective policy is AllSigned (or RemoteSigned against internet-flagged files). Either relax the GPO as above or sign the scripts your organization requires to run under that policy.

5. If a device's local policy is simply restrictive (no GPO involved)

Set it once persistently rather than in every Worklet — for example Set-ExecutionPolicy RemoteSigned from an elevated prompt. If the device still checks in to Automox, the Worklet Catalog entry Windows - Security - Set PowerShell ExecutionPolicy to RemoteSigned can apply this remotely (this catalog Worklet requires an Automox premium/paid Worklet Catalog entitlement).

6. If the error appears suddenly across many devices with no policy changes

• Check whether the affected devices recently moved to a new or beta agent version. A past beta agent release briefly produced this error fleet-wide even on devices whose execution policy was correctly configured; it was resolved by the follow-up agent release. Confirm devices are on the current agent release, and contact Automox Support if a whole fleet fails at once.
• Endpoint security or application-control software may also block PowerShell script execution independently of execution policy in some configurations; confirm the Automox agent is excluded/allow-listed in those tools.

Notes

• The Worklet session's Bypass reverts when the process exits — -Scope Process never persists a change to the device.
• An exit code of 0 with the "overridden by a policy defined at a more specific scope" warning means the Worklet ran; the message only indicates the machine-wide policy change was refused, and the effective policy shown by Get-ExecutionPolicy -List still governs.
• Because the agent runs scripts in a 32-bit session, scripts that need 64-bit modules should invoke $env:SystemRoot\sysnative\WindowsPowerShell\v1.0\powershell.exe with a script block (see Using 64-bit PowerShell Code with Automox) — a separate issue that can look similar when a module "cannot be loaded."
• Bypassing execution policy removes a safety layer; scope it to the session and use it only where needed.
• For persistent policy configuration steps, see Windows: How to Set the Execution Policy.