locked
More than 100 updates in a deployment? RRS feed

  • Question

  • Hello,
     
    A long time ago, when I was first learning SCCM2007, I read a guide (I believe from Microsoft) that recommended packages contain no more than 500 updates, and deployments not more than 100.  After some experience, I can fully understand the package recommendation (updating one with 400+ without binary differential replication, ouch), but now I'm running into a problem with the 100 on deployments.

    I usually keep deployments called "Enforcement ##" (## being a number), each containing 100 updates each so that new computers that come into our system get patched with past updates.  I so want to consolidate these into one deployment every Tuesday when I have to empty them individually of expired and superseded updates.

    I don't have any more than 500 systems at my site.  Is there any reason I shouldn't consolidate them into one deployment?

    Thanks!
    Wednesday, January 14, 2009 4:02 AM

Answers

  • First of all why would you disable binary differential replication?

    I do my deployments by product and I put all aplicable updates for each product into 1 deployment. For example I have a Windows XP deployment, an Office 2003 deployment, etc. I am not sure of the most updates that I have ever placed into a deployment though, it's just not something I track. I do not put updates in there that are installed as part of the image so that does keep the number pretty low I guess. Of course once a guy I work with built 1 package that had all the available patches for all products in it and he sent it out to DP's before he told me. The package was 11Gb and it did make it to the DP's eventually. I later deleted it of course.
    John Marcum, Systems Management Architect - www.TrueSec.com
    Wednesday, January 14, 2009 1:23 PM
  • I think the 100 updates per deployment was a guideline for a while. - though now I think the recommended is something like 350 now but don't quote me.  I personally stick all Security and Critical updates in one giant deployment containing all old updates and then create a new deployment each month for the new updates on Patch Tuesday.  The giant sustainer package has a deadline in the past to update any new computers wandering onto network.  The Patch Tuesday deployment has a two week deadline to give everyone a bit of a heads up on the looming deadline and give them time to either install beforehand or not complain to me when the get rebooted in two weeks.

    thx, Eric

    Wednesday, April 8, 2009 10:38 PM

All replies

  • First of all why would you disable binary differential replication?

    I do my deployments by product and I put all aplicable updates for each product into 1 deployment. For example I have a Windows XP deployment, an Office 2003 deployment, etc. I am not sure of the most updates that I have ever placed into a deployment though, it's just not something I track. I do not put updates in there that are installed as part of the image so that does keep the number pretty low I guess. Of course once a guy I work with built 1 package that had all the available patches for all products in it and he sent it out to DP's before he told me. The package was 11Gb and it did make it to the DP's eventually. I later deleted it of course.
    John Marcum, Systems Management Architect - www.TrueSec.com
    Wednesday, January 14, 2009 1:23 PM
  • I think the 100 updates per deployment was a guideline for a while. - though now I think the recommended is something like 350 now but don't quote me.  I personally stick all Security and Critical updates in one giant deployment containing all old updates and then create a new deployment each month for the new updates on Patch Tuesday.  The giant sustainer package has a deadline in the past to update any new computers wandering onto network.  The Patch Tuesday deployment has a two week deadline to give everyone a bit of a heads up on the looming deadline and give them time to either install beforehand or not complain to me when the get rebooted in two weeks.

    thx, Eric

    Wednesday, April 8, 2009 10:38 PM