Application-update rollout and rollback

Application updates can affect unattended kiosks, security workstations, or other operational devices. Treat each release as a controlled deployment.

Prepare the release

1. Build the final MSI in the approved pipeline.
2. Sign it with the approved code-signing certificate and timestamp.
3. Test clean install, upgrade, repair, restart, configuration retention, service startup, and uninstall where supported.
4. Upload the immutable package to the production HTTPS location.
5. Compute and independently verify SHA-256.
6. Document prerequisites, minimum current version, downtime, restart, data migration, and rollback.
7. Create the release Disabled with a future or verified publication time.
8. Reopen and review every field and target.

Pilot

1. Use a pilot channel where the client supports it.
2. Target one noncritical DEVICE or controlled SITE.
3. Enable the release.
4. Force or wait for one supported update check.
5. Verify the returned version, URL, hash, mandatory flag, and notes.
6. Verify download, signature, installation, restart, version reporting, health heartbeat, device functions, and rollback.
7. Expand gradually across representative networks, hardware, sites, and current versions.

Promote

Create or enable the stable release only after pilot acceptance. Confirm no newer global or targeted release in the same application/channel will take precedence unexpectedly.

Monitor:

• application version and health reporting;
• download and installation failures;
• device offline duration;
• business workflow success;
• support tickets and provider/network errors;
• update-check responses for multiple current versions and targets.

Pause a rollout

Clear Enabled and save. This prevents future manifest selection, but it cannot stop an MSI already downloaded or an installation already started. Verify with a new client check.

If the package host itself is unsafe or compromised, follow the security incident process in addition to disabling the manifest. Do not silently replace bytes at the same URL because clients may have cached the package and the published hash will no longer match.

Roll back

The manifest service returns only a release whose Version compares newer than the client's Current Version. Publishing an older version normally will not downgrade an already upgraded client.

A rollback therefore requires one of these approved strategies:

• publish a new, numerically higher version containing the reverted application code;
• use a client-supported rollback mechanism outside this manifest workflow;
• manually remediate affected devices under change control.

Test database and configuration backward compatibility before rollback. Disabling or deleting the bad release protects clients that have not selected it; it does not reverse completed installations.

Preserve release evidence

Retain package bytes, hash, signing evidence, build provenance, source commit, release notes, targets, publication window, approval, test results, and affected-device list. Prefer disabling an old release over deleting it until retention requirements and active clients have been reviewed.