The old device checks in too

In many tools a rollout counts as done the moment the distribution system reports success. The package went out, the job is green, the list gets shorter. Whether the software actually runs on the device is something nobody has checked. At this point the distribution tool is confirming itself.

The rollout module therefore keeps two status values side by side that are often taken to mean the same thing. Done is set by the technician when they have finished. Verified is set by the system once it has checked the actual state. The first is a statement, the second is evidence.

Checked against data that is already there

Success verification needs no data source of its own. It draws on the connectors already running in the system: ACMP, baramundi, Intune, Wazuh, PRTG, macmon and AssetPanda. Four criteria can be enabled per rollout.

• Contact within days. Did the device check in with a connector after deployment, within the deadline?
• Operating system contains. Does the IT system carry the expected operating system, for example "Windows 11"?
• Software installed. Is the expected software recorded for this host in software inventory?
• Intune compliance. Does Intune report the device as compliant?

The mistake a naive check makes

For the contact criterion, only a contact after the target has been closed out counts. That sounds like a detail, but it is the difference between a check and self-deception. In a notebook replacement there was already a device at that desk, and this old machine had been checking in reliably with every connector for weeks. Anyone who only asks whether there was contact will always find some and wave every target through. So the check runs against the completion timestamp, not against a time window.

Two deliberate asymmetries

In automatic mode a nightly run promotes completed targets that pass all criteria to verified on its own. A failure, by contrast, never demotes. That asymmetry is deliberate: a connector that delivers no data for two days would otherwise invalidate correctly verified targets in batches. What you would end up looking at is the state of the checking infrastructure, not the state of the rollout.

The second asymmetry concerns missing data. If a criterion cannot be evaluated, for instance because the license management module is not active, it does not make the check fail. But if no criterion can be evaluated, the target does not count as passed either. The result stays "not verifiable", and such a target is never verified automatically. Not verifiable is not the same as passed. Only IT system targets are checked in any case, since people, rooms and sites have no technical state.

What the module does not do

It does not distribute. Packages and images remain the job of client management. The rollout module plans deployment in waves, manages each target with its own status and date, records the on-site handover and verifies the result afterwards. In the ITIL chain this is deployment management, directly behind change and release.

Progress is calculated soberly. It counts completed and verified targets. Deliberately excluded targets are marked as skipped and count neither in the numerator nor in the total. A rollout with ten targets, two of them skipped and eight completed, sits at one hundred percent. Not because anything was rounded, but because it stays traceable why the target set got smaller.

More on the rollout management module page.