Add TSG: Secure Boot (AzStackHci_Hardware_Test_Secure_Boot)

[1008covingtonlane]

Summary

Adds a public Environment Validator troubleshooting guide for the Hardware Secure Boot check (AzStackHci_Hardware_Test_Secure_Boot, aggregated AzStackHci_Hardware_SecureBoot). The check runs Test-SecureBoot / Confirm-SecureBootUEFI and is Critical (it blocks deployment until UEFI Secure Boot is enabled on the machine).

What the TSG covers

• Where the failure appears: the Azure portal Validation step, the on-box single validator (Invoke-AzStackHciHardwareValidation -Include Test-SecureBoot), and the AzStackHciEnvironmentChecker event log (Event ID 17205), with the real failure detail.
• How to fix it: enable UEFI Secure Boot in firmware (including the UEFI-mode / GPT prerequisite and the standard-keys note), then re-validate.
• BitLocker precaution: a Secure Boot change is measured into TPM PCR 7, so on a machine with BitLocker enabled the next boot stops at the recovery screen. Azure Local enables data-at-rest encryption by default, so the TSG documents Suspend-BitLocker -RebootCount 0 before the change and Resume-BitLocker after.

Validation

The check was validated end to end on a live Azure Local (masonenode) lab cluster: injecting Secure Boot OFF made the validator return FAILURE, and enabling Secure Boot returned it to SUCCESS.

Indexed in the EnvironmentValidator README.

[Copilot]

Pull request overview

Adds a new Environment Validator troubleshooting guide (TSG) for the Azure Local Secure Boot hardware validation check (AzStackHci_Hardware_Test_Secure_Boot, aggregated as AzStackHci_Hardware_SecureBoot), documenting where the failure surfaces, how to remediate it in firmware, and the BitLocker precaution/workflow around firmware changes.

Changes:

• Introduces a new Secure Boot TSG covering portal/on-box symptoms, validation commands, remediation steps, and escalation guidance.
• Adds the new TSG to the EnvironmentValidator index README.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
TSG/EnvironmentValidator/Troubleshooting-Hardware-Test-Secure-Boot.md	New TSG detailing diagnosis/remediation for the Secure Boot validator and BitLocker precautions.
TSG/EnvironmentValidator/README.md	Adds an index entry linking to the new Secure Boot TSG.

[1008covingtonlane]

Re-reviewed at 280334a.

The deployed-node path is now covered. Previously the TSG was scoped purely pre-deployment, but the BitLocker section addressed already-encrypted machines, which are deployed cluster members; rebooting one into firmware to change Secure Boot needed cluster-safety steps that were missing.

This revision adds them:

• Step 1 drains the node first (health pre-checks on Get-ClusterNode / Get-VirtualDisk / Get-StorageJob, then Suspend-ClusterNode -Drain), one node at a time.
• Step 6 resumes the node and waits for storage resync before the next node.
• The Overview now reconciles the scope (primarily a pre-deployment gate, with the deployed-member drain path called out).

Verified during this pass:

• Step renumbering and every cross-reference are consistent (BitLocker resume references step 2, node resume references step 1, "repeat steps 1 through 6").
• The Suspend-ClusterNode / Resume-ClusterNode reference links resolve, and only the TSG file changed.
• The BitLocker guidance itself is correct: Suspend-BitLocker -RebootCount 0 holds across the firmware change and reboot, and resume reseals to the new measured-boot (PCR 7) state. The UEFI-mode / GPT prerequisite is handled accurately.

No remaining findings. Ready for maintainer review.

[1008covingtonlane]

Re-reviewed at 6f70f29 (the "reframe for the pre-deployment scenario" commit). This resolves the framing concern cleanly and is a clear improvement for the customer.

The check runs in Deployment / Add Node validation, so the machine is a host being vetted to become a node, and the new structure now matches that:

• BitLocker is the primary step 1, with the right rationale: do it even on a fresh host, because a host can be recycled from a prior project with BitLocker already enabled. That keeps the measured-boot (PCR 7) protection in the main path regardless of deployment state.
• The cluster-drain / quorum steps are moved into a clearly gated "If the machine is already a deployed, encrypted cluster member" section, which is the uncommon case.
• Nice detail: the data-volume example changed from C:\ClusterStorage\Volume1 to D:, correct for a pre-deployment host that has no CSV yet.

Verified: the new section anchor matches its heading, the step renumbering (1 BitLocker, 2 firmware, 3 confirm, 4 resume) and all cross-references are consistent, and the forward-pointer from step 2 to the deployed-member section is correct. No remaining findings. Ready for maintainer review.