A stable technical reference point
The first measurement establishes a defensible baseline. Later decisions can be compared with measured state rather than memory, ticket history or assumptions.
Enterprise Failover Cluster Assurance
Know the risk
Prove the improvement
A cluster assessment is most useful when it becomes a control loop. ClusterTriage establishes the technical baseline, turns deviations into prioritised findings, verifies remediation and keeps configuration drift visible throughout the year.
Baselineknown technical starting pointDeltawhat changed since last timeResidual riskwhat remains after remediationDriftnew deviations as they appear
Why enterprise teams use Assurance
A one-off measurement is a snapshot. Assurance creates control.
Large cluster estates change continuously: firmware, drivers, virtual switches, VLANs, storage paths, Windows updates, BIOS settings, quorum, VM placement and operational procedures. A clean report in January does not guarantee a clean cluster in October.
Verification instead of closure
A ticket marked complete does not prove the environment changed. Follow-up measurements verify whether the intended state is actually present.
Detect the new normal before it settles
Configuration drift is exposed between rounds, so small deviations can be addressed before they become accepted production reality.
Risk, not a flat checklist
Measured deviations are assessed in context and prioritised by operational consequence, dependencies and recoverability.
Traceable findings
Findings contain the measured state, expected state, deviation, risk, recommendation and reference rather than a dashboard score without explanation.
One year of comparable evidence
Four rounds make the direction visible: improving, stable or accumulating new risk.
Annual cycle
Four measurements. One continuous assurance loop.
The first round creates the baseline. Each following round uses the same measurement method to verify remediation and expose new drift.
Not merely finding what is wrong, but proving that it improved, and that it stays improved.
Measure → Analyse → Prioritise → Remediate → Verify → RepeatBaseline
Full measurement of cluster, hosts and relevant dependencies. This becomes the technical reference point.
- Full findings report
- Risk priorities
- 1-hour review
Verify
The same measurement runs again. Remediation is verified by measured state, not by assumption.
- Delta report
- Residual-risk overview
- 1-hour review
Detect drift
Firmware, networking, storage and host configuration evolve. The third round shows what shifted since Q2.
- New deviations
- Open actions
- 1-hour review
Assure
The fourth measurement closes the year with a current configuration and risk position.
- Annual trend
- Next priorities
- 1-hour review
How the measurement works
Read-only, from your own management server
A collection script runs from your management server over WinRM to the cluster nodes. It only reads and changes nothing. The base measurement takes about fifteen minutes.
Nothing installed
No agent, no service, no scheduled task. Nothing is left behind afterwards.
Nothing changed
The script changes no settings and restarts nothing.
No passwords
The script works with the privileges of the administrator who starts it. Before the file is written it checks its own output for values that look like credentials.
The result stays with you
One file on your server. You hand it over through an encrypted share we set up for you.
Modules extend the measurement to the layers around the cluster: switches, storage array, management controllers, the Azure side, backup and identity. They run separately, with access agreed in advance, and their findings land in the same report.
What you read per finding
Measured values, the norm, the repair and the check afterwards
Every finding is built from the measured values of this round, not from a template.
Per finding
- What was measured, with the values, the node names and the date.
- What the vendor or Microsoft prescribes, with the source.
- Where the two diverge and what that means in your situation.
- The repair work, in order, with the commands.
- The check with which you confirm it worked: the same command with which we found it.
- How you keep the result in place, so it does not come back.
Two elements you rarely find elsewhere
- Items without deviation. What was checked and found in order is in the report too. That is your evidence of what was examined.
- The limits of the measurement. What we could not see is named, with the reason: no access to the array, management controllers unreachable, a node that did not respond. So you know what the report covers and what it does not.
The report is available in Dutch, English and German. All languages are built from the same measurement and not translated afterwards.
Alongside what you already have
One report across all layers, with the connections between them
You probably already use one or more of these tools. They do their job, and they stop somewhere.
What you already have, and where it stops
- Cluster validation and the Azure Local readiness checker judge whether you may build. About a cluster that has been running for a year they say little.
- The continuous assessment under a Microsoft Unified or Premier contract is useful for the trend, but it is a dashboard, machine-translated, and it only examines the Microsoft layer.
- Your hardware vendors' portals look deep into their own product and not beyond it.
- Documentation tooling records what is there, but does not judge it.
What the cluster assessment adds
- One report across host, cluster, storage, network, array, management controllers, Azure and backup, with the connections between them. A path that is right on the host and wrong on the switch only stands out when someone lays both side by side.
- What was not seen is in the report, with the reason.
- The form of the report is enforced by a check in the toolchain, not by an agreement.
- No support contract, Azure subscription or workspace required. Just a management server that can reach the nodes, and an hour of your time per quarter.
Scope and start
A measurement, not monitoring and not operations
What we do not do
- We monitor nothing: this is a measurement, not alerting.
- We install nothing on your systems.
- We change nothing; everything is read.
- We do not take over operations.
- The repair is yours to do. On a time-and-materials basis we can also do it for you.
How it starts
We start with a conversation about your environment and about what we may see. From that follows which modules make sense and which access they require. We request that access up front. Whatever you do not want to give is then known in advance, instead of appearing afterwards as a gap in the report.
Then you run the measurement, on your own or with us alongside. You place the result on the encrypted share, we deliver the report and schedule the review.
What management gets
Technical evidence that can support an operational decision
Change visibilityWhat was fixed, what remained open and what is new.
Residual riskThe current open risk after remediation, not the original problem list.
TrendWhether risk is actually falling across the year.
PrioritiesWhere engineering attention should go next, with technical reasoning behind it.
Reporting
Same evidence, different management views
The reports are generated from the same measured state. Click the examples to inspect the output.
ClusterTriage Assurance
Make cluster improvement measurable
Start with a baseline, then use three comparable follow-up measurements to verify remediation and control configuration drift.