5a9c3db7af
Observed today on E8FHGDB4: Install-ProvisioningPackage timed out after the PowerShell cmdlet's hardcoded 180s limit on a 7.6 GB GCCH v4.10 PPKG. The catch-block fell through to Add-ProvisioningPackage, which returned "success" but the PPKG diagnostic bundle showed the child provtool.exe was called with empty packagePathsToAdd (session created, State=Not started, RebootCount=0). The PC was named, OOBE-completed, and BPRT apps ran, but the bulk enrollment never applied - PC was not Entra-joined. Microsoft Docs GitHub issue 502 confirms the 180s cmdlet timeout is hardcoded with no configuration option. Quest KB 4376269 suggests rebuilding the PPKG with the latest Windows Configuration Designer, but that is upstream and not under our control per PPKG. Switch to Start-Process -FilePath provtool.exe -Wait. The wait is on the actual child process, no caller-side timeout. provtool.exe is what the cmdlet was invoking anyway; we just bypass the wrapper that imposes the limit. Sources: https://support.quest.com/on-demand-migration/kb/4376269 https://github.com/MicrosoftDocs/windows-powershell-docs/issues/502 https://learn.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-apply-package