5. Shipping agent updates

Owner: IT Prerequisite: Steps 1-4 are complete - the initial Arbium pilot rollout is live and the smoke test came back green.

When the Arbium team ships a new agent version (e.g. Roots.msi v0.1.15.0), the existing Intune LOB app entry from Step 3 is updated in place. Devices auto-upgrade on next sync via Windows Installer’s MajorUpgrade machinery — no re-enrollment, no per-device touch.

This page is the steady-state operational flow for that update cycle. Backend updates (new chart version, new images) are Cloud Ops’s responsibility and roll out independently — see Cloud Ops Step 3 - Upgrading the chart. IT does not redeploy anything when the backend is upgraded; agents reconnect against the same endpoint. The Admin UI is part of the backend chart, so admin upgrades also need no action from IT.

What we send for an update

• The new MSI: Roots.msi (one per architecture: x64 and arm64)

The MSI’s UpgradeCode is stable across versions (that’s what Windows Installer uses to recognize “same app, different version”). The ProductCode is regenerated per build, but LOB MSI deployment handles this automatically — no manual ProductCode tracking.

Update the LOB app in Intune

1. Apps > Windows > Roots (the LOB app entry created in Step 3).
2. Properties > App information > Edit.
3. Click the file picker next to the app package file and upload the new Roots.msi.
4. Intune auto-reads the new version from the MSI. Confirm it shows the expected version.
5. Review + save.

Repeat for each architecture (x64 and arm64) if you have separate LOB app entries.

What happens on the device

On next device sync, Intune detects the version bump and pushes the new MSI:

1. The MSI’s util:CloseApplication terminates the running Roots.exe.
2. Windows Installer’s MajorUpgrade removes the old version and installs the new one.
3. The MSI triggers schtasks /run /tn "Roots" to restart the agent via the per-user scheduled task — the process starts in the logged-in user’s interactive session.

If no user is logged in when the update lands, the restart silently skips and the logon task starts the agent on next sign-in.

Update the config script (only if needed)

For pure binary updates, no script change is needed — skip this section.

If the new version changes the config schema (e.g. adds a new key) or the values themselves change (different endpoint, different Entra tenant), update the platform script:

1. Devices > Scripts and remediations > Platform scripts > Roots windows - write config.json.
2. Properties > Script settings > Edit.
3. Re-upload the updated Set-RootsConfig.ps1 (regenerated with new values — see the config-script block in Step 2).
4. Keep all run-time settings the same (run as SYSTEM, 64-bit host, no signature check).
5. Save.

On the next device sync, Intune re-runs the script, rewrites config.json, and the agent picks up changes via reloadOnChange — no agent restart needed.

Force-deploy to a canary device

Devices auto-upgrade on their next sync (~8h default cycle). To validate immediately on one canary first, on the target Windows device:

• Settings > Accounts > Access work or school > click the work account > Info > Sync.

Within ~5 minutes Intune downloads the new MSI and runs it silently. The agent is killed, upgraded, and restarted automatically.

Verify on the canary

Same checks as Step 4 smoke test, plus a version comparison:

(Get-Item "C:\Program Files\Roots\Roots.exe").VersionInfo.FileVersion
# Expect: the new version (e.g. 0.1.15.0)

Get-Process Roots | Format-Table Id, StartTime
# StartTime should be within the last few minutes

In Sentry Logs, filter by the new release (e.g. release:roots-win@0.1.15.0) and confirm status.type: ready + status.type: upload entries appear.

If the version shows the old value, the device hasn’t picked up the new policy yet. Force a second sync, or check Devices > <device> > Managed apps in Intune for the install status of the Roots app.

After the canary is green, the wider device group auto-upgrades on its natural sync cadence. No further action.

Roll back

To revert to a prior agent version: re-upload that version’s .msi to the same LOB app entry.

The MSI’s MajorUpgrade element rejects downgrades by default (A newer version of Roots is already installed), so a rollback requires either:

1. Uninstall first, then re-install the older version. Switch the Intune assignment to Uninstall, sync the canary, confirm Roots is gone, then switch back to Required after uploading the older MSI.
2. Sequence-bump the older code: ship the prior code with a new (higher) version number. Cleaner from Intune’s perspective but requires a fresh build.

Path 1 is simpler operationally. Ping the Arbium team if you need to coordinate a rollback — we can confirm which approach fits your deployment.

Done

The pipeline self-heals from here. Monitor Sentry for runtime errors from the fleet, and check the backend public.captures table for ongoing health.