feat(autopilot): implement hardware hash upload

[mchave3]

Summary

This pull request is the implementation track for the Autopilot hardware hash upload feature. It introduces the foundation documentation and the first implementation slice required to support a future WinPE hardware hash capture and Microsoft Graph upload workflow.

The feature goal is to complement the existing offline Autopilot JSON profile provisioning path with a second Autopilot mode: capture the hardware hash from WinPE during OS deployment and upload it to Windows Autopilot through a tenant app registration.

Implementation Plan

Phase 0: Foundation and feasibility

• Create the dedicated implementation foundation branch.
• Document the target architecture, scope, non-goals, and operational constraints.
• Analyze the current Foundry Autopilot JSON profile flow.
• Record the WinPE runtime strategy, including OA3Tool, PCPKsp.dll, x64 and ARM64 scope, and retained diagnostics.
• Define the phased branch and PR roadmap.

Phase 1: Configuration model

• Add AutopilotProvisioningMode with JSON profile and hardware hash upload modes.
• Extend OSD persisted Autopilot settings with non-secret tenant, app registration, certificate, and group tag metadata.
• Extend Foundry.Deploy runtime configuration with reduced hardware hash upload metadata.
• Keep legacy missing-mode configuration backward compatible as JSON profile mode.
• Add mode-aware readiness validation and deploy configuration projection.
• Add tests for compatibility, readiness, expired certificate metadata, invalid payloads, and enum serialization boundaries.

Phase 2: Security and tenant onboarding

• Implement managed app registration discovery or creation for Foundry OSD Autopilot Registration.
• Add Graph permission and admin consent validation.
• Manage one active Foundry certificate credential by key ID and thumbprint.
• Require password-protected PFX material during media generation without persisting PFX or private key material in ProgramData.
• Generalize the existing media secret envelope pattern for Autopilot secrets.

Phase 3: Autopilot page UX

• Keep the global Autopilot enablement switch.
• Add mutually exclusive JSON profile and hardware hash upload settings expanders.
• Add tenant connection state, managed app registration state, certificate lifecycle UI, PFX selection, and default group tag selection.
• Add readiness messaging and localized strings.

Phase 4: Media build and WinPE assets

• Add WinPE-SecureStartup by default.
• Stage architecture-specific OA3Tool assets for x64 and ARM64.
• Stage hardware hash upload runtime configuration and encrypted Autopilot secret envelopes.
• Preserve current JSON profile staging behavior for JSON profile mode.
• Do not bundle PCPKsp.dll; it will be copied from the applied Windows image during deployment.

Phase 5: Foundry.Deploy runtime branching

• Load and propagate the selected Autopilot mode through startup, preparation, launch request, deployment context, and runtime state.
• Replace the JSON-only Autopilot step with a mode-aware provisioning step.
• Keep the Autopilot step after recovery partition sealing and before final log writing.
• Keep JSON mode behavior unchanged and prepare hash upload mode runtime state and diagnostics.

Phase 6: Hardware hash capture

• Implement C# OA3Tool orchestration.
• Copy PCPKsp.dll from the applied OS System32 to X:\Windows\System32 before capture.
• Generate OA3 input files, parse OA3.xml, extract serial number and hardware hash, and write troubleshooting CSV/log artifacts.
• Treat PCPKsp.dll copy/load failure as blocking for the Autopilot hash upload workflow.

Phase 7: Microsoft Graph upload

• Authenticate in WinPE only through certificate-based app-only Microsoft Graph auth.
• Import the hardware hash into Windows Autopilot.
• Poll import completion and then poll until the device is visible in Windows Autopilot devices.
• Show progress and a 10-minute visibility countdown, then continue OS deployment automatically on timeout.
• Treat Graph/auth/import failures as non-blocking for the OS deployment, while surfacing clear Autopilot warnings and diagnostics.

Phase 8: Documentation and release guardrails

• Update user-facing Docusaurus documentation in the separate docs repository.
• Document setup, tenant permissions, certificate handling, media sensitivity, WinPE requirements, x64 and ARM64 scope, troubleshooting files, and unsupported scenarios.
• Add release guardrails and physical validation guidance.

Current State In This PR

Completed:

• Foundation implementation plan and split documentation.
• Phase 1 configuration model implementation.
• Phase 1 automated test coverage.

Not included yet:

• Tenant onboarding UI or Graph calls.
• Certificate creation or PFX handling.
• Media asset staging for OA3Tool.
• WinPE hash capture.
• Graph upload runtime.
• Docusaurus documentation updates.

Merge Notes

Do not merge, squash, or auto-squash this PR automatically. The repository owner will handle merge strategy manually.

Testing

Phase 1 was validated before merge into this foundation branch with:

• dotnet build .\src\Foundry.slnx -c Release -p:Platform=x64 --nologo
• dotnet test .\src\Foundry.slnx -c Release -p:Platform=x64 --no-build --nologo

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.