macOS - Software Lifecycle - Intune Install macOS Updates

What the Intune macOS update trigger does

This Automox Worklet™ installs macOS operating system and security updates by handing the workflow off to Microsoft Intune Declarative Device Management (DDM). The Worklet invokes the Automox WDK binary at /usr/local/bin/wdk with the mdm intune patch subcommand, which authenticates to Microsoft Graph using your Azure App Registration, matches Mac endpoints carrying your Automox patch tag against the devices enrolled in your Intune tenant, and creates or updates a DDM configuration policy that targets a named Azure AD group.

The Worklet reads five parameters: PATCH_TAG (default INTUNE), POLICY_NAME (default "AUTOMOX MANAGED - macOS Update Policy"), AAD_GROUP_NAME, DELAY_DAYS (0 to 90), and INSTALL_TIME in 24-hour local time (default 22:00). Three Automox and Azure secrets are passed in as policy inputs: AX_AUTOMOX_API_KEY, AX_AUTOMOX_ORG_UUID, AX_INTUNE_TENANT_ID, AX_INTUNE_CLIENT_ID, and AX_INTUNE_CLIENT_SECRET. Every Graph call the WDK makes is auditable inside Intune.

On the Mac itself, the DDM policy is the trigger. Intune pushes the declaration to the endpoint over its standard MDM check-in, the macOS DDM channel acknowledges it, and the underlying softwareupdate workflow runs at the INSTALL_TIME you set under the authority of the escrowed Bootstrap Token. The user sees the standard Apple update notification at the deferral cutoff, not an admin password prompt.

Why trigger Apple security updates on a schedule you control

Apple ships kernel and WebKit security fixes on a cadence that does not wait for your maintenance window. A Mac that defers a Rapid Security Response or a 14.x point release for two weeks is two weeks exposed to whatever CVE that release closed. On top of that, softwareupdate -ia on a user's machine routinely fails silently when no Bootstrap Token is escrowed or when the user is mid-session.

The Intune DDM update channel is the path that lands the install reliably on a fleet without an admin sitting in front of each laptop. This Worklet is the wiring between the Automox tag that says "these Macs need the patch" and the Intune policy that actually makes the patch land. Corporate laptops, remote contractor MacBooks on coffee-shop Wi-Fi, and lab Macs that sleep in a backpack all converge on the same patched build by next policy run.

How the Intune macOS update trigger works

1. Evaluation phase: The Worklet runs /usr/local/bin/wdk mdm intune patch with --tag, --policy-name, --delay-days, --install-time, --aad-group-name, and --evaluate. The WDK queries Automox for endpoints carrying PATCH_TAG, queries Microsoft Graph to confirm those same Macs are enrolled in your Intune tenant, and returns exit code 10 when at least one match is found. The wrapper translates exit 10 into exit 1, which flags the endpoint for remediation.

2. Remediation phase: The Worklet runs the same WDK subcommand with --remediate instead of --evaluate. The WDK creates the AAD group if it is missing, syncs the matched Mac membership, and writes the DDM software update declaration on the named configuration policy in Intune using DELAY_DAYS and INSTALL_TIME. Intune pushes the declaration to each Mac, the macOS DDM channel acknowledges it, and softwareupdate runs at the scheduled time under the Bootstrap Token. Output from the WDK is captured into OUTPUT and printed to stdout on success or stderr on failure.

Intune macOS update trigger requirements

• Target Macs enrolled in Microsoft Intune with the IntuneMdmAgent installed and the Bootstrap Token escrowed to MDM (DDM software update declarations require a healthy Bootstrap Token to authorize the install)

• Azure App Registration with Microsoft Graph application permissions Device.Read.All, DeviceManagementConfiguration.ReadWrite.All, DeviceManagementManagedDevices.ReadWrite.All, Group.ReadWrite.All, and GroupMember.ReadWrite.All, with admin consent granted at the tenant level

• Organization secrets configured in the Automox console and added as inputs on the Worklet policy: AX_AUTOMOX_API_KEY, AX_AUTOMOX_ORG_UUID, AX_INTUNE_TENANT_ID, AX_INTUNE_CLIENT_ID, and AX_INTUNE_CLIENT_SECRET (input names must match exactly)

• The Automox WDK installed on the agent at /usr/local/bin/wdk (the script invokes it with AX_AUTOMOX_BASE_URL=https://console.automox.com/api)

• Worklet policy scoped to a single endpoint as documented in the script header; scoping to multiple endpoints may result in unintended behavior because the same Graph writes fire repeatedly

• Configurable parameters in the script: PATCH_TAG (default INTUNE), POLICY_NAME (default AUTOMOX MANAGED - macOS Update Policy), AAD_GROUP_NAME (default matches the policy name), DELAY_DAYS (0 to 90, default 3), INSTALL_TIME (24-hour local time, default 22:00)

Expected state after the Intune update trigger

After the Worklet finishes, the target Azure AD group exists in your tenant with the matched Mac members synced in, and the DDM configuration policy is visible in the Intune admin center under Devices with the deferral and install-time settings drawn from your DELAY_DAYS and INSTALL_TIME parameters. The WDK output captured in the Automox activity log records the policy and group operations, so you can pivot directly into Intune to confirm targeting. The next Automox evaluation reports the endpoint as compliant because the join already matches.

On the Mac, Intune delivers the declaration on its next MDM check-in and softwareupdate runs at INSTALL_TIME under the Bootstrap Token after the deferral elapses. You can verify the install path from a terminal session with sudo softwareupdate --list to see pending updates, profiles status -type bootstraptoken to confirm escrow, and sw_vers -productVersion after the reboot to confirm the new build. The DDM policy keeps enforcing the deferral and install window on every subsequent Apple release until you change the parameters or unassign the policy.