)
)
Automox Worklet™ policies let you automate virtually any endpoint task you can write a script for. Built on a two-part evaluation and remediation model, Worklets run PowerShell on Windows and Bash on macOS and Linux to check conditions, enforce configurations, and manage software across your entire fleet. This guide walks you through creating, configuring, and running Worklets so you can standardize operations at scale.
What is an Automox Worklet?
A Worklet is a custom policy within the Automox console that runs scripts on your endpoints. Unlike built-in patch or configuration policies that target specific, predefined tasks, Worklets give you full scripting control over what gets evaluated and what gets remediated.
Each Worklet contains two code blocks: evaluation code and remediation code. The evaluation code runs during every device scan to test a condition. The remediation code runs only when the evaluation flags an endpoint as non-compliant.
Worklets support PowerShell on Windows and Bash on macOS and Linux. The scripts execute in the version installed on the target endpoint, which means you can use the full capabilities of each scripting language.
When should you use Worklets vs. other policy types?
Automox offers several policy types, each designed for different scenarios. Choosing the right one keeps your workflows efficient and maintainable.
| Policy type | Best for | Scripting required | Examples |
|---|---|---|---|
| Built-in patch policies | OS and third-party patching | No | Windows updates, Chrome updates, Firefox patches |
| Required Software policies | Deploying or maintaining specific applications | No (installer upload) | Installing Zoom, deploying agents, maintaining software versions |
| Worklets | Any custom task you can script | Yes (PowerShell or Bash) | Registry edits, service management, compliance checks, software removal |
Built-in patch policies handle standard patching without any scripting. Required Software policies install or maintain applications from uploaded installers. Worklets fill every gap in between, handling anything you can express in a script.
If a built-in policy or Required Software policy covers your use case, start there. Reach for Worklets when you need custom logic, conditional evaluation, or multi-step remediation.
How does the evaluation and remediation model work?
The evaluation and remediation structure is what makes Worklets flexible. Think of it as an if-then relationship: if the evaluation detects a problem, then the remediation fixes it.
Evaluation code
The evaluation code tests a condition and returns an exit code. It runs every time a device performs a scan.
Exit code 0 means the endpoint is compliant. No remediation takes place.
Any non-zero exit code flags the endpoint for remediation at the next scheduled policy run.
Here is an example that checks whether a Windows registry key exists:
# Evaluation: Check if a registry key exists
$regPath = "HKLM:\SOFTWARE\YourCompany\ComplianceSetting"
if (Test-Path $regPath) {
$value = Get-ItemProperty -Path $regPath -Name "Enabled" -ErrorAction SilentlyContinue
if ($value.Enabled -eq 1) {
Write-Output "Compliant: Registry key is set."
exit 0
}
}
Write-Output "Non-compliant: Registry key is missing or incorrect."
exit 1
Remediation code
The remediation code runs only when the evaluation returns a non-zero exit code and the policy's scheduled time arrives. This code block is open-ended and can perform any task you can script.
# Remediation: Create the registry key and set the value
$regPath = "HKLM:\SOFTWARE\YourCompany\ComplianceSetting"
if (-not (Test-Path $regPath)) {
New-Item -Path $regPath -Force | Out-Null
}
Set-ItemProperty -Path $regPath -Name "Enabled" -Value 1 -Type DWord
Write-Output "Remediation complete: Registry key set."
exit 0
One important detail: manually executing a policy triggers the remediation code regardless of the evaluation result. Use manual execution with caution, especially for policies that make destructive changes.
What about 64-bit Windows endpoints?
On 64-bit Windows, Worklet scripts run in a 32-bit PowerShell session by default. This means file system and registry access gets redirected:
Registry paths under `HKLM:\SOFTWARE` redirect to `HKLM:\SOFTWARE\Wow6432Node`
File system paths under `C:\Windows\System32` redirect to `C:\Windows\SysWOW64`
To access native 64-bit locations, use the `Sysnative` alias in your scripts:
# Access the native 64-bit System32 directory
$nativePath = "$env:windir\Sysnative"
& "$nativePath\WindowsPowerShell\v1.0\powershell.exe" -Command {
# Your 64-bit commands here
Get-ItemProperty "HKLM:\SOFTWARE\YourKey"
}
Plan for this redirection when your Worklets interact with registry locations or system directories on 64-bit Windows endpoints.
How do you create a Worklet step by step?
Follow these steps to create and configure a Worklet in the Automox console:
Navigate to Policies in the left sidebar and click Create Policy.
Select Worklet as the policy type.
Give the policy a descriptive name that reflects its purpose (for example, "Enforce TLS 1.2 Registry Setting").
Choose the target operating system: Windows, macOS, or Linux.
Enter your evaluation code in the first code block. This script should exit 0 for compliant and non-zero for non-compliant.
Enter your remediation code in the second code block. This script runs when evaluation flags an endpoint.
Optionally upload any files your remediation script needs. Uploaded files download to the script's working directory when remediation runs.
Assign the policy to one or more groups containing the target endpoints.
Set the schedule for when remediation should run (by month, day of week, or week of month).
Save the policy.
After saving, the evaluation code runs automatically during each device scan. Endpoints flagged as non-compliant receive remediation at the scheduled time.
What are common Worklet use cases?
Worklets cover a broad range of endpoint management tasks. According to Gartner, organizations that automate at least 70% of endpoint management tasks reduce operational costs by up to 40% (Gartner, "Reduce IT Operational Costs Through Automation," 2024). Here are categories where Worklets deliver the most value:
Security hardening: Enforce registry settings, disable legacy protocols, configure firewall rules, and ensure encryption is active.
Software management: Uninstall unauthorized applications, verify installed versions, and deploy configuration files.
Compliance auditing: Check for required settings, validate group policy application, and report on endpoint state.
System monitoring: Verify service status, check disk space thresholds, and confirm agent health.
User environment configuration: Set default browser settings, configure proxy settings, and manage local accounts.
For specific Worklet tutorials, see the Automox Worklet automation scripts and workflows overview, which catalogs dozens of ready-to-use scripts.
How do you upload files to a Worklet?
Some remediation tasks require external files, such as configuration files, certificates, or installers. Automox lets you attach files directly to a Worklet policy.
Uploaded files download to the script's current working directory when the remediation code executes. You can then reference them by filename in your script:
# Reference an uploaded certificate file
$certPath = Join-Path $PWD "company-root-ca.cer"
Import-Certificate -FilePath $certPath -CertStoreLocation Cert:\LocalMachine\Root
Write-Output "Certificate imported successfully."
This keeps your Worklets self-contained. The endpoint doesn't need network access to a file share or download server during remediation.
How do you execute Worklets manually?
Automox provides two methods for manual execution when you need to trigger a Worklet outside its regular schedule:
Per device: Open the Device Details page, scroll to the Associated Policies section, and click Run Policy next to the Worklet. This triggers remediation on that single endpoint.
Per policy: Open the policy from the Policies page, then click Execute Policy Now. This triggers remediation on all endpoints in the policy's associated groups.
Both methods bypass the evaluation step and run the remediation code directly. According to Forrester, reducing manual intervention in endpoint management workflows saves IT teams an average of eight hours per week (Forrester, "The Total Economic Impact of Cloud-Native Endpoint Management," 2023).
What should you know before getting started?
Keep these best practices in mind as you build Worklets:
Test in a small group first. Assign new Worklets to a test group before rolling out to production endpoints.
Use descriptive exit messages. Include `Write-Output` or `echo` statements so the Automox console shows meaningful status information.
Handle errors gracefully. Use `try/catch` blocks in PowerShell and error checking in Bash to prevent unexpected failures.
Document your scripts. Add comments explaining what each section does, especially for scripts other team members will maintain.
Version control your Worklets. Use a Git repository to track changes over time. The Worklet Warden approach provides a framework for backup and version management.
Sources
Automox, "Worklet Documentation" - Official documentation for creating and managing Worklet policies.
Gartner, "Reduce IT Operational Costs Through Automation," 2024 - Analysis of cost savings from endpoint management automation.
Forrester, "The Total Economic Impact of Cloud-Native Endpoint Management," 2023 - Study on time savings from automated endpoint workflows.
Automox, "Automox API Documentation" - API reference for programmatic Worklet management.
Frequently asked questions
Worklets run PowerShell on Windows endpoints and Bash on macOS and Linux endpoints. The scripts execute in whatever version of the shell is installed on the target endpoint. You can invoke other scripting languages (Python, Ruby) from within the native script if the interpreter is installed on the endpoint.
Yes. The remediation code can install software using standard command-line methods. You can upload installer files directly to the Worklet policy or download them within the script. For straightforward application deployment, consider using a Required Software policy first, as it doesn't require scripting.
The evaluation code runs every time a device performs a scan. The default scan interval in Automox is every 24 hours, but administrators can configure different scan frequencies for each device group.
If the remediation script encounters an error, the endpoint remains flagged as non-compliant. The next scan triggers the evaluation code again, and if the condition still isn't met, the endpoint stays in the remediation queue for the next scheduled policy run.
Yes. Like all Automox policies, Worklets support scheduling by month, day of week, and week of month. You can also set maintenance windows to control when remediation executes on endpoints.
Yes. You can use the Automox API to export Worklet configurations and store them in a Git repository. The Worklet Warden tool automates this backup process using the Automox Python SDK and GitHub Actions.
Yes. Automox is a cloud-native platform, so endpoints receive policies and execute Worklets as long as they have internet connectivity. No VPN or on-premises infrastructure is required. --- *Related reading:* - Automox Worklet: Uninstall Applications on Windows - Automox Worklet Automation Scripts and Workflows - Patch Management Best Practices - Automated Patching Solutions Compared
)
)
)
)