If you ever need to wait to execute something until the last mile of Windows’ Setup (also called OOBE, or Out-of-the-Box-Experience) is done, there isn’t much information out in the wild about what you need to wait on. You also can’t programmatically determine the current boot state (without running a boot trace, and you still have to process it after the fact). As far as my research yields there is not a registry value, WMI method, etc. you can use to determine whether the setup has completed either. But the fact remains that when the system is in this state, scripts or commands which may get executed are not guaranteed to function correctly, and you oftentimes see nonsensical, intermittent issues with your provisioning process that leave you scratching your head.
Consider the following: your build system has just used the VMware API to build a new VM and it is now available. Your VM is in the running state, the VM customization has succeeded according to the VM events, so you are now ready to execute your OS provisioning process. This could be a command, script, or configuration management process. All is well, right?
Not necessarily.
For whatever reason (there could be several), sometimes the OOBE setup takes longer to complete than normal. Sometimes the drivers take a long time to install. Sometimes it has trouble joining to the domain (maybe due to network drivers not being fully installed). As such when you get to the OS provisioning portion of your VM build pipeline, you might need to wait for the setup to complete. But since there isn’t a known API or registry key you may consume to know this, you will need to turn to the live environment to ensure the Windows’ Setup is complete. You need to make sure that the WinDeploy.exe process is no longer running.
WinDeploy.exe is the process which handles the last mile of Windows’ Setup. This is the process that configures Windows on the first boot, as well as processes your unattend file. In powershell you can check whether it’s running as follows:
while ( Get-Process -Name windeploy ) {
Write-Verbose "Waiting for Windows' Setup to complete..."
Start-Sleep -s 30
}
Write-Verbose "Windows' Setup is now complete."
However, I don’t recommend waiting on this directly in your provisioning script. The issue is that when WinDeploy.exe exits, it’s likely going to do a final reboot, which will interrupt whatever script you’re currently running. It’s best to query your system state externally from your build system by either:
- Using your hypervisor API to ensure that WinDeploy.exe is not running
- Interact remotely with the system (although to be fair it’s unlikely you’d be able to connect remotely without the assistance of a hypervisor the while the system is in this state)
Once WinDeploy.exe stops executing, make sure you’re not in the process of rebooting. To summarize the process:
- If this is a VM, wait for the guest tools/guest agent/etc. to be ready (VMware has has a consumable API for this).
- Wait for WinDeploy.exe to stop executing.
- Check that Windows is not rebooting.
- If Windows is rebooting, wait for it to come back up, and go back to step 1.
- If Windows is not rebooting, execute your provisioning script.
Note that for steps 2 and 3, you will likely need to handle connection errors, as it’s possible the VM will reboot between polling intervals. If this happens, it’s generally safe to assume the VM is rebooting, and start the process from step 1. However, if you must do this in a provisioning script, you may be able to utilize Powershell Workflows, which are capable of resuming after a reboot.
| Published on System Code Geeks with permission by Traven West, partner at our SCG program. See the original article here: Automation Tip: Knowing When Windows’ Setup is Complete Opinions expressed by System Code Geeks contributors are their own. |
