Why does the ‘Install Software Updates’ step take so long in a Configuration Manager operating system deployment task sequence?
Having set up and deployed machines over and over, I’ve seen many a task sequence seem to apparently freeze (or hang) on the Software Updates step of a task sequence. Why does this step take so long, assuming everything is set up correctly and working?
Let’s take a dive into the logs during deployment and gather more insight into what is happening.
Keep in mind some factors up front. The Configuration Manager client is in provisioning mode and Group Policy is suppressed until after a task sequence completes. Armed with this information, we begin to see some of what is happening in the update agent handler logs.
(WUAHandler Logs during Install Software Updates Step – Windows 7 Deployment – Example had 69 Updates to apply)
In the screenshots above we see that the Windows Update Agent handler starts at 2:01 and doesn’t finish its scan until 16 mins later. It is during this time that the task sequence step ‘Install Software Updates’ appears to hang or freeze. After this scan completes you then see any updates that need to be downloaded and installed. Doesn’t matter if there is 1 or 100. The delay before downloading is approximately the same, while the Windows update agent is properly initialized and configured to work for software updates in a task sequence.
Just to double-check, I recently monitored a Windows 8.1 deployment and had similar results and timing.
(WUAHandler Logs during Install Software Updates Step – Windows 8.1 Deployment – Example had 1 Update to apply)
So what does all this tell us? Adding the ‘software updates’ step to your task sequence will add at least a minimum of 15 minutes to your deployment times, not including the time it takes to install the actual updates. This is okay, but you should be aware of this from a planning and expectation stand point. You may defer this by waiting until after the system is deployed and then have the ConfigMgr client evaluate and apply any missing updates. This can be achieved by using custom client settings for newly deployed machines to have quicker scans and evaluations for software updates. Then, after, say, 24 hours, the machine may be moved to a different collection that no longer has the custom client settings applied. However, it really depends on your particular deployment process. Do you image and then turn off the computer right away? Do you image and hand the computer to the end-user right away? These things should be considered before you decide not to use a software update step in your task sequence. (That reminds me, you should not just turn off the computer straight away after imaging. Otherwise, you will not get your inventories, etc., but that is a blog post for another day.)
There are some additional issues that you may not be aware of, depending on if the machine has internet access or not during deployment. Refer to this ConfigMgr blog article for more information.
I didn’t include screenshots of the WindowsUpdate.Log, but you may watch that in your own environments for even more detailed information about what the client is doing during software updates.