Not clean, just unknown
A patch report usually knows two states: patched or gap. The third one is missing and quietly gets counted as the first: devices that were never surveyed. Why that deserves a field of its own, and what follows for distribution.
Patch reports are remarkably reassuring. Ninety-eight percent green, two percent open, a list to work through. What the number does not answer is the question behind it: how many devices are in those ninety-eight percent because they are actually patched, and how many because they were never asked?
A device that has reported nothing for six weeks does not show up as a problem in most reports. It does not show up at all.
Three states, not two
So the module does not treat patch level as a yes-or-no question. It knows three answers: update installed, update missing, never surveyed. The third state has a field of its own holding the time of the last survey. If it is empty, that does not mean “fine”, it means “unknown”.
The code carries the sentence that makes the difference: a device without a survey is not clean, it is unknown. It sounds like a detail. It decides whether a metric is a statement or a comfort.
The survey itself is read-only and runs as an ordinary scheduled job, not through the signed order channel that carries every changing action. It changes nothing, so it needs neither a signature nor an approval. There is an operational argument on top: every agent has only a few slots for open orders, and a pure survey order would have taken one of them.
Two lists that behave differently
The catalog of known updates is merged, the per-device inventory is replaced. The reason: a missing update disappears from a device's report as soon as it is installed, regardless of who installed it. The user clicks Windows Update themselves, an administrator runs an upgrade by hand, another tool steps in. In none of those cases does the platform receive an event. If the inventory were merged, the old row would remain and the device would look unpatched forever.
Conversely the catalog must not shrink on every run: a cycle in which no device happens to report a given update must not drag a permanent decision down with it.
And those decisions live elsewhere
Which updates may be rolled out is deliberately not stored on the catalog but in a table of its own. The catalog is written by machines on every scan, the approvals by humans only. One overly broad write, and a permanent exclusion decision is gone without anyone noticing.
The same separation carries the evidence trail. The catalog is not audit-logged, because a machine finding is not evidence and one entry per scan would be a flood. The approvals are. What has to be provable is the human decision: that an update was deliberately excluded in March, with a reason and with a name.
When an approval applies
It is evaluated not when the rollout is planned but every time an order is built. The difference becomes visible over the course of a morning: an approval withdrawn at nine is out of every order minutes later. Were it checked at planning time, a rollout submitted on Monday would still be shipping updates on Friday that were excluded on Wednesday.
Two brakes before every rollout
Software distribution is the most powerful tool in client operations, and therefore the most dangerous: without a brake, a faulty package would be on the entire fleet within a single polling cycle. So a rollout runs in rings, each with a soak time and an abort threshold, the next starting only once the previous survives both. Plus maintenance windows, outside of which no order is created at all.
Finally the patch backlog lands as a number on the IT system so rules like “backlog over thirty days” can be expressed without a special path. With the caveat the code puts right next to it: that number is a display, not the truth.
More on the client management module page.
Questions about this update?
Talk to us – we are happy to show you this feature in a demo.