The official blog of the Microsoft System Center Configuration Manager Product Group
[May 13 Update] Thank you all for your patience. A hotfix to address this issue is now available for download here: http://support.microsoft.com/kb/2509007
-- Brian Huneycutt
[Today's post is from Brian Huneycutt]
The Configuration Manager Sustained Engineering and Customer Support and Services teams are investigating an issue where the Install Software Updates action will hang indefinitely on Windows 7 clients.
When this happens, the task sequence Installation Progress dialog displays "Downloading 1 of x Updates (0% complete) ..." with no change in the progress bar, as shown in the following picture.
If you look at the smsts.log file during this time, you'll see the following entries and the last entry repeats:
//Installing all updates targetted for this computerInstallation of updates startedWaiting for installation job to completeWaiting for job status notification ...Waiting for job status notification ...Waiting for job status notification ...//
In addition, the other log files that are associated with the Install Software Updates task (CAS.log, UpdatesDeployment.log, UpdatesHandler.log, UpdatesStore.log) do not update during this time.
Note: The repeated "Waiting for job status notification" message can appear under normal circumstances when updates are being installed. However, if you see the repeated entry and the progress bar hangs at "Downloading 1 of x Updates" and the other components are no longer logging, it is likely that you're experiencing this issue under investigation.
In some scenarios, this issue can occur when a large number of software updates (more than 60) are applied via the Install Software Updates task for Windows 7, Office 2007, or Office 2010. A possible solution here is to use the Updates folder in the Office installation folder to reduce the number of updates to be installed during the Install Software Updates task. For additional information about how to use the Updates folder, see the following:
Some customers have reported that installing the latest Intel Mass Storage drivers as part of their deployment can also trigger this problem. If you experience this, a solution here is to remove the drivers from their deployment packages because base functionality is provided with the default Windows 7 drivers.
These are not necessarily the only triggers for this particular issue, but the two that have been observed by several customers. This blog entry will be updated as soon as we have more information.
Thank you for your patience as we work to find the best resolution for all our customers.
-- Brian Huneycutt
This posting is provided "AS IS" with no warranties and confers no rights.
I have noticed that setting your dp to accept anonymous connections seems to resolve this issue. Not sure why this is needed all of a sudden but its a workaround.
fixed it by not using the microsoft provided functionality, wrote a powershell script to check, download, and install updates, works 100% of the time :) (Note: This was using MDT2010, not the ConfigMgr approach though, but MDT2010 had the same issue)
A work around until this is resolved is to inject the drivers into the captured wim, using
with a windows update downloader program.
Also experiencing this issue when including Office 2007 updates in the Install Software Updates Task. Removing the Office updates from the deployment collection and including them in the Office installation updates folder does seem to solve the problem. However, when deploying a new machine it would be nice to have the latest updates installed using the TS. Do hope a solution will be found pretty soon! (running R3 by the way...)
Thanks for the info Brian. Will you keep this blog post updated with the progress of the issue, please?
I had an update always hang, turns out there was a hidden thumbs.db file in the folder, which would mess it up. I can't recall the exact behavior but as soon as I deleted the thumbs.db, everything worked.
I had the same issue, I was able to solve it by installing the latest Windows Update Agent Version (7.4...) prior to the install updates task.
Interessting, I have exactly the same sympton with vNext beta 1 but with less updates (10 or so...)
Escalated this via CEP, I'll try again with beta 2 ;-)
I have it too.... in both a reference (workgroup) and a deployment (domain) image
tried all kinds of updates and sizes - No Office updates only W7
I would really need an resolution for this issue. Has anyone found a workaround?
Is there a workaround for this issue? I really need a solution to this problem...
We have had the the same issue when reinstalling a existing computer. Our workaround is to delete the computer object from ConfigMgr before we start the installation.
Any update to this issue Brian? Thanks
Seriously, this is really a annoying bug, I can't imagine they haven't thought about this one at first. I mean, with around 15 critical updates relased every tuesday of each month, it was bound to happen... So my workaround is to inject only 45 updates in my "reference image", wow! (sarcasm)
Thank you all for your patience. We are working on a hotfix for this issue and we've identified what we need to do for a fix. Now we just need to put it through its paces in testing. Provided all of our internal testing goes well we have a number of customers queued up to verify the fix for us, and then it will be released via a KB article. This process is a lengthy one but required to ensure we deliver a high quality fix. I'll update the main blog post with more when available. In the meantime, Windows 7 SP1 will greatly reduce the number of individual updates. Of course that requires testing on your own but I did want to mention it as one more option.