Ad-Hoc Patch Deployment

Use this playbook to handle ad-hoc (one-off) patch deployments for specific hosts or small scopes outside the regular monthly cadence.

Use Cases

Typical use cases include:

• Applying a targeted fix to a small number of instances when waiting for the next scheduled cycle is not acceptable.
• Validating a vendor hotfix in a lower environment before incorporating it into a broader baseline.
• Addressing an operational issue that requires a specific package version on a subset of systems.

Procedure

1. Confirm scope and risk.

   • Identify the exact hosts in CMDB (for example, by application, environment, or tags).
   • Confirm with application owners that the change is acceptable and whether any additional testing is required.
   • Check for existing exceptions or baselines that might already cover or intentionally exclude the package.

2. Decide how to deliver the patch.

   Work with Cloudaware to choose an approach:

   • Extend or clone an existing baseline to include the required package(s) and run a small, targeted job.
   • Use a dedicated ad-hoc baseline that only contains the specific fix.
   • For Linux, where appropriate, consider using package-level tools (for example, yum-versionlock) to temporarily pin or exclude packages while you validate behavior.

   All ad-hoc work should still be executed via Cloudaware Patch Management rather than manual shell commands on hosts.

   For the UpToDate tag, note that some instances may have never been patched and need to be brought up to the latest patch level outside the regular schedule.

   • Accounts that require ad-hoc patching should be identified in advance.
   • For such instances, set the tag cloudaware:PatchingMaintenance to the value UpToDate.

   Instances tagged this way will be patched to the latest available patches for their platform during ad-hoc maintenance. If a reboot is required by the patches applied, the instance will be rebooted immediately as part of that maintenance.

   To include this instance in scheduled patching activities going forward, remove the value UpToDate from the cloudaware:PatchingMaintenance tag so it can be handled by the normal Patch Management baselines and schedules.

3. Align with change and maintenance policies.

   • Ensure the ad-hoc job is linked to the appropriate Change Management record.
   • Schedule execution within defined maintenance windows.
   • Notify affected teams using your standard notifications and collaboration channels.

4. Execute and verify.

   • Run a canary on one or a few low-risk hosts first and validate:
     • Package version changes as expected.
     • Application and service health remain acceptable.
   • Expand to the full scoped set of hosts once the canary is successful.
   • Perform post-patch verification, including vulnerability re-scans if the ad-hoc patch closes a specific finding.

5. Roll back and follow up.

   • Be prepared to use documented rollback procedures if the ad-hoc change causes issues.
   • Decide whether the ad-hoc patch should be rolled into a standard baseline for future cycles or treated as a one-time exception.
   • Update any related exceptions and compliance documentation to reflect the change.