Skip to main content

Windows Updates That Need Special Handling

Most Windows updates follow a predictable pattern: TridentStack Control installs them, the endpoint's OS build or installed-update list changes, and the platform confirms the update applied. A small set of updates published by Microsoft does not follow that pattern. Some leave no record that can be checked from outside the endpoint. Some cannot be installed by any remote management tool at all.

Every patch management product faces these same updates. The difference is whether the product tells you the truth about them. This page explains what TridentStack Control does with them, what you will see in the product, and what it means for your patching numbers.

You are probably reading this because an endpoint's history showed Installed, not verified, an update health notice said an update needs hands-on installation, or you are deciding whether to block an update for your organization.

Updates that cannot be verified remotely​

After installing an update, TridentStack Control confirms the result by re-checking the endpoint: the OS build advances, or the update appears in the endpoint's installed-update list. For a small set of updates, Microsoft provides no way to make that check from outside the endpoint. The update runs, the installer reports that it finished, and the endpoint looks exactly as it did before.

The Windows Malicious Software Removal Tool (KB890830) is the best-known example. Microsoft re-releases it every month under the same KB number, it runs as a one-time scan rather than installing a component, and Windows keeps no installation record that a management tool can read to prove the current month's version ran.

When this happens, the endpoint's history shows the update as Installed, not verified rather than Success or Failed. The update installed without error, but Microsoft does not provide a way to confirm it applied from outside the endpoint, so reporting Success would claim something the platform cannot prove, and reporting Failed would be wrong: nothing failed. TridentStack Control does not treat this outcome as a failure. A product enhancement to verify these updates directly is in development.

Updates that require hands-on installation​

A few updates cannot be installed by any remote, unattended process. This is a property of the updates themselves, not of the tool pushing them:

  • The Windows Security platform update (KB5007651) must be installed in an interactive administrator session. Microsoft's own guidance says to run it as an administrator. Pushed remotely, the installer exits without error but the update does not apply, and it keeps showing as needed until it is installed by hand.
  • The Secure Boot DBX security update (KB5012170) can require firmware-level steps that only someone at the machine can complete.

TridentStack Control refuses to install these updates automatically rather than pretending it can. Sending the install would produce a success report with no update behind it, which is worse than an honest refusal. In practice this means:

  • Automatic deployments and update policies skip these updates and record why.
  • One-click and fleet-wide remediation is not offered for them.
  • The endpoint's Update Health reads Action recommended and lists a notice naming the updates and what they need, so the work is visible instead of silently skipped.

To resolve one, install it by hand in an administrator session on the endpoint, following the instructions in Microsoft's KB article, during your normal maintenance. Once it is installed, TridentStack Control picks up the change from what the endpoint reports and clears the update from the missing list.

Blocking an update for your organization​

Sometimes an update is fine for most organizations and wrong for yours: it breaks a line-of-business application, a vendor has told you to hold it, or you are waiting on a fix. You can block a specific update so TridentStack Control never installs it on your endpoints.

Blocked updates are managed on the System Update Policies page, under Blocked updates. Add the update's KB number and a short reason. The reason is required, and it is shown to your team everywhere the update is refused, so whoever finds it later knows why.

Once an update is blocked:

  • No install path sends it. Deployment rings, scheduled policies, bulk installs, and one-click vulnerability remediation all skip it.
  • Installs that were queued but had not started yet are cancelled. An install already running on an endpoint is left to finish rather than interrupted partway.
  • Anywhere the update would normally be offered, it is labeled as blocked by your organization, with your reason.
  • It stops counting toward your compliance and health numbers, so the block does not read as a failure.

To unblock, remove the entry. Endpoints that still need the update begin receiving it again through your normal policies and rings, with no further action.

Blocking is a deliberate choice to stay unpatched for that update. It does not remove the underlying risk, so treat a block as temporary and review it when the reason for it goes away.

How these updates affect your compliance and health numbers​

They do not count against you.

  • An Installed, not verified outcome is not a failure. It does not lower the endpoint's health or compliance scores, does not mark a deployment as failed, and does not pause a deployment ring.
  • An update that needs hands-on installation shows the endpoint as Action recommended in Update Health. That is work to schedule, not a fault: it does not lower the endpoint's health or compliance scores, it never stops the endpoint's other updates from installing, and it never causes an update run to be reported as failed. You can dismiss the notice from the endpoint's Update Health if you have decided not to act on it.
  • If you block an update for your organization, TridentStack Control stops sending it immediately: new deployments skip it and queued installs for it are cancelled, though an install already running on an endpoint is left to finish. A blocked update is treated as a decision, not a defect, so it is never counted as a failure. Blocking does mean those endpoints stay unpatched for that update until you unblock it, and it stays that way by your choice.

TridentStack Control keeps these updates visible where they are relevant, so "does not count against you" never turns into "hidden from you".