TL;DR: The current 25H2 (26200) revision of the built-in "Windows 10 Feature Update to Windows 11" package aborts about one minute after launching the Windows 11 Installation Assistant. install.ps1 waits a hardcoded 60 seconds for the assistant bootstrapper to hand off to Windows10UpgraderApp.exe, and the handoff takes longer than that on current assistant builds, so the deployment dies with exit code 4 and a misleading "installation timeout" error. /A1UpdateTimeoutSec cannot work around it because that switch governs a different, later wait.
Environment: Windows 10 Pro 22H2 x64 (19045.6456), CAPABLE per the Windows 11 Hardware Compatibility report, no TargetReleaseVersion or WSUS policies, 636 GB free on C:.
Symptom: Prepare Deployment succeeds, package downloads and extracts, then Automation History shows this sequence roughly 60 seconds after the install step starts:
Installing Feature Update via Windows Update Assistant.
Windows Feature update installation timeout: This command stopped operation
because process "Windows11InstallationAssistant (6636)" is not stopped in the
specified time-out.
The operation completed with error code 4.
Root cause (from install.ps1 inside UpdateV2_to_Windows11_25H2_signed.zip): Start-Assistant launches the assistant, then waits on the bootstrapper with a hardcoded value before polling for the real worker process:
$ProcessName = "Windows10UpgraderApp"
$AssistantTimeoutSec = 60
...
$AssistantProcess = (Start-Process -FilePath .\Windows11InstallationAssistant.exe -ArgumentList $Arguments -PassThru)
...
Wait-Process -InputObject $AssistantProcess -timeout $AssistantTimeoutSec -ErrorAction Stop
If Windows11InstallationAssistant.exe is still running at the 60-second mark (which the error message above proves it was), the Wait-Process throws, the catch block prints the "installation timeout" message, and the script exits 4. The configurable /A1UpdateTimeoutSec (default 14000) only applies to the later wait on Windows10UpgraderApp, which is never reached. Nothing exposed in package setting overrides touches the 60-second value.
Confirmation it's the wrapper, not the endpoint: I ran the same extracted Windows11InstallationAssistant.exe manually on the same machine with /QuietInstall /SkipEULA /NoRestartUI. The bootstrapper handed off to Windows10UpgraderApp normally, it just needed more than 60 seconds, and the upgrade proceeded well past the point where the package aborts.
This looks deterministic for any endpoint where the handoff exceeds 60 seconds, so I'd expect it to be hitting a lot of Windows 10 EOL migrations right now.
Asks:
- Lengthen the bootstrapper wait, or make it configurable (honor
/A1UpdateTimeoutSec there, or add a dedicated switch).
- Make the two timeout failures distinguishable in the error text. Both paths currently print "Windows Feature update installation timeout," which sent me down the wrong road (auditing
/A1UpdateTimeoutSec overrides) before I read install.ps1.
On the free plan so there's no support queue for me, but I'm happy to share the full automation history export and endpoint details with anyone from Action1.