Windows
View all Worklets
WindowsWindows

Windows - Software Lifecycle - Install M365 Apps

Deploy Microsoft 365 Apps for Enterprise to Windows endpoints with configurable channel, exclusions, and architecture

Worklet Details

What the Microsoft 365 Apps deployer does

This Automox Worklet™ deploys Microsoft 365 Apps for Enterprise to Windows endpoints using the Office Deployment Tool. The Worklet writes an update.xml configuration file from your policy parameters, then runs setup.exe /configure update.xml to download and install the Click-to-Run suite from the Microsoft CDN. The setup payload (the ODT setup.exe) is uploaded to the Worklet once and reused on every run, so the endpoint never needs to fetch the deployment tool itself.

The update.xml file is generated dynamically from four policy variables: channel (Current, MonthlyEnterprise, FirstReleaseCurrent, Deferred, FirstReleaseDeferred, or InsiderFast), excludeApps (a comma-separated list of Office app IDs such as Teams, Groove, Lync, OneDrive), bitness (32 or 64), and visibility (FULL to show the install progress UI or NONE for a silent install). The installation language follows the operating system locale with an EN-US fallback when no match is available. If the OfficeUpdate UpdateBranch policy key exists at HKLM:\SOFTWARE\Policies\Microsoft\Office\16.0\Common\OfficeUpdate, the Worklet uses that channel for the install and logs the override to the Activity Log, so GPO-managed endpoints retain the cadence defined by Group Policy.

Because the Automox agent runs setup.exe outside an interactive user session, the Worklet wraps the install in a scheduled task named "Install M365 Apps" that runs under the USERS account. It registers the task with a registration trigger, polls Get-ScheduledTask until the state returns to Ready, then unregisters the task. This pattern sidesteps Click-to-Run errors that surface when setup.exe is launched directly from a service context, and it keeps the install behavior consistent across Windows 10, Windows 11, and Windows Server SKUs.

Why deploy Microsoft 365 Apps from the catalog

Microsoft 365 Apps for Enterprise is the productivity baseline most organizations require on every Windows endpoint. Manual installs from the user portal can produce inconsistent results: Word and Excel without Teams, Outlook on the wrong update channel, or 32-bit installs on 64-bit hardware. Manual installs also delay onboarding. The Office Deployment Tool fixes the consistency problem when every admin uses the same configuration. This Worklet centralizes that configuration in one policy and applies it across the fleet.

Schedule this Worklet against the standard Windows workstation and server groups; the Click-to-Run registry check evaluates each endpoint, setup.exe deploys Microsoft 365 Apps for Enterprise where the VersionToReport key is missing, and the installed version reports back to the Activity Log. Onboarding and image-refresh gaps close on the policy schedule rather than as one-off help-desk tickets.

How Microsoft 365 Apps deployment works

  1. Evaluation phase: The Worklet reads the VersionToReport value at HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration, using the 64-bit registry view on 64-bit Windows and the 32-bit view on 32-bit Windows. If VersionToReport is present, the endpoint is marked compliant and remediation is skipped. If the value is missing or the ClickToRun configuration key does not exist, the endpoint exits 2 and is flagged for remediation.

  2. Remediation phase: The remediation script writes update.xml from the policy variables, registers a scheduled task that runs setup.exe /configure update.xml from the Worklet payload directory under the USERS account, and polls Get-ScheduledTask until the task state returns to Ready. Once setup.exe exits, the Worklet unregisters the task, re-reads VersionToReport, writes the installed version to the Activity Log, and exits 0 on success. Setup.exe failures surface as exit code 1, and OfficeC2RClient.exe install logs are left at %WINDIR%\Temp for follow-up.

Microsoft 365 Apps deployment requirements

  • Windows 8.1 or later (Windows 10, Windows 11, and Windows Server 2016+ are the supported targets)

  • PowerShell 3.0 or later, with the Automox agent running in its default SYSTEM context

  • Office Deployment Tool (setup.exe) uploaded as the Worklet payload – download the latest ODT from the Office Deployment Tool download page, extract setup.exe, and attach it to the policy

  • Outbound HTTPS connectivity from each endpoint to the Microsoft Office CDN (officecdn.microsoft.com and officecdn.microsoft.com.edgesuite.net)

  • Policy variables set: channel (Current, MonthlyEnterprise, FirstReleaseCurrent, Deferred, FirstReleaseDeferred, or InsiderFast), excludeApps (comma-separated Office app IDs), bitness (32 or 64), and visibility (FULL or NONE)

  • A valid Microsoft 365 license assigned to the signed-in user for activation after install (the Worklet handles deployment; activation happens on first launch)

Expected Microsoft 365 state after deployment

After a successful run, Microsoft 365 Apps for Enterprise appears under Apps and Features in Windows Settings and on the Start menu. Word, Excel, Outlook, PowerPoint, and the other suite apps you did not exclude are ready for activation on first launch. The Worklet writes the installed Click-to-Run version to the Automox Activity Log so the policy run is auditable, and it leaves the OfficeC2RClient.exe and setup.exe install logs at %WINDIR%\Temp\ if a follow-up is needed.

Subsequent runs of the Worklet read the existing VersionToReport registry value and exit without re-running setup, so the policy can sit on the same weekly schedule as your patch policy. To validate manually, open a PowerShell prompt and read the Click-to-Run version with Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration' VersionToReport, or run "C:\Program Files\Common Files\Microsoft Shared\ClickToRun\OfficeC2RClient.exe" /update user to confirm the channel and trigger an update check. To change the update channel after deployment, update the channel variable on the policy and re-run. On endpoints where the OfficeUpdate UpdateBranch policy key is set, the Worklet defers to the GPO value for the install channel and logs the override.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's 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. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets