The situation
The modern hosts had to move to a datacentre before permanent replacement hardware would arrive. Development and UAT still needed somewhere to run, so the practical option was to recover three retired HPE servers and build a temporary cluster from equipment already on site.
What I found
The old hardware could run Windows Server 2022 and integrate with shared SAN storage, but cluster validation exposed a much more interesting fault. Ordinary network connectivity succeeded while WinRM, CIM, WMI and Hyper-V management calls failed between hosts. That made the obvious network, firewall, policy and authentication explanations progressively less convincing.
What I changed
I rebuilt the hosts, mapped physical NICs to switch ports, configured the required VLANs, created the failover cluster and separated management, live-migration and VM traffic. The remote-management fault was traced to legacy NIC behaviour; adjusting offload and virtualisation-related settings restored management traffic. I then validated live migration, node drain and controlled reboot/recovery before preparing the source estate and using Hyper-V Replica for the DEV/UAT migration.
What happened
Three decade-old servers became a functioning temporary failover cluster with shared storage, resilient VM connectivity and a documented rollback position. The migration could proceed while the wider datacentre transition continued instead of waiting months for replacement hardware.
What I’d carry forward
Temporary does not mean casual. If an interim system is going to carry real workloads, it still deserves clear traffic roles, validation, rollback and enough documentation that “temporary” does not quietly become “mysterious”.