Removing a patch that caused a problem

Occasionally a patch is the problem. AegisOne supports patch uninstall from the console and the API, dispatched to the endpoint the same way installation is and recorded in the action log the same way.

Before removing anything, establish that the patch is actually implicated. The action log gives you the timing — what was installed on this machine and when — and the health history gives you the behaviour. If the behaviour change predates the install, the patch is not your cause and removing it costs you a day and leaves the real fault in place.

curl -X POST https://<your-console-host>/api/agent/<endpoint_id>/patch/uninstall \
  -H "Authorization: Bearer $AEGISONE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"patch_ids":["<patch_id>"]}'

Remove from one machine first and confirm the symptom resolves before you widen. This is the same discipline as staged rollout and it is skipped more often on the way back than on the way out, because by the time you are rolling back somebody is under pressure.

Removing a security patch reintroduces the exposure it closed. That is sometimes the correct trade — an unusable estate is its own kind of incident — but it should be a decision somebody makes explicitly and records, not a side effect of getting a service running again. Note the decision, the reason and the intended remediation date on the relevant ticket while the reasoning is still fresh.

Halt the wider rollout as soon as you suspect a problem. The most expensive version of this scenario is not the machines you rolled back; it is the four hundred machines that received the patch during the two hours you spent confirming the fault.

Finally, re-scan the affected endpoints after removal. The patch inventory should reflect reality, and reality has just changed.