Cluster Aware Updating: runbook, audit trail, en wat niemand documenteert

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 wij in cluster assessments vinden:

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 5

Zit 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. Als wij het herstel doen, eisen wij 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-Cluster run, 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 cluster assessment 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 nuchtere 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).

Onze 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.

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 cluster assessments. 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 CAU-hoofdstuk in het cluster assessment

In het cluster assessment 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-CauReport output, 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 herstel willen uitbesteden, doen wij dat op basis van nacalculatie.

Plan een Hyper-V cluster assessment kennismaking →