@a11ign/screenreader-fleet 0.0.0-reserved.0 → 0.1.0

package/src/provisioning/bare-metal/autounattend.xml

@@ -0,0 +1,428 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+  Unattended install for a BARE-METAL x64 capture worker, served from the PXE box.
+
+  The sibling at ../../local-worker/autounattend.xml is the proven recipe, and this is that recipe
+  adapted for real hardware on a real LAN. Four differences, each of which matters:
+
+  1. NO PLAINTEXT PASSWORD. The arm64 file embeds `witness`/`witness` and justifies it as "a disposable
+     local VM behind QEMU user-mode networking, reachable solely through forwarded ports". None of that
+     is true of a mini PC on your LAN, so the justification does not travel with the file. The account
+     is created with a BLANK password instead, which is the same design the rest of the fleet already
+     depends on: `LimitBlankPasswordUse=1` (a Windows default) confines a blank-password account to
+     CONSOLE logon, so it cannot be reached over SMB, RDP or password SSH at all. That makes the account
+     strictly narrower than a password would, not wider — and nothing secret is ever committed here.
+     Provisioning re-asserts and VERIFIES that invariant afterwards; see provision-nvda-worker.ps1.
+
+  2. NO VIRTIO DRIVERS. Those paths point at UTM's support ISO (`E:\Drivers\...`) and exist because a
+     QEMU guest has no inbox driver for its own disk or NIC. Real hardware does. Leaving them in would
+     fail the windowsPE pass looking for a drive that is not there.
+
+  3. ComputerName is `*`, not `A11Y-WORKER`. Twelve machines answering to one NetBIOS name is a name
+     conflict on a real network; the arm64 file could hardcode it because there is one VM behind NAT.
+     Workers are identified by address in ansible/inventory.yml, so a generated name costs nothing.
+
+  4. The TPM/SecureBoot/CPU bypasses are KEPT, and here they are load-bearing rather than a VM
+     workaround: the 6th and 7th generation boxes in this fleet (EliteDesk 800 G2/G3) are not on
+     Windows 11's supported-CPU list at all, and would refuse to install. They are harmless on the
+     8th-gen machines that would pass anyway.
+
+  ============================ THIS WIPES DISK 0, WITHOUT ASKING ============================
+  `WillWipeDisk` on DiskID 0 is what makes the install hands-off, and it is why this file must only
+  ever be served to a machine you intend to become a worker. Point your PXE server's boot entry at
+  the machines you have set aside, not at a default-for-everything entry.
+  ==========================================================================================
+
+  UAC stays at its DEFAULT, deliberately, exactly as the arm64 file explains: with UAC off every
+  process runs at high integrity, and the capture pipeline depends on NVDA (nvda_noUIAccess.exe) and
+  the browser sitting at the SAME integrity level. Provisioning gets elevation from a RunLevel Highest
+  scheduled task, which elevates with no prompt — and a prompt would be fatal, since UAC dialogs render
+  on the secure desktop where no automation can reach them.
+-->
+<unattend xmlns="urn:schemas-microsoft-com:unattend" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
+
+  <settings pass="windowsPE">
+    <!-- The locale MUST be one the INSTALL MEDIA actually carries, and this is the defect that made
+         every unattended install fall back to a fully interactive one.
+
+         Our media is Win11_23H2_EnglishInternational_x64v2, whose volume label is
+         CCCOMA_X64FRE_EN-GB_DV9: it ships en-GB resources and no en-US ones. Asking for en-US
+         therefore fails at the point Setup tries to load them, and Setup's response is not an error
+         but a FALLBACK to the language-selection page. From the console that is indistinguishable
+         from the answer file never being read, which is how it was misdiagnosed repeatedly: the
+         edition name, the boot mode, iVentoy's injection and the payload server were each blamed and
+         each was fine.
+
+         The proof is in Setup's own log, which reports success right up to this point:
+
+           Found usable unattend file for pass [windowsPE] at [C:\autounattend.xml]
+           Successfully deserialized and validated unattend file
+           Product key is valid ... User accepted the EULA in the unattend file
+           SetSetupKeyboardLayout: Failed to set the key board layout to [en-US]      <- here
+           CLanguages::v_InitLanguage - Failed to load en-US resources with error 2
+
+         Error 2 is FILE NOT FOUND. Check the media before changing these: the volume label encodes
+         the language, and `Callback_Locale_*` in X:\Windows\Panther\setupact.log names the failure. -->
+    <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
+      <SetupUILanguage>
+        <UILanguage>en-GB</UILanguage>
+      </SetupUILanguage>
+      <InputLocale>en-GB</InputLocale>
+      <SystemLocale>en-GB</SystemLocale>
+      <UILanguage>en-GB</UILanguage>
+      <UserLocale>en-GB</UserLocale>
+    </component>
+
+    <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
+      <Diagnostics>
+        <OptIn>false</OptIn>
+      </Diagnostics>
+
+      <!-- UEFI/GPT layout: ESP, MSR, then Windows across the remainder. -->
+      <DiskConfiguration>
+        <WillShowUI>OnError</WillShowUI>
+        <Disk wcm:action="add">
+          <DiskID>0</DiskID>
+          <WillWipeDisk>true</WillWipeDisk>
+          <CreatePartitions>
+            <CreatePartition wcm:action="add">
+              <Order>1</Order>
+              <Type>EFI</Type>
+              <Size>300</Size>
+            </CreatePartition>
+            <CreatePartition wcm:action="add">
+              <Order>2</Order>
+              <Type>MSR</Type>
+              <Size>16</Size>
+            </CreatePartition>
+            <CreatePartition wcm:action="add">
+              <Order>3</Order>
+              <Type>Primary</Type>
+              <Extend>true</Extend>
+            </CreatePartition>
+          </CreatePartitions>
+          <ModifyPartitions>
+            <ModifyPartition wcm:action="add">
+              <Order>1</Order>
+              <PartitionID>1</PartitionID>
+              <Format>FAT32</Format>
+              <Label>System</Label>
+            </ModifyPartition>
+            <ModifyPartition wcm:action="add">
+              <Order>2</Order>
+              <PartitionID>2</PartitionID>
+            </ModifyPartition>
+            <ModifyPartition wcm:action="add">
+              <Order>3</Order>
+              <PartitionID>3</PartitionID>
+              <Format>NTFS</Format>
+              <Label>Windows</Label>
+              <Letter>C</Letter>
+            </ModifyPartition>
+          </ModifyPartitions>
+        </Disk>
+      </DiskConfiguration>
+
+      <!-- /IMAGE/NAME must match an image NAME in the media's own install.wim EXACTLY, and the
+           value is a property of the ISO rather than of Windows. Read it, never assume it:
+
+             mount -o loop,ro <iso> /mnt
+             tail -c 200000 /mnt/sources/install.wim | tr -d '\0' | grep -oE '<NAME>[^<]*</NAME>'
+
+           This said "Windows 11 Professional". On Win11_23H2_EnglishInternational_x64v2 both NAME
+           and DESCRIPTION are "Windows 11 Pro", and "Professional" is Windows 7-era naming that
+           appears nowhere in that WIM, so it named no image at all.
+
+           HONESTY ABOUT WHAT THIS DID AND DID NOT CAUSE: it was found while chasing an interactive
+           install, and written up at the time as the cause of it. It was not — the locale mismatch
+           above was, proven afterwards from Setup's own log. This value was genuinely wrong and had
+           to be fixed, but it was never demonstrated to produce a symptom, because the locale bug
+           stopped Setup before the image was ever selected. Treat it as a latent defect corrected,
+           not as a diagnosis.
+
+           NOTE FOR THE NEXT EDITOR: an XML comment may not contain two consecutive hyphens. Using
+           them as a dash here broke the file a third time in this repo's history, and a malformed
+           answer file fails in exactly the same silent way as a wrong edition name. Validate with
+           `python3 -c "import xml.dom.minidom as m; m.parse('autounattend.xml')"` before pushing.
+
+           The generic key below is Microsoft's public KMS key for Pro, so this file always meant
+           Pro; only the spelling was wrong.
+
+           Keep this block byte-for-byte simple: substituting /IMAGE/INDEX here, or adding a
+           comment inside <InstallFrom>, made Setup reject the whole answer file the same way. -->
+      <ImageInstall>
+        <OSImage>
+          <InstallFrom>
+            <MetaData wcm:action="add">
+              <Key>/IMAGE/NAME</Key>
+              <Value>Windows 11 Pro</Value>
+            </MetaData>
+          </InstallFrom>
+          <InstallTo>
+            <DiskID>0</DiskID>
+            <PartitionID>3</PartitionID>
+          </InstallTo>
+          <WillShowUI>OnError</WillShowUI>
+        </OSImage>
+      </ImageInstall>
+
+      <!-- Not a VM workaround here: the 6th/7th-gen boxes in this fleet are not on Windows 11's
+           supported-CPU list and Setup refuses them outright without these. Harmless on 8th-gen. -->
+      <RunSynchronous>
+        <RunSynchronousCommand wcm:action="add">
+          <Order>1</Order>
+          <Path>reg add HKLM\System\Setup\LabConfig /v BypassCPUCheck /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <RunSynchronousCommand wcm:action="add">
+          <Order>2</Order>
+          <Path>reg add HKLM\System\Setup\LabConfig /v BypassRAMCheck /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <RunSynchronousCommand wcm:action="add">
+          <Order>3</Order>
+          <Path>reg add HKLM\System\Setup\LabConfig /v BypassSecureBootCheck /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <RunSynchronousCommand wcm:action="add">
+          <Order>4</Order>
+          <Path>reg add HKLM\System\Setup\LabConfig /v BypassTPMCheck /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <RunSynchronousCommand wcm:action="add">
+          <Order>5</Order>
+          <Path>reg add HKLM\System\Setup\LabConfig /v BypassDiskCheck /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <!-- BypassStorageCheck is the name Setup actually reads; BypassDiskCheck was inherited from the
+             arm64 file and appears in no Microsoft documentation. Both are kept: an ignored registry
+             value costs nothing, and a missing one costs the install. -->
+        <RunSynchronousCommand wcm:action="add">
+          <Order>6</Order>
+          <Path>reg add HKLM\System\Setup\LabConfig /v BypassStorageCheck /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <!-- The install-time bypasses above do not cover the UPGRADE path, which is what a later feature
+             update takes. Without this a box installs happily and then refuses 25H2 with "this PC doesn't
+             meet the minimum requirements", months later, on a machine nobody is watching. -->
+        <RunSynchronousCommand wcm:action="add">
+          <Order>7</Order>
+          <Path>reg add HKLM\System\Setup\MoSetup /v AllowUpgradesWithUnsupportedTPMOrCPU /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+      </RunSynchronous>
+
+      <UserData>
+        <AcceptEula>true</AcceptEula>
+        <FullName>a11ign</FullName>
+        <Organization>a11ign</Organization>
+        <!-- NO product key, deliberately, and the element is present-but-empty rather than absent.
+             `/IMAGE/NAME` above already selects the edition, which is the only job a key was doing
+             here: we do not want activation, and an unactivated Windows is fully functional for
+             capture.
+
+             It used to carry the generic Windows 11 Pro KMS client key
+             (W269N-WFGWX-YVC9B-4J6C9-T83GX). That worked while the media shipped a single
+             install.wim, and started failing with "the unattended answer file contains an invalid
+             product key" once install.wim was SPLIT into install.swm parts to fit the ISO's file-size
+             limit. Setup validates the key against the edition it resolved from the split image, and
+             the two stopped agreeing. Naming the edition and omitting the key removes the
+             disagreement rather than trying to satisfy both halves of it.
+
+             The `Key` element must be PRESENT and EMPTY, exactly like the blank password below.
+             Omitting it entirely fails differently and just as fatally: Setup stops with "Windows
+             cannot read the <ProductKey> setting from the unattend answer file". Empty means "no key,
+             do not ask"; absent means "malformed". `WillShowUI=Never` is what suppresses the "enter
+             your product key" page, which on a headless fleet is a hang nobody is there to clear. -->
+        <ProductKey>
+          <Key></Key>
+          <WillShowUI>Never</WillShowUI>
+        </ProductKey>
+      </UserData>
+    </component>
+  </settings>
+
+  <settings pass="specialize">
+    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
+      <!-- `*` generates a unique name. Twelve machines called A11Y-WORKER is a NetBIOS conflict on a
+           real network; the workers are addressed by IP from ansible/inventory.yml regardless. -->
+      <ComputerName>*</ComputerName>
+      <TimeZone>GMT Standard Time</TimeZone>
+    </component>
+    <!-- The windowsPE LabConfig keys live in the INSTALLER's registry and do not survive into the
+         installed system. Written again here so the running OS carries them, which is what a feature
+         update and any in-place repair will consult. Without this the box installs on unsupported
+         hardware and then quietly stops being able to update itself.
+
+         BypassNRO removes the "you must connect to the internet and sign in with a Microsoft account"
+         wall that 24H2 reintroduced at OOBE. The LocalAccount + HideOnlineAccountScreens below usually
+         carry it, but usually is not a property you want on a fleet you cannot see the screen of. -->
+    <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
+      <RunSynchronous>
+        <RunSynchronousCommand wcm:action="add">
+          <Order>1</Order>
+          <Description>Persist the hardware bypasses into the installed OS</Description>
+          <Path>reg add HKLM\SYSTEM\Setup\LabConfig /v BypassTPMCheck /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <RunSynchronousCommand wcm:action="add">
+          <Order>2</Order>
+          <Path>reg add HKLM\SYSTEM\Setup\LabConfig /v BypassSecureBootCheck /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <RunSynchronousCommand wcm:action="add">
+          <Order>3</Order>
+          <Path>reg add HKLM\SYSTEM\Setup\LabConfig /v BypassCPUCheck /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <RunSynchronousCommand wcm:action="add">
+          <Order>4</Order>
+          <Path>reg add HKLM\SYSTEM\Setup\LabConfig /v BypassRAMCheck /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <RunSynchronousCommand wcm:action="add">
+          <Order>5</Order>
+          <Path>reg add HKLM\SYSTEM\Setup\LabConfig /v BypassStorageCheck /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <RunSynchronousCommand wcm:action="add">
+          <Order>6</Order>
+          <Description>Allow feature updates on unsupported TPM/CPU</Description>
+          <Path>reg add HKLM\SYSTEM\Setup\MoSetup /v AllowUpgradesWithUnsupportedTPMOrCPU /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <RunSynchronousCommand wcm:action="add">
+          <Order>7</Order>
+          <Description>No Microsoft account / network wall at OOBE</Description>
+          <Path>reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE /v BypassNRO /t REG_DWORD /d 0x00000001 /f</Path>
+        </RunSynchronousCommand>
+        <!-- THE BLANK PASSWORD MUST NOT BE ABLE TO EXPIRE, AND THIS IS THE ONLY PASS THAT CAN SAY SO.
+             #1933, measured 2026-09-22 while the chairman built the five new boxes from USB media: the
+             first one came up at "Your password has expired and must be changed" and would not log on.
+             An empty new password was accepted, so the account survived; nothing in the tree had stopped
+             it being asked.
+
+             Windows' default max password age is 42 days and it applies to the blank `witness` password
+             like any other. `account.yml` and `provision-nvda-worker.ps1` BOTH set
+             `PasswordNeverExpires`, but both run over SSH, which needs the box up, which needs
+             auto-logon, which is the thing the expiry breaks. Every existing remedy sits on the far side
+             of the door it locks.
+
+             `FirstLogonCommands` cannot fix it either, and that is the trap worth naming: an expired
+             password makes AUTO-LOGON ITSELF fail, so the box stops at an interactive prompt and the
+             first-logon commands never run at all.
+
+             So it is set here, in `specialize`, which runs during setup before any logon exists. As
+             POLICY rather than per-account, because at this point the account does not exist yet:
+             `oobeSystem` creates it below and inherits whatever policy is in force.
+
+             PXE boxes mostly dodged this because provisioning follows the install within minutes and
+             closes the window. A USB build is done by hand, over hours or days, from media that may have
+             been written weeks earlier, so the window is wide enough to land in. -->
+        <RunSynchronousCommand wcm:action="add">
+          <Order>8</Order>
+          <Description>A blank password that can expire is a box that cannot auto-logon</Description>
+          <Path>net accounts /maxpwage:unlimited</Path>
+        </RunSynchronousCommand>
+        <!-- Belt and braces, and NOT a restatement of the line above. `maxpwage` stops the clock for
+             accounts created from here on; this clears the expiry WARNING path that a Windows security
+             baseline or an OEM image may already have stamped into the image being installed. The first
+             machine showed the symptom on day zero, which `maxpwage` alone does not explain, so the two
+             are kept separate rather than merged into one command that would hide which one mattered. -->
+        <RunSynchronousCommand wcm:action="add">
+          <Order>9</Order>
+          <Description>No password expiry warning at logon</Description>
+          <Path>reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v PasswordExpiryWarning /t REG_DWORD /d 0x00000000 /f</Path>
+        </RunSynchronousCommand>
+      </RunSynchronous>
+    </component>
+    <component name="Microsoft-Windows-Security-SPP-UX" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
+      <SkipAutoActivation>true</SkipAutoActivation>
+    </component>
+    <component name="Microsoft-Windows-SQMApi" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
+      <CEIPEnabled>0</CEIPEnabled>
+    </component>
+  </settings>
+
+  <settings pass="oobeSystem">
+    <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
+      <InputLocale>en-GB</InputLocale>
+      <SystemLocale>en-GB</SystemLocale>
+      <UILanguage>en-GB</UILanguage>
+      <UserLocale>en-GB</UserLocale>
+    </component>
+
+    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
+      <UserAccounts>
+        <LocalAccounts>
+          <LocalAccount wcm:action="add">
+            <Name>witness</Name>
+            <DisplayName>witness</DisplayName>
+            <Group>Administrators</Group>
+            <!-- BLANK, and empty rather than absent: Setup wants the element. See the header — a
+                 blank-password account is confined to console logon by LimitBlankPasswordUse, which
+                 is what makes credential-free auto-logon safe on a networked box. -->
+            <Password>
+              <Value></Value>
+              <PlainText>true</PlainText>
+            </Password>
+          </LocalAccount>
+        </LocalAccounts>
+      </UserAccounts>
+
+      <!-- The whole reason this file exists. NVDA is a GUI application: it needs a real logged-on
+           desktop session. No auto-logon means no session after a reboot, which means captures
+           silently return nothing at all — and on a headless fleet nobody is there to log in. -->
+      <AutoLogon>
+        <Enabled>true</Enabled>
+        <Username>witness</Username>
+        <Password>
+          <Value></Value>
+          <PlainText>true</PlainText>
+        </Password>
+        <LogonCount>2147483647</LogonCount>
+      </AutoLogon>
+
+      <OOBE>
+        <HideEULAPage>true</HideEULAPage>
+        <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
+        <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
+        <HideLocalAccountScreen>true</HideLocalAccountScreen>
+        <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
+        <ProtectYourPC>3</ProtectYourPC>
+      </OOBE>
+
+      <FirstLogonCommands>
+        <SynchronousCommand wcm:action="add">
+          <Order>1</Order>
+          <Description>Disable hibernation</Description>
+          <CommandLine>cmd /c POWERCFG -H OFF</CommandLine>
+        </SynchronousCommand>
+        <!-- Never leave the console locked: a locked desktop makes NVDA silent. Belt and braces
+             alongside provisioning, which also turns the screensaver off. -->
+        <SynchronousCommand wcm:action="add">
+          <Order>2</Order>
+          <Description>Disable screensaver (it steals foreground mid-capture)</Description>
+          <CommandLine>reg add "HKCU\Control Panel\Desktop" /v ScreenSaveActive /t REG_SZ /d 0 /f</CommandLine>
+        </SynchronousCommand>
+        <!-- Fetch the payload over HTTP rather than looking for it on the install media.
+             ==================== SET THE ADDRESS BELOW BEFORE USE ====================
+             `$h` below is 203.0.113.10 — an RFC 5737 DOCUMENTATION address, not this fleet's real
+             control-plane host (#86: a real address sat here in tracked source; RFC 5737 is reserved so
+             it can never resolve to anything, the same replacement #83 used elsewhere in this repo).
+             It WILL fail to fetch, on purpose: a box that silently boots against a stale or wrong host
+             is a worse failure than one that visibly hangs retrying an address that cannot answer.
+             Replace it with your control plane's real address before generating install media.
+
+             iVentoy injects files to X:, which is the WinPE RAM disk and is GONE by the time this runs,
+             so scanning drive letters (which the UTM path does, from a support ISO that stays attached)
+             finds nothing here. Fetching also means one small file to serve rather than a repacked ISO,
+             and this project already has scar tissue from El Torito boot catalogues.
+
+             The box PXE-booted from this host moments ago, so it can certainly reach it.
+             `serve-bootstrap.sh` on the control plane serves exactly these two files. -->
+        <SynchronousCommand wcm:action="add">
+          <Order>3</Order>
+          <Description>Fetch the bootstrap payload from the control plane</Description>
+          <CommandLine>powershell -NoProfile -ExecutionPolicy Bypass -Command "$h='http://203.0.113.10:8099'; $d='C:\a11y'; New-Item -ItemType Directory -Force $d | Out-Null; foreach($f in 'first-boot.cmd','bootstrap-windows-worker.ps1','operator-key.pub'){ for($i=0;$i -lt 60;$i++){ try{ Invoke-WebRequest -UseBasicParsing -Uri ($h+'/'+$f) -OutFile ($d+'\'+$f); break }catch{ Start-Sleep -Seconds 5 } } }"</CommandLine>
+        </SynchronousCommand>
+        <!-- Then hand off. first-boot.cmd waits for DHCP, stages the operator key, and runs the bootstrap
+             elevated via a RunLevel Highest scheduled task, because a UAC prompt here would render on the secure
+             desktop where no automation can reach it. After this the box is reachable by Ansible and needs
+             no console visit at all. -->
+        <SynchronousCommand wcm:action="add">
+          <Order>4</Order>
+          <Description>Run the worker bootstrap elevated, without a UAC prompt</Description>
+          <CommandLine>cmd /c if exist C:\a11y\first-boot.cmd start /wait C:\a11y\first-boot.cmd</CommandLine>
+        </SynchronousCommand>
+      </FirstLogonCommands>
+    </component>
+  </settings>
+</unattend>

package/src/provisioning/bare-metal/serve-bootstrap.sh

@@ -0,0 +1,86 @@
+#!/usr/bin/env bash
+# Serve the three files a PXE-installing worker fetches at first logon.
+#
+#   ./serve-bootstrap.sh ~/.ssh/a11y-witness_ed25519.pub
+#   ./serve-bootstrap.sh ~/.ssh/a11y-witness_ed25519.pub 8099
+#
+# Run it on the machine whose address is in autounattend.xml — normally the iVentoy host, because the
+# box PXE-booted from there moments earlier and can certainly reach it.
+#
+# ## Why a fetch rather than files on the media
+#
+# iVentoy's file injection decompresses into **X:**, which is the WinPE RAM disk and is GONE by the time
+# FirstLogonCommands runs. The UTM path can scan drive letters because its support ISO stays attached;
+# nothing stays attached here. Rebuilding the install ISO to carry the files is the other option, and
+# this project has already spent a day on El Torito boot catalogues and `0xc0000225` to earn the opinion
+# that it is not worth it for three small files.
+#
+# ## The key is served, never committed
+#
+# A public key is not a secret, but it IS specific to whoever runs this fleet, and a checked-in one
+# grants access to anyone with the repo. It is passed in here and served for the few minutes an install
+# takes.
+#
+# ## Run it by hand, or as a service
+#
+# This serves an SSH public key and two scripts to anyone on the LAN who asks. That is a small exposure and
+# a real one, so run by hand it should be Ctrl-C'd once the box is up.
+#
+# It used to say it was "deliberately NOT a service", and the fleet outgrew that. Started by hand it is a
+# step somebody has to remember, and forgetting produces the worst failure this path has: Windows installs
+# fine, the fetches retry for ~15 minutes, and the box sits at a desktop with no worker on it — which reads
+# as a bad image. `a11y-bootstrap.service` beside this file runs it with Restart=always instead.
+#
+# If you do run it as a service, note the staging below: the payload is snapshotted at START, so a restart
+# is what picks up a changed first-boot.cmd or bootstrap-windows-worker.ps1.
+set -euo pipefail
+
+KEY="${1:-}"
+PORT="${2:-8099}"
+
+if [ -z "$KEY" ] || [ ! -f "$KEY" ]; then
+  echo "usage: $0 <path-to-public-key> [port]" >&2
+  echo "  e.g. $0 ~/.ssh/a11y-witness_ed25519.pub" >&2
+  exit 2
+fi
+
+# Refuse a PRIVATE key with the loudest message available. Handing one to every machine on the LAN is
+# not a mistake anyone recovers from quietly, and the two filenames differ by four characters.
+if grep -q "PRIVATE KEY" "$KEY"; then
+  echo "REFUSING: $KEY is a PRIVATE key. Serve the .pub, and rotate that key now." >&2
+  exit 1
+fi
+if ! grep -qE '^(ssh-|ecdsa-)' "$KEY"; then
+  echo "REFUSING: $KEY does not look like an SSH public key (expected ssh-... or ecdsa-...)." >&2
+  exit 1
+fi
+
+HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+STAGE="$(mktemp -d)"
+trap 'rm -rf "$STAGE"' EXIT
+
+cp "$HERE/../../local-worker/first-boot.cmd" "$STAGE/first-boot.cmd"
+cp "$HERE/../bootstrap-windows-worker.ps1" "$STAGE/bootstrap-windows-worker.ps1"
+cp "$KEY" "$STAGE/operator-key.pub"
+
+# CRLF for the .cmd. A LF-only batch file run by cmd.exe fails in ways that name the wrong line, which is
+# a debugging session nobody needs at 2am beside a mini PC.
+perl -pi -e 's/\r?\n/\r\n/' "$STAGE/first-boot.cmd" 2>/dev/null || true
+
+cat <<EOF
+
+  Serving on port $PORT:
+    first-boot.cmd
+    bootstrap-windows-worker.ps1
+    operator-key.pub   ($(ssh-keygen -lf "$KEY" 2>/dev/null | awk '{print $2, $3}'))
+
+  autounattend.xml must point at THIS machine. Check the address in it matches one of:
+$(command -v ip >/dev/null 2>&1 && ip -4 -o addr show scope global | awk '{print "    http://" substr($4, 1, index($4, "/")-1) ":'"$PORT"'"}' \
+  || ifconfig 2>/dev/null | awk '/inet /{if ($2 != "127.0.0.1") print "    http://" $2 ":'"$PORT"'"}')
+
+  Ctrl-C once the worker is up — this is not a service.
+
+EOF
+
+cd "$STAGE"
+python3 -m http.server "$PORT"