Patching a Cluster With a Hard Maintenance Window
Adventure Works runs a four-node Hyper-V failover cluster on Windows Server 2022 hosting 120 VMs. Management requires that no VM be down for more than 30 seconds and that patching complete within a six-hour window on Saturday night.
Current practice is manual: an administrator drains a node, patches it, restarts it, and moves to the next. The last cycle took 14 hours because two nodes required multiple restarts and one VM repeatedly failed to live migrate, blocking the drain. The VM that blocked migration is a large SQL Server VM with 96 GB of assigned memory and a 2 TB VHDX on a CSV. Live migration of that VM takes about 11 minutes.
A proposal is to enable Cluster Operating System Rolling Upgrade and patch all nodes in parallel to fit the window. Security requires that critical patches be applied within 7 days of release, and the team wants evidence that patching actually completed on every node.
1. Assess whether parallel patching fits the constraints, and design a sequence that meets the 30-second and six-hour requirements.
Read the worked answer
Parallel patching does not fit. Patching all four nodes at once removes the cluster's ability to keep VMs running; VMs would be stopped, violating the 30-second requirement. Even patching two at a time risks quorum loss and leaves no node to absorb the 96 GB VM.
Sequence that fits.
- Pre-stage. Download and stage updates on all nodes before the window. Verify cluster validation and that no node is already in a degraded state. Confirm CSV ownership and that the SQL VM's preferred owner is set to a node that will be patched last.
- Drain and patch one node at a time. Use
Suspend-ClusterNode -Drainso VMs move before the node restarts. Patch, restart, and confirm the node rejoins and its VMs are healthy before moving on. - Budget the time. Four nodes with one restart each is roughly four cycles. The 11-minute live migration of the SQL VM happens once if its preferred owner is set correctly and it is not migrated repeatedly. With staging done in advance, a four-node cycle fits in six hours if each node's patch-and-restart is under about 45 minutes.
- Handle the SQL VM explicitly. Set its preferred owner to the last node patched so it migrates once. If live migration is too slow or fails, use quick migration during that node's drain, accepting a brief VM pause - but verify the pause stays under 30 seconds, which for a 96 GB VM may require reducing assigned memory or using a faster migration path (compression or SMB).
- Verify. After each node, confirm it is Up and its VMs are Running. At the end, collect patch compliance from every node.
On the 30-second requirement. Live migration of the SQL VM at 11 minutes does not violate it - the VM stays running during live migration. The risk is a failed migration forcing a quick migration or a stop. Test the migration in advance.
2. The proposal mentions Cluster OS Rolling Upgrade. Explain whether it helps here and what it does and does not provide.
Read the worked answer
What it provides. Cluster OS Rolling Upgrade allows a cluster to run nodes on different Windows Server versions during an upgrade - for example, moving a Windows Server 2016 cluster to 2019 node by node - so the cluster stays online throughout. It is the supported mechanism for a version upgrade without downtime.
What it does not provide. It is not a patching mechanism. It does not apply monthly cumulative updates, it does not schedule patching, and it does not run nodes in parallel. Enabling it will not shorten the six-hour window or make parallel patching safe. For monthly patching, the relevant tools are Cluster-Aware Updating (CAU) with a maintenance window, or a patching orchestrator that drains nodes one at a time.
Where it could still matter. If the team is also planning a version upgrade, Rolling Upgrade is the right vehicle and should be done as a separate change, not combined with monthly patching. Combining them makes failures harder to attribute and lengthens the window.
Recommendation. Use CAU with a run profile that drains and patches one node at a time, scheduled inside the Saturday window, with pre-staged updates. Use Rolling Upgrade only for the version upgrade, in its own window. For the evidence requirement, have CAU report per-node results and export them, and cross-check with Get-HotFix or the update history on each node after the run.
Judgement. The proposal conflates two different features because both involve clusters and updates. The exam-relevant distinction is that Rolling Upgrade changes what versions can coexist; CAU changes when and how updates are applied.