Robert R. Posted October 18, 2012 Report post Posted October 18, 2012 Hello, A little background, we migrated our CM2007 box to CM2012 last week. There are a few loose ends here and there, but the things that we need to work - client upgrades, application deployment, software updates to clients and reporting are functional. The issue I'm having right now is with our OSD task sequences. For some reason they are not able to locate the update package in the Software Updates step. I've double-checked our boundaries and boundary groups and they are configured correctly. Dependencies during the execution of the TS are hitting their local DP for content downloads. But when it comes to the updates step, it times out. From SMSTS.log: Failed to run the action: Install Software Updates. This operation returned because the timeout period expired. (Error: 800705B4; Source: Windows) I kept a cmd window open during the TS so that I can capture the log files. If anyone here has any thoughts about this, I would greatly appreciate it. Cheers - Robert smsts.log smsts-20121018-143846.log WindowsUpdate.log Quote Share this post Link to post Share on other sites More sharing options...
Peter van der Woude Posted October 19, 2012 Report post Posted October 19, 2012 Are you completely sure you made the update available to a collection in which the machine exists? Quote Share this post Link to post Share on other sites More sharing options...
Robert R. Posted October 20, 2012 Report post Posted October 20, 2012 Thanks Peter for responding. I examined the collection structure and we did have nested sub-collections in our old cm2007 box. Thinking that the software update group would have trouble hitting the collection that the device to be imaged resided in, I created a test collection with a flat hierarchy and confirmed that the task sequence and software update group objects were indeed listed in the properties (see screengrab). I then re-ran the osd TS and software updates step still failed to execute with same error code as I noted earlier. This time though I scrutinized other log files in C:\windows\ccm\logs. I noticed in the UpdatesDeployment.log that the GUID for the corresponding software update group was detected. To me, something is rejecting the bits from the update package to be downloaded. Logs.zip WindowsUpdate.log Quote Share this post Link to post Share on other sites More sharing options...
Peter van der Woude Posted October 21, 2012 Report post Posted October 21, 2012 It looks like the same thing that happened as with ConfigMgr 2007, the step times out with a lot of updates. Try adding another Install Software Updates -step, like explained here: http://support.microsoft.com/kb/2009754 1 Quote Share this post Link to post Share on other sites More sharing options...
Robert R. Posted October 27, 2012 Report post Posted October 27, 2012 i did the workaround outlined in the KB - it worked as expected. However I'm still concerned that this workaround even needs to be implemented, as this functionality was working just fine in CM2007. I'll open up a case on Premier so we can get to the bottom of this. If there a resolution to this, I'll post it on this thread. I appreciate the advice Peter, thank you. - Robert Quote Share this post Link to post Share on other sites More sharing options...
Robert R. Posted November 9, 2012 Report post Posted November 9, 2012 Found solutions to my problem: * For an OSD TS, I appended an 'https://' to the SMSMP client installation property (ex. SMSMP=https://SCCM.HDCCO.COM). We setup our MP to communicate to the client using HTTPS and require a cert from our PKI. According the the client installation properties reference page on TechNet, specifying the MP in this fashion is required if you're not running SP1. Once I did this, updates are detected and downloaded. http://technet.micro...y/gg699356.aspx * For a Build & Capture TS, I was running into a similar issue as well. Updates would be detected but IIS would refuse to let the client download the BITS. I had a case opened on Premier to address this and they discovered in the IIS logs that NTLM wasn't being accepted as a way to pass credentials of the NAA. They had me insert a step in my TS to install KB2522623 to address this, and when the software updates ran, they were promptly detected and downloaded. http://support.micro....com/kb/2522623 Quote Share this post Link to post Share on other sites More sharing options...