b86b830568
Imaging chain stalled on WJF00159 after FormTracePak Setup.exe forced a reboot: SupportUser auto-logged in fine, briefly flashed something (an HKLM\Run logon hook), then idle - no resume of Run-ShopfloorSetup. Confirmed via diag-dispatcher.ps1: bay had AutoLogon working, RunOnce empty, no Stage-Dispatcher.ps1 on disk, no setup-stage.txt. Root cause: Run-ShopfloorSetup launches once from unattend XML's FirstLogonCommands and has no self-resume mechanism. If anything cuts it off mid-flight (FormTracePak Setup, eDNC MSI, Oracle install with forced reboot, etc) the chain dies and nothing brings it back. Stage-Dispatcher.ps1 in the repo is academic infrastructure that was never wired into the live flow - startnet.cmd does not stage it and nothing creates setup-stage.txt. Fix: have Run-ShopfloorSetup register ITSELF as RunOnce at the top of the script. The script is idempotent throughout (detection checks skip already-done work) so re-entry post-reboot picks up cleanly. Normal completion path removes the RunOnce so it does not re-fire after the planned end-of-script reboot. Also top up AutoLogonCount to 10 at script start. The unattend XML's LogonCount=7 budget gets consumed across typical imaging reboots (Office, Oracle, FormTracePak, Run-ShopfloorSetup explicit, sync-intune) and an unplanned FormTracePak forced reboot pushes the counter past 0, clearing AutoAdminLogon and parking the bay at the login screen. Restoring the budget every Run-ShopfloorSetup entry keeps SupportUser auto-logging in across any number of forced reboots until normal completion. Lockdown's Autologon.exe sets its own AutoAdminLogon for the ShopFloor user when it runs, so the post-completion natural decrement to 0 does not affect the final state. Verified via diag-dispatcher.ps1 capture on WJF00159 today - that bay had AutoLogonCount=4 and no Stage-Dispatcher.ps1 on disk, which both match this root cause + fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
24 KiB
24 KiB