Before you begin
- Atlas Reach enabled for the tenant, with the Atlas Reach agent installed on your devices
- The Software Deployment setting turned on for the devices' scope in Settings → Configuration Matrix (it is on by default)
- The reach.deploy permission to deploy software and to edit the catalog, the required apps and the Exe allow-list; reach.view is enough to read them
Where to find it
- Atlas Reach → Devices: the toolbar has App catalog, Required apps and Exe allow-list.
- On a device: the Deploy action ("Install, uninstall or upgrade software…") opens Deploy software for that device.
- Atlas Reach → Software: the fleet-wide Software Inventory, Updates and Winget History views.
- A device's Software tab: what is installed on that one device, with its update status.
Step 1: Build the app catalog
The app catalog is the list of software your team deploys. Each entry names the install mechanism and the package, so technicians pick from a list instead of typing package ids. Open Atlas Reach → Devices → App catalog and click Add entry.
- Enter a name, for example Google Chrome.
- Choose the mechanism. Windows: winget, MSI, Chocolatey or Installer (.exe). macOS: Homebrew or macOS package (.pkg). Linux: apt or dnf.
- For a package manager, enter the package id. For winget you can search by name or id and pick the match.
- For a file-based installer (MSI, .pkg or .exe), enter an https:// source URL and the package's 64-character SHA-256. The download is checked against the hash before it runs, so every catalog deploy is pinned to the exact file you approved.
- Optionally set a version pin and notes (why it is in the catalog, licensing caveats, who to ask).
- Click Add to catalog.
A catalog holds up to 500 entries. Removing an entry does not uninstall the software anywhere; it only stops being offered when you deploy. You can also save a package to the catalog straight from a winget search in the Deploy dialog.
Step 2: Allow-list .exe install arguments
A generic .exe installer runs as LocalSystem, so Atlas Reach only lets it run with silent-install switches you have approved. Open Exe allow-list from the Devices toolbar and add each argument string your installers use, for example /VERYSILENT /NORESTART for an Inno Setup installer, with an optional label.
- Arguments are matched exactly as entered.
- Add an empty entry to permit a silent install with no switches.
- Until at least one string is allow-listed, you cannot save an .exe catalog entry or deploy an .exe, and required-app enforcement cannot install one.
- Removing a string stops catalog entries and deploys that use it from being accepted until you add it back.
Step 3: Deploy software to a device
Open a device and choose Deploy. Pick an entry under From the app catalog to fill in the form, or fill it in yourself.
- Choose the action: Install, Uninstall or Upgrade. For Upgrade, leave the package blank to upgrade every package the package manager can update.
- Check the mechanism and the package, and optionally a version (the latest is used if blank) and a timeout.
- Click Deploy. The output, the exit code and any errors appear in the dialog once the device finishes.
Deploys run on the device as LocalSystem (root on Linux and macOS; Homebrew runs as the user who owns it) and every deploy is recorded in the audit log. If you pick a mechanism the device's operating system cannot run, Atlas warns you and the agent refuses it.
Step 4: Mark apps as required
Required apps say which catalog apps a set of devices must have. Open Required apps from the Devices toolbar.
- Choose the Catalog app. A requirement always points at a catalog entry, so add the app to the catalog first.
- Choose the Scope: Tenant (every device), Host pool, or Device, and pick the pool or device.
- Leave Auto-install when missing on to have Atlas install the app on devices that do not have it. Turn it off to report compliance only.
- Optionally turn on Only during a maintenance window, so the install waits for a maintenance window that covers the device's host pool.
- Click Add requirement.
- Auto-install: the app is installed on the device's next check-in.
- Auto-install · in window: the app is installed only while a maintenance window is open for the device's host pool.
- Report only: missing devices show as non-compliant, and nothing is installed.
A device's required apps are everything required at the tenant, at its host pool and on the device itself. When the same app is required at more than one scope, it is auto-installed if any requirement asks for it, and kept to a maintenance window if any requirement asks for that. Removing a requirement never uninstalls the app; it just stops being required at that scope.
Check a device's compliance
At the bottom of Required apps, under Check a device's compliance, choose a device. Atlas compares the device's required apps with the software it last reported and shows Compliant, or how many apps are missing, with a count such as 4 / 5 installed.
A pinned version is reported alongside the installed one, but on its own a different version does not make a device non-compliant. Compliance is about the app being installed.
How enforcement works
- A missing auto-install app is installed on the device's next check-in. An offline device is picked up when it reconnects.
- Enforcement uses the same software-deploy path, permissions checks and Exe allow-list as a manual deploy, and each install is recorded in the audit log.
- After each attempt, Atlas waits 12 hours before trying the same app on the same device again, giving the install time to finish and the inventory time to catch up.
- After 5 attempts without the app appearing in the device's inventory, enforcement gives up on that app for that device. Once the app shows as installed, the count resets, so a later removal is enforced again from the start.
If an app keeps failing, deploy it by hand from the device's Deploy action to see the installer's output and exit code, fix the cause (often a bad URL, a changed SHA-256 or a missing allow-listed argument), then let enforcement take over again.
See what is installed
Atlas Reach → Software shows the software on every device. Software Inventory lists each application with its publisher, versions and device count; Updates lists the winget updates your devices report; Winget History shows Winget-AutoUpdate runs with the previous and new versions and the result. Each device's own Software tab shows the same for that device.
Winget History needs the Windows Atlas Reach agent 1.0.116 or later.
Not the same as host pool app deployment
This article covers Atlas Reach devices. Installing winget apps, browser extensions and bookmarks on Azure Virtual Desktop session hosts when they are provisioned is a separate feature with its own article, Deploy Apps, Extensions & Bookmarks, in the Host Pools section of the Support Center.
Troubleshooting
- App catalog, Required apps or Exe allow-list are read-only: your role has reach.view but not reach.deploy. Ask an administrator.
- Deploy is not offered, or a deploy is refused: check that Software Deployment (and Toolbox Elevated Actions, which it depends on) is on for the device's scope in the Configuration Matrix, and that the device is approved and online.
- You cannot save an .exe entry: allow-list the installer's silent switches on the Exe allow-list first.
- A required app never installs: check that Auto-install is on, that a maintenance window is open if the requirement is window-only, and whether it has reached the 5-attempt limit.
- A device shows an app as missing right after it installed: the inventory has not refreshed yet. The 12-hour wait stops Atlas installing it again in the meantime.