Skip to main content

To make it easier for Automox users to learn about Worklet™️ automation scripts and how they can make your life easier – we’ve constructed another fun challenge! It’s an easy way to get started with Worklets and win a fantastic, limited-edition Lego Otto set! 

So, what is a Worklet? A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklet automation scripts perform configuration, remediation, and the installation or removal of applications and settings across Windows, macOS, and Linux.

Now, what’s the challenge? 

⭐️ Step 1: Click through this Worklet demo to discover how easy it is to run and verify a Worklet (it only takes a few minutes).

⭐️ Step 2: Execute your own Worklet automation script. 

It can be as simple as getting the reboot history for a remote computer or installing the SentinelOne agent on all your Mac devices. Explore the Worklet catalog to choose from hundreds of Worklet automation scripts to execute! You can also browse community-created Worklets here and try one out! There are some real gems that will make your life a lot easier! 

⭐️ Step 3: Share a screenshot of your successfully executed Worklet in the Automox Community (just drop a comment below).

 

Every month, we’ll give away limited edition Lego Otto sets to participants! How cool are these?! 

So get to it! 

Other Resources on Worklets

The Automox University is your go-to training ground for all things Automox and Worklets! There are over 40 snackable training courses and certificates you can earn! Here are some Worklet-focused courses we recommend: 

Let’s Go!!! Can’t wait to see what you all come up with. 


Wi-fi Network Adapter Info:

 

Script: 

Output 

 


Here’s a uesfull worklet I have created, this worklet ensures that no users have admin level access on there workstations. We do have service accounts such as domain admin etc that can remain there, it will remove any users that are not listed.

 

 


pretty cool!


I have to share since Ivanti was called out on the Automox website when we first started to look for a new patch deployment tool 🙂.  

We needed something to begin the removal process.

Script to remove the Ivanti Scheduling services and clean up the ProPatches directory.  

 


Hi Folks,

Thought this worklet might help people as well. I created this worklet to enroll all company managed devices to enroll in Intune and add in Azure AD. it will save you ton of time for enrollment process if you are migrating from tenant to tenant in Azure or just onboarding with your Azure tenant.

I havent got a chance to trim it but you could add evaluation script like below. In my script i just skipped evaluation part with exit code 1.

(Note: You need to create provisioning package for Azure/Intune to deploy it through Automox. Refer to this link for how to create provisioning package: https://techcommunity.microsoft.com/t5/intune-customer-success/bulk-join-a-windows-device-to-azure-ad-and-microsoft-endpoint/ba-p/2381400)

 Evaluation Script: 

# Check if the device is Azure AD joined
$azureAdStatus = dsregcmd /status
$azureAdJoined = $azureAdStatus | Select-String "AzureAdJoined" | ForEach-Object { $_.Line -match "AzureAdJoined\s*:\s*(\S+)" ; $matches$1] }

# Check if the device is enrolled in Intune by looking for the Intune certificate
$intuneCertificatePath = "Cert:\LocalMachine\My"
$intuneCertificate = Get-ChildItem -Path $intuneCertificatePath | Where-Object { $_.Issuer -like "*Intune*" -or $_.Subject -like "*Intune*" }
if ($azureAdJoined -eq "YES" -and $intuneCertificate) {
    Write-Output "Device is enrolled in Azure AD and Intune."
    exit 0
} else {
    Write-Output "Device is not enrolled in Azure AD or Intune."
    exit 1
}

 

 Remediation Script: 

# Define the local path to the provisioning package
$ppkgPath = "testIntune.ppkg"

# Check if the provisioning package file exists
if (Test-Path -Path $ppkgPath) {
    try {
        # Apply the provisioning package silently without restarting
        Add-ProvisioningPackage -Path $ppkgPath -Quiet -ErrorAction Stop
        Write-Output "Provisioning package applied successfully."
    } catch {
        Write-Error "Failed to apply the provisioning package. Error: $_"
    }
} else {
    Write-Error "Provisioning package not found at $ppkgPath."
}

 

Script
Output1
Output2
Output3

More than happy to trim this worklet for couple of likes lol. 😏


A little something I threw together to find out the age of our MacOS computers so we know which computer to start replacing.

Because we want to run it against all MacOS computers.
 

 


A little something I threw together to find out the age of our MacOS computers so we know which computer to start replacing.

 

SO helpful to stay ahead of things! Thanks for sharing @slammert! Sending you a DM so we can get you a Lego Otto set! 


I use the “Windows - Enterprise Branding - Set Desktop Background for All Users” to set the Wallpaper for our Manager PCs.  Works pretty well and helps us standardize across 500+ devices.  I like being able to go to remote to any device in that group and see the same Wallpaper across each device.  It helps to see the Wallpaper as I am a heavy multitasker!

 

 

 


Reply