Prepare an additional HGS node without overlooking its identity and DNS prerequisites

Source facts

Microsoft recommends a highly available HGS cluster for production so a failed HGS node does not prevent shielded virtual machines from starting. Secondary nodes are optional in test environments. An additional node should match the primary node’s hardware and software, share the HGS network, and resolve the other HGS servers by name. The documented procedure joins it to the same domain as the first HGS node. Microsoft documentation.

Applicability

Use this review when adding capacity or resilience to an existing HGS deployment. Identify its forest model and certificate arrangement, then follow the matching branch of the source procedure for that environment.

DSE recommendation

Compare the proposed node with the primary before initialization. Assign owners for name resolution, domain membership, certificates, and the workload acceptance test. Record the existing HGS service state and plan the addition during an agreed maintenance period. Keep the new node out of the accepted service inventory until its configuration and intended role have been reviewed.

Verification

Check name resolution and domain membership from the added node. Verify the completed HGS configuration against the selected procedure and perform an approved shielded-VM start test. Include a controlled loss of the node intended to be redundant. Record which nodes participated and investigate any failed start separately from successful installation.

Official references

Microsoft Learn: Configure additional HGS nodes. Source reviewed September 8, 2026.