I came across an old issue that is still there when installing Software Updates during the Operating System Deployment process. This is what happens, when there are too many Software Updates available for installation, the deployment process can hang while “Waiting for job status notification”. This issue can occur in while deploying Windows 7 via Configuration Manager 2007 but also with Configuration Manager 2012. It is a Windows 7 issue, nevertheless Configuration Manager 2012 has a nice feature to overcome this issue.
This is what is happening, during the deployment process the Task Sequence hangs at “Waiting for job status notification” like shown below.
One way to fix this issue is to use the Offline Servicing option within Configuration Manager 2012, periodically install the Software Updates into the Windows 7 SP1 WIM image with the Schedule Updates option, like shown below;
After selecting the Schedule Updates option, you can choose which updates you want to install into the WIM image. Be sure to select the right Windows Architecture.
Schedule the installation of the updates on a time when the image can be taken offline, like at night. The process of installing the updates can take a couple of hours, depending of your system and the amount of Software Updates. In case of a failure, or you want to roll back the WIM image, a backup of the original WIM image is created in at the package source folder of the WIM image.
After a while the updates will be successfully installed and the installed updates are listed in the update status list.
Always update the distribution points with the updated WIM image, so that you are able to deploy Windows 7 SP1 again 🙂 It will install the Windows 7 Operating System with all the latest patches that are discovered during the OSD process.
January 15, 2014 @ 12:59
Hit F8 to open cmd, launch services.msc and restart BITS service. This should unlock the downloading updates process.
January 19, 2014 @ 17:06
Never tried this but it should be fixed in the current versions.
January 22, 2014 @ 05:22
I’ve been using Offline Servicing for a while, but recently got a bad WIM file from an update. What is the correct process for rolling back the WIM file?
e.g. do we just re-name the .bak copy & update distribution points; or should we rename & then re-import as a new OS Image?
January 22, 2014 @ 09:14
Hi Jay, that is indeed the rollback procedure. You could import the WIM again but I think that in both cases the list of installed Software Updates in the console won’t match.
January 22, 2014 @ 23:16
I just tested both methods & indeed you are right… Both will ‘work’; but neither will show the ‘correct’ SU as being installed or required. That’s a bit of a bummer…
I tried re-applying some old SU’s to the re-imported WIM & it completed successfully without actually changing the source WIM file. So you could ‘clean up’ the list by going through the SU process again… But then why not just start from a clean WIM file anyway (assuming you are using the one from the ISO).
If I were to start again from the WIM on the ISO; would you recommend applying the updates oldest to newest, or vice versa? I notice there is a massive file size difference in my updated WIM to the ‘clean’ WIM… I wonder if applying in batches newest to oldest would actually make a smaller WIM as some of the older updates would no longer be applicable (and presumable the WIM wouldn’t get updated with those).
January 24, 2014 @ 04:02
I decided to test out starting from the ISO’s install.WIM & apply updates from newest to oldest & did indeed end up with a (slightly) smaller WIM to the one that had updates applied to it each month as they came out.
Applied Each Month: ~7GB
Applied Newest>Oldest: ~6.2GB
So not a massive difference but guess every little bit can help, particularly if you have a slow network.
March 23, 2015 @ 21:31
I started seeing is issue, or at least these symptoms, recently with my win7 OSD TS in SCCM 2012R2. The task sequence seems to stall out aftThe progress dialog for the TS shows “Downloading 33 of 33 updates (96%)” and just stalls there. The smsts.log file shows repeated entries of “Waiting for Job Status notification”. I wouldn’t think 33 updates would be ‘too many’, especially considering that we had just created a new reference image in late February with updates included, so it should be just the March patches that are being applied.
I know Peter said this should be fixed in current versions, but I’m not too sure…
January 12, 2016 @ 20:30
Restarting the Windows Update service will also allow this task sequence step to complete