Cluster Aware Updating: Runbook, Audit Trail, and What Nobody Documents
Cluster Aware Updating (CAU) has existed since Windows Server 2012 and most organisations use it. Or more accurately: CAU is configured, a role exists, a schedule is set, and nobody looks at it anymore. Until the moment Microsoft Support during an incident asks for the CAU report of the last three months, and it turns out there is no audit trail, the runbook is not documented anywhere, and the ops team does not know which mode is actually active.
In the Hyper-V Cluster Health Checks we run, CAU is nearly always a finding. Not because patches are not being applied, that usually happens. But because operational governance around CAU is missing, and that is exactly what makes the difference during an escalated Sev-1 incident where Microsoft support quality depends on what you can prove.
This article is about CAU runbooks, audit trails, and the practical decisions you take upfront so patching stays a professional operation rather than a monthly hope nothing goes wrong.
- The two CAU modes and what they actually mean
- What a CAU runbook needs to contain
- The audit trail that is missing
- Self-updating vs remote-updating, an honest trade-off
- Pre-update and post-update tasks that matter
- CAU on Windows Server 2025, what changes
- Three common governance gaps
- The CloudLabs CAU readiness report
1. The two CAU modes and what they actually mean
Cluster Aware Updating has two operational modes, and the choice between them is a strategic decision affecting runbook, audit trail, and supportability.
Self-updating mode. The cluster itself orchestrates the update run. One cluster node is the coordinator, drains the other nodes in turn, patches them, brings them back. The cluster has a configured CAU role, a built-in schedule, and the cluster role itself must have sufficient rights to query Windows Update or WSUS.
Remote-updating mode. An external orchestrator (a management server, a script host, or a manual operator) starts the CAU run through Invoke-CauRun. The cluster itself has no configured CAU role. Every update cycle is explicitly triggered from a documented patch window.
Which is "better"?
It depends on your operational model. Self-updating is set-and-forget, scales well across many clusters, and fits organisations that want full automation. Remote-updating gives explicit control per cycle, fits organisations with strict change management, and is what we see more often at customers with compliance requirements mandating human approval per patch cycle.
What CloudLabs finds in Health Checks:
A surprising number of customers think they run self-updating, but the cluster role no longer exists or sits in a degraded state. Someone tried remote-updating years ago, wrote a script, and disabled the self-updating role. The script still runs, but nobody documented the transition. Result: a patch cycle that looks like self-updating, but actually depends on a forgotten scheduled task on a management server that will be decommissioned in six months.
Detecting what is actually running:
# Check whether a CAU clustered role exists
Get-ClusterGroup | Where-Object {$_.GroupType -eq 'ClusterAwareUpdating'}
# Detail of the CAU resource
Get-CauClusterRole -ClusterName $cluster
# Recent runs (last 5)
Get-CauReport -ClusterName $cluster -Last 5No output here means you are running remote-updating (or nothing at all). Absence of the cluster role is not by itself wrong, provided a documented remote-updating process exists. Without that process, it is a finding.
2. What a CAU runbook needs to contain
A CAU runbook is not optional documentation, it is operational infrastructure. In CloudLabs remediation engagements we require as standard that the following sections exist and stay current.
- Section 1, the mode. Self-updating or remote-updating, explicitly described, with the reason this mode was chosen.
- Section 2, the schedule. When does a CAU run happen, with what frequency, in which maintenance window, and what is the fallback if the window is missed.
- Section 3, the update source. Windows Update direct, WSUS, SCCM, or Azure Update Manager. Including the URL or server, and the service account the cluster uses for authentication.
- Section 4, pre-update tasks. What must be checked before each run, scripted or manual. For example: cluster validation, no existing paused nodes, no active incidents.
- Section 5, post-update tasks. What must be checked after each run. CSV ownership rebalance, time service sync verification,
Test-Clusterrun, alert on new firmware drift. - Section 6, escalation path. What to do if a node does not rejoin correctly, if a patch fails, or if a VM does not migrate correctly during drain. Who gets called, on which number, with what information package.
- Section 7, rollback. What is the rollback process if a patch causes a regression. Which maintenance window is needed for that, and which decision criteria trigger rollback.
- Section 8, audit location. Where are CAU reports archived, with what retention, and who has access. Under 90 days retention is structurally too short if Microsoft Support wants to look three months back.
We deliver this runbook as a template with a Health Check remediation, filled in for the specific customer environment. The template itself is generic, the filling-in is what takes time and creates the value.
3. The audit trail that is missing
The most common finding around CAU is not "patches are missing". It is "there is no evidence which patches were applied at which moment on which node".
What a good audit trail contains:
Per CAU run the full report: which nodes were patched, which KB numbers, how long each took, which failed, which required a reboot. Microsoft provides Get-CauReport for this purpose, but the output rarely gets archived.
# Full report of the last run, to XML for archiving
$report = Get-CauReport -ClusterName $cluster -Last 1
$report | Export-Clixml -Path "C:\Audit\CAU\$($cluster)_$(Get-Date -Format 'yyyyMMdd').xml"
# Or as HTML for human readability
Get-CauReport -ClusterName $cluster -Last 1 -Detailed |
ConvertTo-Html | Out-File "C:\Audit\CAU\$($cluster)_$(Get-Date -Format 'yyyyMMdd').html"What we add as standard in remediation:
A scheduled task that after every CAU run pulls the report, archives it to an independent location (not on the cluster itself, and not on one node), and sends a notification to a Teams webhook or SIEM. For customers with compliance requirements (ISO 27001, SOC 2, NEN 7510) this is a mandatory part of the remediation report.
Beyond the report itself:
Which change management ticket is linked to this run. Who triggered or authorised the run. What was the reason for deviation from the standard schedule. This is information the cluster itself does not track, but that needs to be captured in the broader operational context.
4. Self-updating vs remote-updating, an honest trade-off
Microsoft documentation suggests self-updating for most customers. Our experience is that remote-updating is often the right choice in enterprise environments, and here is why.
For self-updating:
- Low operational overhead, no external orchestrator needed. The cluster patches itself in the configured window, done.
- Scalable, one configuration applies to one cluster and you do not have to maintain it on a management host.
- Suited to remote sites, edge deployments, and environments without a central management server.
For remote-updating:
- Explicit control per cycle, an operator triggers the run intentionally. Fits compliance frameworks with human approval better.
- No cluster role that can degrade or land in an unexpected state without anyone noticing.
- Easier to combine pre-update and post-update tasks with the patching itself, because everything runs through one script.
- Suited to central operations teams managing multiple clusters through the same tooling (an Ansible playbook, an Azure Automation runbook, or a scheduled PowerShell script on a management host).
The CloudLabs recommendation:
For enterprise environments with multiple Hyper-V clusters and a central ops team: remote-updating, with a standardised script stack that runs each cycle consistently. For branch sites or edge deployments with limited central connectivity: self-updating.
Document the choice in the runbook (section 1), and keep the motivation in place so a future administrator understands why the mode is what it is.
CAU governance is a topic where customers are often surprised about what does or does not work in their environment. "We thought it was self-updating" is a sentence we hear in every other Health Check.
A CloudLabs Hyper-V Cluster Health Check maps the actual CAU state, identifies governance gaps, and delivers a runbook template plus audit trail script as part of the remediation report.
Schedule a Health Check intro call →5. Pre-update and post-update tasks that matter
CAU supports scriptable pre-update and post-update tasks. We use those heavily, and the specific tasks we set up as standard:
Pre-update tasks:
# Example pre-update task: cluster validation and sanity checks
$preTask = @'
param($ClusterName)
$ErrorActionPreference = 'Stop'
# Check 1: no paused nodes
$paused = Get-ClusterNode -Cluster $ClusterName | Where-Object State -eq 'Paused'
if ($paused) { throw "Paused nodes detected: $($paused.Name -join ', ')" }
# Check 2: all CSVs online
$csvBad = Get-ClusterSharedVolume -Cluster $ClusterName |
Where-Object State -ne 'Online'
if ($csvBad) { throw "CSVs not online: $($csvBad.Name -join ', ')" }
# Check 3: time service sync on all nodes
foreach ($node in (Get-ClusterNode -Cluster $ClusterName).Name) {
$source = Invoke-Command -ComputerName $node { w32tm /query /source }
if ($source -match 'Local CMOS|Free-running') {
throw "Node $node has invalid time source: $source"
}
}
Write-Host "Pre-update validation passed"
'@Register with Set-CauClusterRole -PreUpdateScript. If the pre-update task fails, CAU stops the run before a single node gets touched. This is protection against patching in an already-degraded state, which in our experience is the most dangerous patch scenario.
Post-update tasks:
# Example post-update task: CSV rebalance plus validation
$postTask = @'
param($ClusterName)
$ErrorActionPreference = 'Stop'
# Rebalance CSVs round-robin
$nodes = (Get-ClusterNode -Cluster $ClusterName | Where-Object State -eq 'Up').Name
$i = 0
Get-ClusterSharedVolume -Cluster $ClusterName | ForEach-Object {
Move-ClusterSharedVolume -Cluster $ClusterName -Name $_.Name `
-Node $nodes[$i % $nodes.Count]
$i++
}
# Test-Cluster inventory check
Test-Cluster -Cluster $ClusterName -Include 'Inventory','Network' `
-ReportName "PostCAU-$(Get-Date -Format 'yyyyMMdd-HHmm')"
Write-Host "Post-update tasks completed"
'@Register with Set-CauClusterRole -PostUpdateScript. This automatically fixes the CSV imbalance that otherwise stays behind after every patch round. See CSV ownership imbalance for broader context.
What we do not do in pre/post tasks:
No Hyper-V Replica handling. Replica synchronisation during patching is handled separately in the runbook, not automatically in CAU. That is intentional, because we want explicit control over Replica state.
No backup triggers. Backups run on their own schedule, not coupled to CAU. A CAU run that happens to coincide with a backup is a different problem, solved by schedule coordination, not by pre/post scripts.
6. CAU on Windows Server 2025, what changes
Windows Server 2025 brings several changes to CAU worth considering.
Hot-patching integration. Patches that are hot-patchable (see Windows Server 2025 Hyper-V) run much faster through a CAU run because they require no reboot. A monthly CAU run that took four hours on WS 2022 for a four-node cluster often drops to one and a half hours on WS 2025, with larger reboot windows on quarterly basis for the non-hot-patchable updates.
Azure Update Manager as alternative. For Arc-enabled Hyper-V hosts you can use Azure Update Manager instead of CAU. That orchestrates from the Azure portal and gives a central audit trail through Azure Monitor. For customers with multiple clusters in different sites this is operationally easier than per-cluster CAU configuration. However: it is a different tool, with different abstractions, and the runbook must be adapted accordingly.
Improved reporting. Get-CauReport in WS 2025 delivers slightly richer output, with explicit logging of which patches were applied via hot-patch and which were not. That helps with troubleshooting regressions.
Backward compatibility. CAU configuration from WS 2022 is automatically carried over during a cluster rolling upgrade. Existing pre/post scripts keep working. No reconfiguration needed after the upgrade, provided the scripts had no hard-coded versions.
7. Three common governance gaps
Gap 1, nobody knows which mode is active
The cluster patches monthly, but if you ask whether it is self-updating or remote-updating, you get an uncertain answer. We find this in roughly 40% of Health Checks. Fix: document explicitly in the runbook, verify with Get-CauClusterRole.
Gap 2, no audit trail of previous runs
Get-CauReport works, but nobody archives the output. When Microsoft Support wants to look three months back at a specific patch, the information is gone. Fix: scheduled task that after every run archives the report to an independent location.
Gap 3, pre/post scripts exist but were never tested
Someone added a script years ago, it appears to work, but nobody checked whether it shows expected behaviour during a failing node. Fix: simulate a failing node in a test cluster, validate that the pre-update script aborts the run correctly.
8. The CloudLabs CAU readiness report
In CloudLabs Health Checks we treat CAU as a separate finding area, with the following structure per cluster:
- Which mode is actually running. Self-updating, remote-updating, or neither. With evidence from
Get-CauClusterRole, scheduled tasks, and any external scripts. - When is the last successful run, and what did it patch. With
Get-CauReportoutput, and a check on gaps in the patch rhythm. - What is the audit trail. Does archiving exist, where, with what retention.
- Which pre/post scripts are configured. And are they idempotent, tested, and documented.
- Which runbook exists. And is it current, or does it date from a previous hardware generation.
- Which remediation steps bring it up to standard. Severity-prioritised, with estimated effort.
For customers wanting to build their own CAU governance, we deliver a runbook template and a pre/post script library. For customers wanting to outsource the remediation, we do it as a fixed-scope engagement of two to four working days.
Schedule a Hyper-V Cluster Health Check intro call →
Frequently asked questions
For the moments when it does not go well. A runbook is not for the success scenario, it is for the escalation scenario where you lose time reconstructing what normal state was. Microsoft Support during an escalated call will ask about patch levels, audit reports, and post-patch checks. If those did not exist, the call takes three times as long and support may decide not to treat issues as covered.
CAU works fine with WSUS, and for most customers that remains the right choice. Azure Update Manager is a good option if you are already Arc-enabled, manage multiple clusters across different sites, and the central audit trail in Azure adds value. It is not a required upgrade.
At minimum 12 months, preferably 24 months. Microsoft Support can ask about patches up to a year back during escalation. For customers with compliance frameworks (ISO 27001, SOC 2) retention requirements may be longer, check with the compliance officer.
First step: leave the cluster alone, do not manually resume nodes. CAU has state in C:\Windows\Cluster\CauRun.xml and can resume an interrupted run with Resume-CauRun. Second step: check why it failed with Get-CauReport -Detailed. Third step: solve the cause (usually a paused node, a failed reboot, or a hanging drain) and resume or restart the run.
For Azure Local with Azure Update Manager: yes, firmware updates are integrated into the update run. For classic Windows Server Hyper-V clusters with CAU: no, firmware remains a separate vendor procedure (Dell OpenManage, HPE OneView, Lenovo XClarity). Pre/post scripts can do firmware checks, but the actual firmware flash happens outside CAU.
Cluster Aware Updating: runbook, audit trail, en wat niemand documenteert
Cluster Aware Updating (CAU) bestaat sinds Windows Server 2012 en wordt door de meeste organisaties gebruikt. Of beter gezegd: CAU is geconfigureerd, een rol bestaat, een schema staat, en niemand kijkt er nog naar. Tot het moment dat Microsoft Support tijdens een incident vraagt om het CAU-rapport van de afgelopen drie maanden, en blijkt dat er geen audit trail is, dat het runbook nergens beschreven staat, en dat het ops-team niet weet welke modus precies actief is.
In de Hyper-V Cluster Health Checks die wij uitvoeren is CAU vrijwel altijd een bevinding. Niet omdat patches niet worden toegepast, dat gebeurt meestal wel. Maar wel omdat de operationele governance rondom CAU ontbreekt, en dat is precies wat het verschil maakt tijdens een geëscaleerd Sev-1 incident waarbij ondersteuningskwaliteit van Microsoft afhangt van wat je kunt aantonen.
Dit artikel gaat over CAU-runbooks, audit trails, en de praktische beslissingen die je vooraf neemt zodat patching een professionele operatie blijft in plaats van een maandelijkse hoop dat er niets misgaat.
- De twee CAU-modi en wat ze werkelijk betekenen
- Wat een CAU-runbook moet bevatten
- De audit trail die ontbreekt
- Self-updating vs remote-updating, een eerlijke afweging
- Pre-update en post-update tasks die ertoe doen
- CAU op Windows Server 2025, wat verandert
- Drie veelvoorkomende governance-gaps
- Het CloudLabs CAU readiness-rapport
1. De twee CAU-modi en wat ze werkelijk betekenen
Cluster Aware Updating heeft twee operationele modi, en de keuze tussen beide is een strategische beslissing die invloed heeft op runbook, audit trail en supportbaarheid.
Self-updating mode. Het cluster zelf orkestreert de update-run. Eén cluster-node is de coordinator, draint de andere nodes om de beurt, patcht ze, brengt ze weer in. Het cluster heeft een geconfigureerde CAU-rol, een ingebouwd schema, en de cluster-rol moet zelf voldoende rechten hebben om Windows Update of WSUS te bevragen.
Remote-updating mode. Een externe orchestrator (een management-server, een script-host, of een handmatige operator) start de CAU-run via Invoke-CauRun. Het cluster zelf heeft geen geconfigureerde CAU-rol. Iedere update-cyclus wordt expliciet getriggerd vanuit een gedocumenteerd patch-window.
Welke is "beter"?
Het hangt af van je operationele model. Self-updating is set-and-forget, schaalt goed over veel clusters, en past bij organisaties die volledige automatisering willen. Remote-updating geeft expliciete controle per cyclus, past bij organisaties met strikt change-management, en is wat wij vaker zien bij klanten met compliance-eisen die menselijke goedkeuring per patch-cyclus voorschrijven.
Wat CloudLabs in Health Checks vindt:
Een verrassend aantal klanten denkt dat ze self-updating draaien, maar de cluster-rol bestaat niet meer, of staat in een gedegradeerde state. Iemand heeft jaren geleden remote-updating geprobeerd, een script geschreven, en de self-updating rol uitgezet. Het script draait nog steeds, maar niemand documenteerde de overgang. Resultaat: een patch-cyclus die op self-updating lijkt, maar feitelijk afhangt van een vergeten scheduled task op een management-server die over zes maanden gedecommissioneerd wordt.
Detecteren wat er werkelijk draait:
# Check of er een CAU clustered role bestaat
Get-ClusterGroup | Where-Object {$_.GroupType -eq 'ClusterAwareUpdating'}
# Detail van de CAU-resource
Get-CauClusterRole -ClusterName $cluster
# Recente runs (laatste 5)
Get-CauReport -ClusterName $cluster -Last 5Zit hier geen output, dan draai je remote-updating (of helemaal niets). De afwezigheid van de cluster-rol is op zichzelf niet fout, mits er een gedocumenteerd remote-updating-proces is. Zonder dat proces is het wel een bevinding.
2. Wat een CAU-runbook moet bevatten
Een CAU-runbook is geen optionele documentatie, het is operationele infrastructuur. Wij eisen in CloudLabs remediation-opdrachten standaard dat de volgende secties bestaan en bijgewerkt zijn.
- Sectie 1, de modus. Self-updating of remote-updating, expliciet beschreven, met de reden waarom voor deze modus is gekozen.
- Sectie 2, het schema. Wanneer draait een CAU-run, met welke frequentie, in welk onderhoudsvenster, en wat is de fallback als het venster gemist wordt.
- Sectie 3, de update-bron. Windows Update direct, WSUS, SCCM, of Azure Update Manager. Inclusief de URL of server, en het serviceaccount waarmee het cluster authenticeert.
- Sectie 4, pre-update tasks. Wat moet vóór elke run gecontroleerd worden, scripted of handmatig. Bijvoorbeeld: cluster validatie, geen bestaande paused nodes, geen actieve incidents.
- Sectie 5, post-update tasks. Wat moet ná elke run gecontroleerd worden. CSV ownership rebalance, time service sync verifiëren,
Test-Clusterrun, alert op nieuwe firmware-drift. - Sectie 6, escalatiepad. Wat te doen als een node niet correct rejoint, als een patch faalt, of als een VM niet correct migreert tijdens drain. Wie wordt gebeld, op welk nummer, met welk informatie-pakket.
- Sectie 7, rollback. Wat is het terugrolproces als een patch een regressie veroorzaakt. Welk onderhoudsvenster is daarvoor nodig, en welke beslissingscriteria triggeren rollback.
- Sectie 8, audit-locatie. Waar worden CAU-rapporten gearchiveerd, met welke retentie, en wie heeft toegang. Onder de 90 dagen retentie is structureel te kort als Microsoft Support drie maanden terug wil kunnen kijken.
Wij leveren dit runbook als template mee bij een Health Check remediation, ingevuld voor de specifieke klantomgeving. De template zelf is generiek toepasbaar, het invullen is wat tijd kost en wat de waarde maakt.
3. De audit trail die ontbreekt
De meest voorkomende bevinding rondom CAU is niet "patches missen". Het is "er is geen bewijs welke patches op welk moment op welke node zijn toegepast".
Wat een goede audit trail bevat:
Per CAU-run het volledige rapport: welke nodes zijn gepatched, welke KB-nummers, welke duurde hoe lang, welke faalden, welke vereisten een reboot. Microsoft levert Get-CauReport voor dit doel, maar de output wordt zelden gearchiveerd.
# Volledige rapportage van de laatste run, naar XML voor archivering
$report = Get-CauReport -ClusterName $cluster -Last 1
$report | Export-Clixml -Path "C:\Audit\CAU\$($cluster)_$(Get-Date -Format 'yyyyMMdd').xml"
# Of als HTML voor menselijke leesbaarheid
Get-CauReport -ClusterName $cluster -Last 1 -Detailed |
ConvertTo-Html | Out-File "C:\Audit\CAU\$($cluster)_$(Get-Date -Format 'yyyyMMdd').html"Wat we standaard in remediation toevoegen:
Een scheduled task die na elke CAU-run het rapport ophaalt, archiveert naar een onafhankelijke locatie (niet op de cluster zelf, en niet op één node), en een notificatie naar een Teams-webhook of SIEM stuurt. Voor klanten met compliance-eisen (ISO 27001, SOC 2, NEN 7510) is dit een verplicht onderdeel van het remediation-rapport.
Naast de rapportage zelf:
Welke change-management ticket is gekoppeld aan deze run. Wie heeft de run getriggerd of geautoriseerd. Wat was de reden voor afwijkingen van het standaardschema. Dit is informatie die het cluster zelf niet bijhoudt, maar wat in de bredere operationele context wel vastgelegd moet worden.
4. Self-updating vs remote-updating, een eerlijke afweging
Microsoft's documentatie suggereert voor de meeste klanten self-updating. Onze ervaring is dat remote-updating in enterprise-omgevingen vaker de juiste keuze is, en hier is waarom.
Voor self-updating:
- Lage operationele overhead, geen externe orkestrator nodig. Het cluster patcht zichzelf in het ingestelde venster, klaar.
- Schaalbaar, één configuratie geldt voor één cluster en je hoeft het niet op een management-host bij te houden.
- Geschikt voor remote sites, edge-deployments, en omgevingen zonder centrale management-server.
Voor remote-updating:
- Expliciete controle per cyclus, een operator triggert de run bewust. Past beter bij compliance-frameworks met menselijke goedkeuring.
- Geen cluster-rol die kan degraderen of in een onverwachte staat raken zonder dat iemand het merkt.
- Eenvoudiger om pre-update en post-update tasks te combineren met de patching zelf, omdat alles via één script verloopt.
- Geschikt voor centrale operations-teams die meerdere clusters beheren via dezelfde tooling (een Ansible-playbook, een Azure Automation runbook, of een scheduled PowerShell-script op een management-host).
De CloudLabs aanbeveling:
Voor enterprise-omgevingen met meerdere Hyper-V clusters en een centraal ops-team: remote-updating, met een gestandaardiseerde script-stack die elke run consistent uitvoert. Voor branch sites of edge-deployments met beperkte centrale connectivity: self-updating.
De keuze documenteer je in het runbook (sectie 1), en de motivatie blijft staan zodat een toekomstige beheerder begrijpt waarom de modus is wat hij is.
CAU governance is een onderwerp waar klanten vaak verrast zijn over wat er wel of niet werkt in hun omgeving. "We dachten dat het self-updating was" is een zin die wij in elke tweede Health Check horen.
Een CloudLabs Hyper-V Cluster Health Check brengt de werkelijke CAU-toestand in kaart, identificeert governance-gaps, en levert een runbook-template plus audit-trail-script mee als onderdeel van het remediation-rapport.
Plan een Health Check kennismaking →5. Pre-update en post-update tasks die ertoe doen
CAU ondersteunt scriptable pre-update en post-update tasks. Wij gebruiken die intensief, en de specifieke tasks die wij standaard inrichten:
Pre-update tasks:
# Voorbeeld pre-update task: cluster validatie en sanity checks
$preTask = @'
param($ClusterName)
$ErrorActionPreference = 'Stop'
# Check 1: geen paused nodes
$paused = Get-ClusterNode -Cluster $ClusterName | Where-Object State -eq 'Paused'
if ($paused) { throw "Paused nodes detected: $($paused.Name -join ', ')" }
# Check 2: alle CSVs online
$csvBad = Get-ClusterSharedVolume -Cluster $ClusterName |
Where-Object State -ne 'Online'
if ($csvBad) { throw "CSVs not online: $($csvBad.Name -join ', ')" }
# Check 3: time service sync op alle nodes
foreach ($node in (Get-ClusterNode -Cluster $ClusterName).Name) {
$source = Invoke-Command -ComputerName $node { w32tm /query /source }
if ($source -match 'Local CMOS|Free-running') {
throw "Node $node has invalid time source: $source"
}
}
Write-Host "Pre-update validation passed"
'@Registreer met Set-CauClusterRole -PreUpdateScript. Faalt de pre-update task, dan stopt CAU de run voordat ook maar één node wordt aangeraakt. Dit is bescherming tegen patchen in een al gedegradeerde staat, wat in onze ervaring het meest gevaarlijke patch-scenario is.
Post-update tasks:
# Voorbeeld post-update task: CSV rebalance plus validatie
$postTask = @'
param($ClusterName)
$ErrorActionPreference = 'Stop'
# Rebalance CSVs round-robin
$nodes = (Get-ClusterNode -Cluster $ClusterName | Where-Object State -eq 'Up').Name
$i = 0
Get-ClusterSharedVolume -Cluster $ClusterName | ForEach-Object {
Move-ClusterSharedVolume -Cluster $ClusterName -Name $_.Name `
-Node $nodes[$i % $nodes.Count]
$i++
}
# Test-Cluster inventory check
Test-Cluster -Cluster $ClusterName -Include 'Inventory','Network' `
-ReportName "PostCAU-$(Get-Date -Format 'yyyyMMdd-HHmm')"
Write-Host "Post-update tasks completed"
'@Registreer met Set-CauClusterRole -PostUpdateScript. Dit fixt automatisch de CSV-onbalans die anders na elke patch-ronde achterblijft. Zie CSV ownership-onbalans voor de bredere context.
Wat we niet doen in pre/post-tasks:
Geen Hyper-V Replica handling. Replica-synchronisatie tijdens patching wordt apart afgehandeld in het runbook, niet automatisch in CAU. Dat is bewust, omdat we expliciete controle willen over Replica state.
Geen backup-triggers. Backups draaien op hun eigen schema, niet gekoppeld aan CAU. Een CAU-run die toevallig met een backup samenvalt is een ander probleem, opgelost door schema-coördinatie, niet door pre/post-scripts.
6. CAU op Windows Server 2025, wat verandert
Windows Server 2025 brengt enkele veranderingen aan CAU die het overwegen waard zijn.
Hot-patching integratie. Patches die hot-patchable zijn (zie Windows Server 2025 Hyper-V) lopen veel sneller door een CAU-run, omdat ze geen reboot vereisen. Een maandelijkse CAU-run die op WS 2022 vier uur kostte voor een vier-node cluster, daalt op WS 2025 vaak naar anderhalf uur, met grotere reboot-windows op kwartaalbasis voor de niet-hot-patchable updates.
Azure Update Manager als alternatief. Voor Arc-enabled Hyper-V hosts kun je in plaats van CAU ook Azure Update Manager gebruiken. Dat orkestreert vanuit Azure-portal en geeft een centrale audit-trail uit Azure Monitor. Voor klanten met meerdere clusters in verschillende sites is dit operationeel comfortabeler dan per-cluster CAU-configuratie. Wel: het is een andere tool, met andere abstracties, en het runbook moet daarop worden aangepast.
Verbeterde reporting. Get-CauReport in WS 2025 levert iets rijkere output, met expliciete logging van welke patches via hot-patch zijn toegepast en welke niet. Dat helpt bij troubleshooting van regressies.
Backward compatibility. CAU-configuratie van WS 2022 wordt automatisch overgenomen tijdens een cluster rolling upgrade. Bestaande pre/post-scripts blijven werken. Geen herconfiguratie nodig na de upgrade, mits de scripts geen hard-coded versies hadden.
7. Drie veelvoorkomende governance-gaps
Gap 1, niemand weet welke modus actief is
Het cluster patcht maandelijks, maar als je vraagt of het self-updating of remote-updating is, krijg je een onzeker antwoord. Wij vinden dit in ongeveer 40% van de Health Checks. Fix: documenteer expliciet in het runbook, verifieer met Get-CauClusterRole.
Gap 2, geen audit-trail van eerdere runs
Get-CauReport werkt, maar niemand archiveert de output. Wanneer Microsoft Support drie maanden terug wil kijken naar een specifieke patch, is de informatie weg. Fix: scheduled task die na elke run het rapport archiveert naar een onafhankelijke locatie.
Gap 3, pre/post-scripts bestaan maar zijn nooit getest
Iemand heeft ooit een script toegevoegd, het lijkt te werken, maar niemand heeft gecontroleerd of het bij een falende node correct het verwachte gedrag vertoont. Fix: simuleer een falende node in een test-cluster, valideer dat het pre-update script de run correct afbreekt.
8. Het CloudLabs CAU readiness-rapport
In CloudLabs Health Checks behandelen we CAU als een eigen bevindingsgebied, met de volgende structuur per cluster:
- Welke modus draait er werkelijk. Self-updating, remote-updating, of geen van beide. Met evidence uit
Get-CauClusterRole, scheduled tasks, en eventuele externe scripts. - Wanneer is de laatste succesvolle run, en wat patched die. Met
Get-CauReportoutput, en een check op gaps in het patch-ritme. - Wat is de audit-trail. Bestaat er archivering, waar, met welke retentie.
- Welke pre/post-scripts zijn geconfigureerd. En zijn ze idempotent, getest, en gedocumenteerd.
- Welk runbook bestaat. En is het actueel, of dateert het uit een vorige hardware-generatie.
- Welke remediation-stappen brengen het op niveau. Met severity geprioriteerd, en met geschatte effort.
Voor klanten die zelf hun CAU-governance willen opbouwen, leveren we een runbook-template en pre/post-script bibliotheek mee. Voor klanten die het remediation-traject willen uitbesteden, doen wij het in een afgebakende opdracht van twee tot vier werkdagen.
Plan een Hyper-V Cluster Health Check kennismaking →
Veelgestelde vragen
Voor de momenten dat het niet goed gaat. Een runbook is niet voor het successcenario, het is voor het escalatiescenario waar je tijd verliest aan reconstructie van wat de normale toestand was. Microsoft Support gaat tijdens een geëscaleerde call vragen naar patch-niveaus, audit-rapporten en post-patch checks. Hebben die niet bestaan, dan duurt de call drie keer langer en kan support beslissen om problemen niet als covered te beschouwen.
CAU werkt prima met WSUS, en voor de meeste klanten blijft dat de juiste keuze. Azure Update Manager is een goede optie als je sowieso al Arc-enabled bent, meerdere clusters in verschillende sites beheert, en de centrale audit-trail in Azure waarde toevoegt. Het is geen vereiste upgrade.
Minimaal 12 maanden, bij voorkeur 24 maanden. Microsoft Support kan tot een jaar terug naar patches vragen tijdens escalatie. Voor klanten met compliance-frameworks (ISO 27001, SOC 2) kan de retentie-eis langer zijn, controleer met de compliance-officer.
Eerste stap: laat het cluster met rust, ga niet handmatig nodes resumen. CAU heeft state in C:\Windows\Cluster\CauRun.xml en kan een interrupted run resumen met Resume-CauRun. Tweede stap: check waarom hij gefaald is met Get-CauReport -Detailed. Derde stap: los de oorzaak op (meestal een paused node, een gefaalde reboot, of een hangende drain) en resume of restart de run.
Voor Azure Local met Azure Update Manager: ja, firmware-updates zijn geïntegreerd in de update-run. Voor klassieke Windows Server Hyper-V clusters met CAU: nee, firmware blijft een aparte vendor-procedure (Dell OpenManage, HPE OneView, Lenovo XClarity). Pre/post-scripts kunnen wel firmware-checks doen, maar de daadwerkelijke firmware-flash gebeurt buiten CAU om.