SCCM Update deployment RRS feed

  • Question

  • Hello, 

    I have a question about updates deployment with SCCM.

    I am still testing the solution and I am trying to deploy the following scenario.

    Each month, ADR generates Software Update Groups that are advertised to a test collection.

    At the deadline the updates are properly installed on each server but it looks like the SCCM Client waits for the maintenance windows to download the update on each server.

    I would like to know if this is by design or if I can force the target servers to "pre-download" the updates before the maintenance window.

    Utlimately, I might have a lot of servers in my collection and I don't want them to wait for the maintenance window to download the updates because of the impact on the network traffic and I guess it will slow down the update deployment.

    I hope my question is clear.

    Thanks for your help.

    Monday, November 17, 2014 2:28 AM


  • Deadline randomization is something different than what I refereed to so to my knowledge, this download delay is hard-coded and unchangeable.

    Jason | | @jasonsandys

    Monday, November 17, 2014 10:06 PM

All replies

  • there is no predeployment feature is available (if maintenace windwow specify)only software update will start after closing maintenance window.
    Monday, November 17, 2014 4:42 AM
  • Updates will start downloading after the start time of the deployment on systems that they are target to and applicable on. There is up to a 2 hour randomization of this (from memory) so as to not overwhelm the DP.

    MWs only affect actual deployment enforcement which in this case means update installation; MWs do not dictate update download.

    Jason | | @jasonsandys

    • Proposed as answer by fern.santos Monday, November 17, 2014 7:55 PM
    • Unproposed as answer by fern.santos Tuesday, November 18, 2014 1:21 PM
    Monday, November 17, 2014 7:51 PM
  • additionally to Jason's reply, you can control the randomization in the client settings (Disable deadline randomization)... Not saying that you should or should not - up to you to decide.

    "However, in Configuration Manager SP1, you will be able to control this behavior for required software updates and required applications, by using a new client setting, Disable deadline randomization."

    Monday, November 17, 2014 8:02 PM
  • Deadline randomization is something different than what I refereed to so to my knowledge, this download delay is hard-coded and unchangeable.

    Jason | | @jasonsandys

    Monday, November 17, 2014 10:06 PM
  • Thank you for your answers.

    My main concern is that I don't want to overload the DP and the network if all my servers download the updates at the "same time", even though I understand there is a 2 hour randomization.

    In that case, what would be a recommendation for the number of servers (per distribution) on which I can deploy the updates at the same time ?


    Tuesday, November 18, 2014 4:18 AM
  • It depends on the bandwidth between the clients and the DP and on the resources that the DP has (Disk performance).

    How many clients do you have on that DP?

    Tuesday, November 18, 2014 12:45 PM
  • I don't quite agree here. My experience is that the updates are not pre-cached. They are downloaded to the local cache as they are being installed - after the deadline is reached + randomization.

    Gerry Hampson | Blog: | LinkedIn: Gerry Hampson | Twitter: @gerryhampson

    Tuesday, November 18, 2014 1:10 PM

  • I also read an 80 page Doc on the software updates process (by Vinay - Sr Support escalation engineer), which is very detailed, and it mentions the randomization for the deployment (controlled by the client setting), but it doesn't mention any randomization for the caching of the content. It says that the job to download the software update files from the DP starts at the scheduled deadline, after it validates the required updates.

    Looking at the screenshots he used, the deployment was required at 7:15pm and the download happened within the same minute... If there was randomization it would take a few minutes at least, even in a lightly used test environment.

    ... from technet... Unfortunately, it doesn't mention randomization... 

    The Configuration Manager client downloads the content for required software updates to the local client cache soon after it receives the deployment. However, the client waits download the content until after the Software available time setting for the deployment.

    The client does not download software updates in optional deployments (deployments that do not have a scheduled installation deadline) until the user manually initiates the installation.

    >>>When the configured deadline passes, the software updates client agent performs a scan to verify that the software update is still required, then the software updates client agent checks the local cache on the client computer to verify that the software update source file is still available, and then installs the software update.

    If the content was deleted from the client cache to make room for another deployment, the client downloads the software updates to the cache. Software updates are always downloaded to the client cache regardless of the configured maximum client cache size. For other deployments, such as applications or packages, the client only downloads content that is within the maximum cache size that you configure for the client. Cached content is not automatically deleted, but it remains in the cache for at least one day after the client used that content.

    • Edited by fern.santos Tuesday, November 18, 2014 1:41 PM
    Tuesday, November 18, 2014 1:21 PM
  • Yes, I know what it says on the TechNet article Fernsantos. I just never agreed with it. I hadn't experienced the updates being downloaded as soon as they became available (or within a randomized timeframe) despite previously carrying out some testing on this.

    However (there is always a however), I've just carried out some more testing and I'm incorrect. My apologies. I have analysed the behaviour on some clients that received a software update policy yesterday (Monday) with a deadline of Wednesday. The updates were downloaded to the cache from 5 to 8 hours later. It seems that the period of randomisation is much greater than the default 2 hours in the case. Clearly I wasn't patient enough in previous testing.

    Gerry Hampson | Blog: | LinkedIn: Gerry Hampson | Twitter: @gerryhampson

    Tuesday, November 18, 2014 2:36 PM
  • Gerry, that is interesting...

    I checked one of my computers for my last deployment and I see that it started downloading the content exactly 1 hour after the deployment's available time, which was a few days before the deadline (required) time. Deployment was Created Nov 4 @9:46a, Available Nov 4 @9:46a, Deadline Nov 7 @2:00A. The client downloaded to cache Nov 4 @10:46a (when the machine policy ran and discovered the new deployment?).

    Another computer downloaded at 9:49a. I can't check all computers, but it would be interesting to see.

    Keep in mind that it can take up to 1 hour for my new deployment to be received on the client side (client policy setting).

    It would be nice to find some MS official doc, but I haven't yet...

    Tuesday, November 18, 2014 3:50 PM
  • I have about 100 clients for this distribution point.
    Wednesday, November 19, 2014 8:19 PM
  • Thanks for your help with this issue.

    I could also reproduce and as you said, after some time (more than 2 hours), the updates were cached in the ccmcache folder.

    Now, I wonder why the updates installation is so take 5 more times than if I install them manually. Is it because of the SCCMClient that creates some overhead ?


    • Edited by LiveBTW83 Thursday, November 20, 2014 3:20 AM
    Wednesday, November 19, 2014 8:25 PM
  • I’m cleaning up old post, did you figure this out yet, if so what was the solution?

    Garth Jones | My blogs: Enhansoft and Old Blog site | Twitter: @GarthMJ

    Saturday, November 29, 2014 4:53 PM
  • The deployment of the updates is still slower via SCCM than using "Control Panel, Windows Updates, Check from MS" and install the updates manually.

    Moreover, lots of updates fail during the installation or gets stucks at "waiting to install"...

    Saturday, February 21, 2015 4:42 AM
  • You would have to start troubleshooting that. Why is it failing? Why is it "waiting for installation"? I do not agree that using ConfigMgr is slower in general.

    Torsten Meringer |

    Saturday, February 21, 2015 8:29 AM