From Health Check to Patch Night: The Method at Work
This post walks through a worked example of the five-step CloudLabs Method applied to a production Hyper-V cluster. Twelve High Risk findings were discovered, remediated in dependency order, re-measured to verify the fixes, and then executed as a patch run so clean that the on-call administrator didn't need to get out of bed.
- Setting the scene
- Intake: know what you are standing on
- Scripted inventory: read-only, repeatable, no agents
- Analysis against best practice: numbers, not impressions
- The findings document, and the re-measurement that makes it honest
- The action list, and the dependency chain that gates it
- The patch night
- Why this worked, and what it cost
0. Setting the scene
This was a planned Windows Update round on a production multi-site Hyper-V cluster: six Windows Server 2022 nodes stretched across two Dutch datacentres, carrying around 135 VMs. The updates had been deliberately scheduled as the final step of a Health Check engagement, after weeks of remediation, and executed remotely with Cluster Aware Updating.
My working morning in Bangkok went into the final checks: the run script, a fresh DNS audit of every node, and a full Failover Cluster Validation, all clean by quarter past eleven. Then, at 06:37 Amsterdam time, while the customer's administrators were still asleep, I started the run. By 09:08 it was finished: 23 updates installed, zero failures, zero cancelled, every node back up, every VM where it should be, before the first users came in on a quiet Friday morning. One of the two administrators was on holiday. The other checked in over Teams, mid-dog-walk, when the run was already almost done. Nobody had to get out of bed.
That is the whole story, and that is the point. A patch run on a production stretch cluster should be the most boring event of the month. This one was, but only because of everything that happened in the weeks before it.
1. Intake: know what you are standing on
The first Method step. Every engagement starts with topology, storage model, management tooling, backup, monitoring and recent incidents. Not because it is a formality, but because every later judgement depends on it.
This cluster: the six nodes from the opening, SAN storage over iSCSI on dedicated 25 GbE networks, SET virtual switches for LAN and Live Migration, managed through Virtual Machine Manager, backed up with Veeam. The VMs were distributed unevenly across the two sites.
The intake also surfaces what is in motion. Here, two things were: the customer was mid-way through replacing their domain controllers, which meant the DNS landscape was changing under the cluster's feet, and one Linux VM had a known Live Migration problem. Both of these would matter at the very end. An intake that misses the moving parts produces a findings document that is stale on delivery.
2. Scripted inventory: read-only, repeatable, no agents
Step two. The data comes from PowerShell scripts tailored to the environment, executed from the customer's own management server. Nothing gets installed, nothing gets changed. The inventory script is read-only by design and says so in its header, because the person approving the run should be able to verify that claim in the source.
A few design choices have earned their keep across engagements:
Pre-flight before inventory. Section 0 tests every node for DNS resolution into the management subnet, ICMP, WinRM reachability, listener bindings and firewall state. Any node that fails pre-flight is excluded from every downstream section, with an inline banner naming it, so the report stays self-documenting instead of silently incomplete.
Resumability. A state file records which sections completed. If a run is interrupted at section 9 of 12, the next invocation picks up at section 10 and appends to the same output file. On a six-node cluster a full inventory takes a while; losing it to a dropped session is not acceptable.
One text file out. The output is a single UTF-8 text file. It diffs cleanly against the previous measurement, which is exactly what step four needs.
3. Analysis against best practice: numbers, not impressions
Step three. Every data point is compared to the Microsoft baseline for the topology, and each deviation gets a risk level with a supporting reference. The first full measurement of this cluster produced twelve High Risk findings. A sample, because the concrete numbers are what make a findings document actionable:
Clock drift of up to 86 seconds. One site was clean, within a second. The other site, plus one stray node, sat 64 to 86 seconds off. That pattern points at a failed time source on one side, not random drift. Kerberos tolerates five minutes; CSV ownership and cluster heartbeats degrade well before that. Finding, root cause direction, and a hard gate: no patch round until all nodes are within one second.
Defender exclusions: empty on all six nodes. No paths, no processes, no extensions. Every VHDX I/O was eligible for real-time scanning, the most common root cause of Event ID 9 (slow I/O on a clustered volume) and almost certainly behind the backup-window slowness the customer had lived with for a year.
Pending reboots on five of six nodes, confirmed down to PendingFileRenameOperations in the registry, with around 200 days since the last restart.
Patch level seven months behind. The newest hotfix on any node dated from the previous October.
None of these is exotic. All of them are invisible from a dashboard that only shows green VMs.
4. The findings document, and the re-measurement that makes it honest
Step four. Findings go into a structured document: (1) current situation, (2) best practice, (3) deviation, (4) recommendation, (5) action, (6) reference, colour-coded by risk. But a findings document is a snapshot, and remediation changes the picture. So the document gets delta versions: re-measure, compare against the previous output file, and move findings to resolved only when the data says so.
That discipline catches things a checkbox process never would. One example worth sharing: the customer rolled out the Defender exclusions through Group Policy, exactly as recommended. The verification run still showed all six nodes scanning everything. The cause sat inside the GPO editor: in the Administrative Template for exclusions, the value name and the value had been swapped. Defender takes the value name as the exclusion, so the policy had loaded twenty labels like an exclusion list and excluded nothing. Flip the columns, gpupdate, re-verify: 162 checks passed. Without a scripted re-measurement, that policy would have sat there looking compliant for years.
Over three delta cycles the High Risk list shrank from twelve to a handful: BIOS versions aligned across sites, drivers aligned, pending reboots from before the Health Check cleared through a controlled restart cycle (weeks before the patch run), clock drift fixed at the time source, exclusions verified active. What remained High Risk was the patch backlog itself, deliberately scheduled last, because patching a cluster with broken time sync, pending file renames and a shifting DNS layer is how you convert a backlog into an outage.
5. The action list, and the dependency chain that gates it
The fifth Method step turns recommendations into an executed plan, and the key word is order. Each action gets an owner, a dependency chain and a validation step. For the patch run, the chain looked like this: clocks within a second, pending reboots cleared, WinRM reachable on all nodes, and, because of the in-flight domain controller migration, DNS verified clean on every node.
That last gate deserves emphasis. The new domain controllers had different IP addresses than the ones they replaced. A cluster node that reboots mid-patch and comes up pointing at a decommissioned resolver is a node that may not rejoin cleanly. So on the morning of the run, a standalone read-only DNS audit walked every NIC on every node: configured DNS servers, suffixes, registration settings, with an explicit match flag against the list of old DC addresses. Zero hits. Every node pointed at two valid, new domain controllers.
Then the final gate: a full Failover Cluster Validation. Not a partial run, the whole report, and every yellow line read, not skimmed. It came back clean. That was the green light.
6. The patch night
The run itself was scripted around Invoke-CauRun in self-updating mode. No CAU cluster role, no virtual computer object, no permanent account in the cluster, because this customer patches deliberately, on their schedule, not automatically. The script does four things worth copying.
It refuses to start unless the environment matches the plan. All six nodes up, no CAU run already in progress, and one very specific check: the Linux VM with the known Live Migration problem had been shut down manually in advance, with its cluster stop action set accordingly. The script verifies that VM is actually offline and aborts if it is not, because a drain that hits an unmigratable VM stalls the whole run at three in the morning. (This could have been automated with a successful-run trigger, but manual shutdown was safer: an automated script that stops a VM and then fails mid-patch leaves you explaining to the customer why their guest is offline. Not worth the risk.)
It patches one site at a time. CAU has no native site awareness, but -NodeOrder accepts an explicit list. Site one's three nodes first, then site two's. On a stretch cluster this keeps the failover capacity story simple at every moment of the run: at most one node down, and you always know which site is carrying the drained workload.
$cauParams = @{
ClusterName = $Cluster # FQDN
CauPluginName = 'Microsoft.WindowsUpdatePlugin'
NodeOrder = $NodeOrder # site 1, then site 2
RequireAllNodesOnline = $true
Force = $true
EnableFirewallRules = $true
}
$job = Start-Job { param($p)
Import-Module ClusterAwareUpdating
Invoke-CauRun @p
} -ArgumentList $cauParamsIt shows you what is happening. Invoke-CauRun blocks and prints nothing useful to a console. Launching it as a background job leaves the main thread free to poll Get-CauRun and Get-ClusterNode every twenty seconds, printing only transitions: a node moving to Suspending as it drains, Restarting as it reboots, the cluster state flipping to Down and back to Up. I watched the run over a casual lunch at my desk: the fairly boring log feed making its progress on one screen, Failover Cluster Manager open on the node being processed on the second, and the Cluster Aware Updating console on the third. All three agreed, every twenty seconds, that this was going like a charm. That triple confirmation is the difference between confidence and refreshing Failover Cluster Manager nervously for three hours.
It treats a failed launch as a failure. The first attempt died in six seconds on a wrong plugin name (Microsoft.WindowsUpdatePlugin, not Microsoft.WindowsUpdate; Get-CauPlugin lists the registered names). The lesson baked into the script afterwards: collect the job's error stream and throw loudly, because a script that prints "complete" after a run that never started is worse than no script.
The run installed the cumulative update, the .NET rollup and the definition updates on every node, each node draining, patching, rebooting and resuming in order, one site and then the other. Get-CauReport confirmed it afterwards: succeeded, twenty-three updates, nothing failed, nothing cancelled.
7. Why this worked, and what it cost
The temptation with a seven-month patch backlog is to just run the updates and hope. The backlog was the symptom that was visible. The conditions that made patching dangerous, drifting clocks, stale pending operations, an unverified policy rollout, a DNS layer mid-migration, were not visible until something measured them.
The sequence is the Method doing its job. Measure everything, rank the deviations, fix in dependency order, re-measure after every change, and only then execute the risky operation, gated behind a final validation and wrapped in a script that checks its own preconditions. The patch night was uneventful because nothing about it was left to chance, including the timing. The five to six hour difference between Bangkok and the Netherlands turns out to be a genuine operational advantage for critical maintenance: I spent a fresh morning on the final checks, launched the run in the customer's quietest hour, and watched it complete over lunch while their working day was only just beginning.
Where does your cluster stand before the next Windows Update? A CloudLabs Hyper-V Cluster Health Check follows exactly this method, ending with the scripted patch run that makes the difference between an uneventful night and an incident at three in the morning.
Book a Hyper-V Cluster Health Check →Frequently asked questions
The five-step Method: (1) Intake,understand topology, storage, tooling, backup, monitoring. (2) Scripted inventory,read-only, repeatable PowerShell across all nodes. (3) Analysis,compare against Microsoft baselines, rank deviations by risk. (4) Findings document,structured output with delta re-measurements to verify remediation. (5) Action list,execute recommendations in dependency order, gated by validation.
Clock drift up to 86 seconds (breaks Kerberos, CSV), no Defender exclusions (causes slow I/O), pending reboots on five nodes, and seven months of missed patches. None visible on a dashboard showing only green VMs. Scripted measurement finds what dashboards hide.
Clocks within one second, pending reboots cleared, WinRM reachable on all nodes, and DNS verified,critical because domain controllers were mid-migration. Each gate had a validation step. A full Failover Cluster Validation with every line read, not skimmed, was the final green light.
From 06:37 to 09:08 Amsterdam time (2 hours, 31 minutes). Six nodes, 23 updates installed, zero failures, zero cancelled. Every node back up, every VM where it should be, before the first users arrived on a quiet Friday morning.
It had a known Live Migration problem that would stall a drain at three in the morning. The script explicitly verifies the VM is offline and aborts if not, because a stalled drain mid-patch is unacceptable. Known blockers must be eliminated before the run.
Van Health Check tot Patch Night: de CloudLabs-werkwijze in de praktijk
Dit artikel volgt een praktijkvoorbeeld van de vijfstaps CloudLabs-werkwijze, toegepast op een productie Hyper-V cluster. Twaalf High Risk-bevindingen werden ontdekt, opgelost in afhankelijkheidsvolgorde, opnieuw gemeten om de fixes te verifiëren, en daarna uitgevoerd als een patchrun zo schoon dat de on-call beheerder niet uit bed hoefde.
- De situatie geschetst
- Intake, weet waar je staat
- Scripted inventory: read-only, herhaalbaar, geen agents
- Analyse op basis van best practice: getallen, geen indrukken
- Het Findings-document en een herhaalde meting
- De actielijst en de afhankelijkheidsketen die alles bewaakt
- De patch-night
- Waarom dit werkte en wat het kostte
0. De situatie geschetst
Dit was een geplande Windows Update-ronde op een productie multi-site Hyper-V cluster: zes Windows Server 2022 nodes, verspreid over twee Nederlandse datacenters, met ongeveer 135 VM's. De updates waren bewust ingepland als laatste stap van een Health Check engagement, na meerdere dagen remediation verspreid over enkele weken, en op afstand uitgevoerd met Cluster Aware Updating.
Mijn ochtend in Bangkok had ik besteed aan de laatste controles: het run script, een nieuwe DNS-audit van alle nodes, en een volledige Failover Cluster Validation, allemaal schoon om kwart over elf. Daarna, om 06:37 Amsterdamse tijd, terwijl de beheerders van de klant nog sliepen, startte ik de run. Om 09:08 was het klaar: 23 updates geïnstalleerd, nul fouten, nul geannuleerd, elke node weer up, elke VM waar die hoort, voordat de eerste gebruikers binnenkwamen op een stille vrijdagochtend. Een van de twee beheerders was met vakantie. De ander checkte in via Teams, midden in een wandeling met zijn hond, toen de run al bijna klaar was. Niemand hoefde uit bed.
Dat is het hele verhaal, en dat is precies het punt. Een patchrun op een productie multi-site cluster zou de saaiste gebeurtenis van de maand moeten zijn. Dat was het ook, maar alleen omdat alles wat eraan voorafging zo zorgvuldig was uitgevoerd.
1. Intake, weet waar je staat
De eerste stap van de CloudLabs-werkwijze. Elk engagement begint met een gesprek over topologie, storagemodel, beheertools, backup, monitoring en recente incidenten. Niet omdat het een formaliteit is, maar omdat elk later oordeel ervan afhangt.
Dit cluster: de zes nodes van hierboven, SAN-storage via iSCSI op dedicated 25 GbE-netwerken, SET virtual switches voor LAN en Live Migration, beheerd via Virtual Machine Manager, geback-upt met Veeam. De VM's waren ongelijk verdeeld over de twee sites.
De intake brengt ook aan het licht wat er in beweging is. Hier waren dat twee dingen: de klant was halverwege het vervangen van zijn domeincontrollers, waardoor het DNS-landschap onder het cluster veranderde, en een Linux-VM had een bekend live-migratieprobleem. Beide zouden er aan het eind toe doen. Een intake die de bewegende delen mist, levert een Findings-document op dat al verouderd is bij aflevering.
2. Scripted inventory: read-only, herhaalbaar, geen agents
Stap twee. De data komt van PowerShell-inventarisatiescripts die op maat voor de omgeving zijn geschreven, uitgevoerd vanaf de eigen managementserver van de klant. Niets wordt geïnstalleerd, niets wordt veranderd. Het inventory script is read-only by design en zegt dat in de header, omdat degene die de run goedkeurt dat in de source moet kunnen verifiëren.
Een paar designkeuzes hebben zich over meerdere engagements bewezen:
Pre-flight vóór inventory. Fase 0 test elke node op DNS-resolutie in het management-subnet, ICMP, WinRM-bereikbaarheid, listener-bindings en firewallstatus. Elke node die pre-flight niet doorstaat, wordt uitgesloten van alle volgende secties, met een inline banner die de server benoemt, zodat het rapport zelfdocumenterend blijft in plaats van stil onvolledig.
Hervatbaarheid. Een state file registreert welke secties klaar zijn. Als een run wordt onderbroken bij sectie 9 van 12, begint de volgende run bij sectie 10 en voegt toe aan hetzelfde outputbestand. Op een zes-node cluster duurt een volledige inventory lang; die verliezen door een verbroken sessie is niet acceptabel.
Resultaat. De output is één tekstbestand. Het toont de verschillen ten opzichte van de vorige meting, wat van groot belang is voor stap vier.
3. Analyse op basis van best practice: getallen, geen indrukken
Stap drie. Elk gegeven wordt vergeleken met de Microsoft-baseline voor de topologie, en elke afwijking krijgt een risiconiveau met een ondersteunende referentie. De eerste volledige meting van dit cluster leverde twaalf High Risk-bevindingen op. Een voorbeeld, want het zijn de concrete getallen die een Findings-document bruikbaar maken:
Clock drift tot 86 seconden. Eén site was schoon, binnen een seconde. De andere site, plus een verdwaalde node, zat er 64 tot 86 seconden naast. Dat patroon wijst op een mislukte time source aan de ene kant, niet op willekeurige drift. Kerberos tolereert vijf minuten; CSV ownership en cluster heartbeats degraderen veel eerder. Bevinding, richting van de root cause, en een harde randvoorwaarde: geen patchronde tot alle nodes binnen een seconde van elkaar liggen.
Defender-uitsluitingen: leeg op alle zes nodes. Geen paths, geen processen, geen extensies. Elke VHDX-I/O kwam in aanmerking voor real-time scanning, de meest voorkomende oorzaak van Event ID 9 (trage I/O op een clustered volume) en vrijwel zeker de reden achter de trage backup-window waar de klant al een jaar mee leefde.
Pending reboots op vijf van de zes nodes, bevestigd tot in PendingFileRenameOperations in de registry, met ongeveer 200 dagen sinds de laatste restart.
Patch-level zeven maanden achter. De nieuwste hotfix op elke node dateerde van oktober vorig jaar.
Geen ervan is exotisch. Allemaal onzichtbaar op een dashboard dat alleen groene VM's toont.
4. Het Findings-document en een herhaalde meting
Stap vier. Bevindingen worden verzameld in een gestructureerd document: (1) huidige situatie, (2) best practice, (3) afwijking, (4) aanbeveling, (5) actie, (6) referentie, kleurgecodeerd op risico. Maar een Findings-document is een momentopname, en remediation verandert het beeld. Daarom krijgt het document deltaversies: meet opnieuw, vergelijk met het vorige outputbestand, en verplaats bevindingen pas naar opgelost wanneer de data dat bevestigt.
Die discipline werkt beter dan een afvinklijst. Een voorbeeld dat het delen waard is: de klant rolde de Defender exclusions uit via Group Policy, exact zoals aanbevolen. De verificatie-run liet zien dat alle zes nodes nog steeds alles scanden. De oorzaak zat in de GPO-editor: in de Administrative Template voor exclusions waren de waardenaam en de waarde verwisseld. Defender neemt de waardenaam als de exclusion, dus de policy had twintig labels als exclusion list geladen en sloot in feite niets uit. Kolommen omdraaien, gpupdate, opnieuw verifiëren: 162 checks passed. Zonder een herhaalde meting met het script zou die policy er jarenlang compliant uit blijven zien.
Over drie deltacycli kromp de High Risk-lijst van twaalf naar een handvol: BIOS-versies gelijkgetrokken over de sites, drivers gelijkgetrokken, pending reboots van vóór de Health Check opgelost via een gecontroleerde restartcyclus (weken vóór de patchrun), clock drift opgelost bij de time source, exclusions geverifieerd actief. Wat High Risk bleef, was de patch backlog zelf, bewust als laatste gepland, want een cluster patchen met verbroken time sync, openstaande file renames en een veranderende DNS-laag is precies hoe je een backlog in een storing verandert.
5. De actielijst en de afhankelijkheidsketen die alles bewaakt
De vijfde stap zet aanbevelingen om in een actieplan, en de volgorde is daarbij doorslaggevend. Elke actie krijgt een eigenaar, een afhankelijkheidsketen en een verificatiestap. Voor de patchrun zag de keten er zo uit: klokken binnen een seconde, pending reboots opgelost, WinRM bereikbaar op alle nodes, en, vanwege de lopende domeincontroller-migratie, DNS geverifieerd schoon op elke node.
Die laatste vereiste verdient nadruk. De nieuwe domeincontrollers hadden andere IP-adressen dan de servers die ze vervingen. Een clusternode die midden in het patchen herstart en opstart terwijl hij naar een buiten gebruik gestelde resolver wijst, kan mogelijk niet schoon rejoinen. Dus op de ochtend van de run draaide opnieuw een standalone read-only DNS-audit over iedere node: ingestelde DNS-servers, suffixes, registration settings, met een expliciete match flag tegen de lijst met oude DC-adressen. Nul hits. Elke node verwees naar twee geldige, nieuwe domeincontrollers.
Daarna de laatste randvoorwaarde: een volledige Failover Cluster Validation. Geen gedeeltelijke run, het hele rapport inclusief storage, en elke regel gelezen, niets overgeslagen. Het kwam schoon terug. Dat was het groene licht.
6. De patch-night
De run zelf was gescript rond Invoke-CauRun in self-updating mode. Geen CAU-clusterrol, geen virtual computer-object, geen permanent account in het cluster, omdat deze klant doelbewust patcht, op zijn eigen schema, niet automatisch. Het script doet vier dingen die de moeite waard zijn om te kopiëren.
De checks zijn op maat gemaakt voor de omgeving. Alle zes nodes actief, geen al lopende CAU-run, en één zeer specifieke check: de Linux-VM met het bekende Live Migration-probleem was van tevoren handmatig uitgeschakeld, met de cluster stop action navenant ingesteld. Het script verifieert dat de VM daadwerkelijk offline is en stopt als dat niet zo is, omdat een onvolledige drain midden in het patchen niet acceptabel is. (Dit had geautomatiseerd kunnen worden met een successful-run trigger, maar handmatig uitschakelen was veiliger: als een geautomatiseerd script een VM stopt en daarna midden in het patchen blijft hangen, moet je aan de klant uitleggen waarom hun VM offline is. Dat risico is het niet waard.)
Het script patcht één site per keer. CAU heeft geen native site awareness, maar -NodeOrder accepteert een expliciete lijst. Eerst de drie nodes op site 1, daarna die op site 2. Op een multi-site cluster houd je zo het verhaal rond failovercapaciteit op elk moment van de run eenvoudig: hooguit één node down, en je weet altijd welke site de gedrainde workload draait.
$cauParams = @{
ClusterName = $Cluster # FQDN
CauPluginName = 'Microsoft.WindowsUpdatePlugin'
NodeOrder = $NodeOrder # site 1, then site 2
RequireAllNodesOnline = $true
Force = $true
EnableFirewallRules = $true
}
$job = Start-Job { param($p)
Import-Module ClusterAwareUpdating
Invoke-CauRun @p
} -ArgumentList $cauParamsHet laat je zien wat er gebeurt. Invoke-CauRun blokkeert en drukt niets nuttigs af naar de console. Door het als background job te starten blijft de main thread vrij om Get-CauRun en Get-ClusterNode elke twintig seconden te pollen en alleen de wijzigingen te tonen: een node die naar Suspending gaat terwijl hij draint, Restarting bij een herstart, de cluster state die naar Down klapt en terug naar Up. Ik volgde de run tijdens een ontspannen lunch aan mijn bureau: de tamelijk saaie logfeed die zijn voortgang toonde op het ene scherm, Failover Cluster Manager open op de node in behandeling op het tweede, en de Cluster Aware Updating-console op het derde. Alle drie waren het elke twintig seconden met elkaar eens. Het was duidelijk dat dit uitstekend ging. Die driedubbele bevestiging is het verschil tussen vertrouwen en bijna drie uur lang zenuwachtig verversen.
Een valse start. De eerste poging stierf in zes seconden op een foute pluginnaam (Microsoft.WindowsUpdatePlugin, niet Microsoft.WindowsUpdate; Get-CauPlugin geeft de geregistreerde namen weer). De les die daarna in het script is ingebakken: verzamel de error stream van de job en meld de fout luid, want een script dat "complete" afdrukt na een run die nooit begon, is erger dan geen script.
De run installeerde de cumulatieve update, de .NET-rollup en de definition updates op elke node, waarbij elke node om de beurt werd gedraind, gepatcht, herstart en hervat, eerst de ene site en daarna de andere. Get-CauReport bevestigde het daarna: succeeded, drieëntwintig updates, niets gefaald, niets geannuleerd.
7. Waarom dit werkte en wat het kostte
De verleiding bij een patch backlog van zeven maanden is om de updates gewoon uit te voeren en te hopen. De backlog was het symptoom dat zichtbaar was. De omstandigheden die patchen gevaarlijk maakten, driftende klokken, verouderde openstaande operaties, een niet-geverifieerde policy-rollout, een DNS-laag midden in een migratie, waren niet zichtbaar totdat het inventarisatiescript ze had gemeten.
In die volgorde doet de werkwijze haar werk. Meet alles, benoem de afwijkingen, bepaal de afhankelijkheidsvolgorde, meet opnieuw na elke wijziging, en voer dan pas de riskante operatie uit, afgeschermd achter een laatste validatie en verpakt in een script dat zijn eigen precondities controleert. De patch-night was saai omdat niets eraan aan het toeval werd overgelaten, inclusief de timing. Het verschil van vijf tot zes uur tussen Bangkok en Nederland blijkt een echt operationeel voordeel voor kritiek onderhoud. Ik kon uitgerust aan de laatste checks beginnen, het CAU-script starten in het rustigste uur van de klant, en zag het klaar zijn tijdens mijn lunch, terwijl hun werkdag net begon.
Waar staat je cluster voordat je aan de volgende Windows Update begint? Een CloudLabs Hyper-V Cluster Health Check volgt precies deze werkwijze, en eindigt met de gescripte patchrun die het verschil maakt tussen een saaie nacht en een incident om drie uur 's nachts.
Boek een Hyper-V Cluster Health Check →Veelgestelde vragen
De vijfstaps werkwijze: (1) Intake: begrijp topologie, storage, tooling, backup, monitoring. (2) Scripted inventory: read-only, herhaalbare PowerShell over alle nodes. (3) Analyse: vergelijk met Microsoft-baselines, rangschik afwijkingen op risico. (4) Findings-document: gestructureerde output met herhaalde metingen om remediation te verifiëren. (5) Actielijst: voer aanbevelingen uit in afhankelijkheidsvolgorde, bewaakt door validatie.
Clock drift tot 86 seconden (breekt Kerberos en CSV), geen Defender exclusions (veroorzaakt trage I/O), pending reboots op vijf nodes, en zeven maanden gemiste patches. Niets daarvan zichtbaar op een dashboard dat alleen groene VM's toont. Een gescripte meting vindt wat dashboards verbergen.
Klokken binnen een seconde, pending reboots opgelost, WinRM bereikbaar op alle nodes, en DNS geverifieerd, kritiek omdat de domeincontrollers midden in een migratie zaten. Elke voorwaarde had een verificatiestap. Een volledige Failover Cluster Validation, met elke regel gelezen en niets overgeslagen, was het laatste groene licht.
Van 06:37 tot 09:08 Amsterdamse tijd (2 uur en 31 minuten). Zes nodes, 23 updates geïnstalleerd, nul fouten, nul geannuleerd. Elke node weer up, elke VM waar die hoort, voordat de eerste gebruikers binnenkwamen op een rustige vrijdagochtend.
De VM had een bekend Live Migration-probleem dat een drain om drie uur 's nachts zou laten vastlopen. Het script verifieert expliciet dat de VM offline is en breekt af als dat niet zo is, want een vastgelopen drain midden in het patchen is onacceptabel. Bekende blokkades moeten vóór de run zijn weggenomen.