Patching Is More
Than Patching

The Full Lifecycle of Enterprise Patch Management

SCCM + Ansible Automation Platform

The Patching Iceberg

  • Install updates on servers
  • Schedule maintenance windows
  • Open change-management tickets
  • Back up systems before patching
  • Drain & order HA cluster nodes
  • Validate post-patch health
  • Roll back on failure
  • Close tickets with evidence

The Real Patch Lifecycle

Open Ticket /
Change Request
➡
Schedule
Off-Hours Window
➡
Pre-Patch
Backup
➡
Drain HA /
Ordered Shutdown
➡
Apply
Patches
➡
Validate
& Test
➡
Restore if
Failed
➡
Close Ticket
w/ Evidence

Each box is a potential point of failure — and a manual step someone has to remember.

Scheduling During Off-Hours

  • Patches must land in approved maintenance windows
  • Different apps, different teams, different windows
  • Time-zone coordination across global infrastructure
  • Weekend / holiday blackout periods
  • Someone has to be awake to press the button…
    …or automation does it for them

Pre-Patch Backups

  • Snapshot VMs, database dumps, config exports
  • Verify the backup actually completed
  • Tag / label backups so you know which patch cycle they belong to
  • Retention policy: how long do we keep the safety net?
A patch without a backup is a one-way door.

HA & Cluster Ordering

You can't just reboot everything at once.

  1. Identify cluster members and current primary
  2. Drain connections from Node A
  3. Patch & reboot Node A
  4. Validate Node A is healthy & rejoin cluster
  5. Repeat for Node B, C, …
  6. Confirm quorum and failover capability restored

Get the order wrong and you take down production.

Restore If It Fails

  • Patch breaks the application — now what?
  • Restore from pre-patch backup / snapshot
  • Re-validate services are running correctly
  • Document why the patch failed (root cause)
  • Update the ticket with rollback evidence
A rollback plan you haven't tested is just a hope.

Opening & Closing Tickets

  • Change Advisory Board (CAB) approval before work starts
  • Ticket must capture: scope, risk, rollback plan, schedule
  • During patching: update ticket with progress
  • After patching: attach evidence of success or rollback
  • Close ticket — audit trail complete
No ticket, no audit trail. No audit trail, no compliance.

How SCCM Handles Patching

What SCCM Does Well

  • Software Update Points — sync patches from Microsoft Update catalog
  • Automatic Deployment Rules (ADR) — approve & deploy patches on a schedule
  • Maintenance Windows — enforce when installs can happen
  • Compliance Reporting — which machines are patched vs. missing
  • Phased Deployments — pilot ring before broad rollout

Where SCCM Stops

  • Windows-centric — Linux / network gear / appliances are out of scope
  • No native pre-patch backup orchestration
  • No HA-aware drain / ordered reboot logic
  • Ticket creation & closure? Manual or separate tool
  • Rollback = re-image or manual restore; not orchestrated
  • Cross-platform workflow stitching is left to you
SCCM excels at deploying Windows patches.
Everything around it is your problem.

Enter Ansible Automation Platform

AAP doesn't replace SCCM. It wraps the whole process.

Before the Patch

  • Open ServiceNow / Jira ticket via API
  • Snapshot VMs (VMware, AWS, Azure)
  • Verify backup success
  • Drain load-balancer pool members

After the Patch

  • Validate application health checks
  • Re-enable nodes in load-balancer
  • Rollback automatically on failure
  • Close ticket with full audit log

AAP + SCCM: Better Together

AAP: Open
Change Ticket
➡
AAP: Snapshot
& Backup
➡
AAP: Drain
HA Node
➡
SCCM: Deploy
Windows Patches
➡
AAP: Validate
& Rejoin
➡
AAP: Close
Ticket

Red = AAP  |  Blue = SCCM

  • AAP orchestrates the entire workflow, calling SCCM for Windows patching
  • AAP handles Linux, network, storage, and cloud resources natively
  • Single pane of glass for the full patch lifecycle

What AAP Adds to the Process

Lifecycle StepSCCM AloneSCCM + AAP
Change ticketManual / separate toolAutomated via API
SchedulingMaintenance windows (Windows)Cross-platform, any schedule
Pre-patch backupNot includedVM snapshots, DB dumps, configs
HA orderingNot includedDrain, patch, rejoin per node
Patch deploymentWindows onlyWindows (via SCCM) + Linux + network
ValidationCompliance scanApp health checks, smoke tests
RollbackManualAutomated restore on failure
Close ticketManualAuto-close with evidence

AAP Workflow Job Template

A single click runs the whole lifecycle:

1. Open Change Request — ServiceNow API call
2. Pre-Patch Snapshot — VMware / cloud provider module
3. Verify Backup — assert snapshot status = complete
4. Drain LB Node — F5 / HAProxy / cloud LB module
5. Patch System — yum/apt (Linux) or trigger SCCM (Windows)
6. Reboot & Validate — wait_for_connection + health check URI
7. Re-enable in LB — add node back to pool
8. Rollback if Failed — revert snapshot, alert on-call
9. Close Ticket — attach job log as evidence

Key Benefits of Adding AAP

  • Consistency — same process every time, no missed steps
  • Cross-platform — Windows, Linux, network, cloud, all in one workflow
  • Off-hours without staff — schedule jobs, go to sleep
  • Audit trail — every action logged, tickets updated automatically
  • Faster rollback — automated restore in minutes, not hours
  • Scale — patch 10 or 10,000 servers with the same workflow

Summary

Patching is not a single step.
It's a workflow with 8+ stages that span multiple tools and teams.

  • SCCM is great at deploying Windows patches
  • AAP orchestrates everything around it — and across platforms
  • Together, they turn a fragile manual process into a
    repeatable, auditable, automated workflow

Questions?

Patching done right means
no one has to be awake at 2 AM.

Red Hat