none
Software Update Deployment Package Size Best Practice RRS feed

  • Question

  • Is there a recommended size limit for Software Update Deployment Packages in SCCM 2012?  I've read and heard that while there's no hard limit, it's recommended to build them and break them up by year, but some of the more recent years' packages are well over 12+ GB.  Is there any performance drag or consequence to having those be so large?  Should I break those large packages down in to smaller chunks?  

    I would like to just have one Deployment Package for simplicity's sake, but that would be monstrous.  I guess, since those are just storing the update binaries and not doing much else, I'm not sure I understand if there is or why there would be a performance drag due to large sizes.  Any suggestions or best practices for these?


    Thanks,
    Ryan

    Wednesday, May 1, 2013 3:34 PM

Answers

  • You're spot on Ryan. I like to keep the update packages smaller in size (in MB/GB size, and not necessarily number of updates) so that they are manageable if content becomes corrupted, you need to replace a DP, you add a DP, or for whatever reason you need to redeploy the package(s). Thus, I typically create a separate package for each calendar year of updates (there are of course other divisions of the updates into packages possible but all are ultimately arbitrary because clients know nothing about update packages and there is no technical reason for an update to be in one package vs. another so any other arbitrary criteria is just as good -- unless you are dealing with multiple languages and DPs dedicated to systems with only specific languages or DPs dedicated to specific OSes). Unfortunately, you can't change (from the console) the update package that an ADR uses but you can do it via PowerShell.

    Jason | http://blog.configmgrftw.com

    • Marked as answer by RyanUIowa Wednesday, May 1, 2013 8:24 PM
    Wednesday, May 1, 2013 6:48 PM

All replies

  • Wednesday, May 1, 2013 3:36 PM
  • Hi Mike,

    Thanks for the link.  I've reviewed that a couple of times and maybe I'm just missing it, but I don't see anything about recommended size limits for the Deployment Packages.  We recognize the 1000 update limit to the deployments themselves, so we keep our Software Update Groups broken down in to 1000 update increments for deploying to clients.  

    I'm more curious if there is a recommendation for the deployment package size.  Does it even matter what size they are?  Does the size only impact at first when the updates are copied to the Site/DP content libraries or when/if they have to be copied to a newly created DP (for example)?

    My thinking is the size of these only impacts when the update binaries are copied to the Site/DP content libraries or if we scale out to more DP's down the road, but I thought I would throw it out for suggestions/recommendations.

    Ryan

    Wednesday, May 1, 2013 4:35 PM
  • You're spot on Ryan. I like to keep the update packages smaller in size (in MB/GB size, and not necessarily number of updates) so that they are manageable if content becomes corrupted, you need to replace a DP, you add a DP, or for whatever reason you need to redeploy the package(s). Thus, I typically create a separate package for each calendar year of updates (there are of course other divisions of the updates into packages possible but all are ultimately arbitrary because clients know nothing about update packages and there is no technical reason for an update to be in one package vs. another so any other arbitrary criteria is just as good -- unless you are dealing with multiple languages and DPs dedicated to systems with only specific languages or DPs dedicated to specific OSes). Unfortunately, you can't change (from the console) the update package that an ADR uses but you can do it via PowerShell.

    Jason | http://blog.configmgrftw.com

    • Marked as answer by RyanUIowa Wednesday, May 1, 2013 8:24 PM
    Wednesday, May 1, 2013 6:48 PM
  • Thanks for the clarification, Jason.  I really appreciate it!

    Ryan

    Wednesday, May 1, 2013 8:24 PM
  • Just to summarize:

    - Deployment packages can be any size and contain any number of Patches (limited only by manageability and system resources)

    - Every deployment must involve no more than 1000 Patches, however big; this implies (i think) that every Update Group must contain no more than 1000 Patches, because every deployment is based on an Update Group

    - Many Update Groups can point to the same Deployment package.

    Are the above statements correct?

    If they are, then one could limit both the size of the Deployment package and the number of Patches per Update Group (somewhat) simply regularly removing from the groups (and then from the deployments) and then from the Update Package any superseded or expired patch, and then updating the package content on the DPs. (The expired ones are meant to be removed automatically from the Group if one enables the system to do this. I'm not sure if this removes the downloaded Patches from the Update Package, too).

    So, for example, I have an Upgrade Group for Endpoint Protection Patches and Definition Updates, with its Deployment Package, which is automatically renewed every 6 hours by a Deployment Rule. The Updates in the Group are a bunch, but the Patches downloaded in the package are many more, including the expired and superseded ones. The package is now little more than 1 GB; simply deleting the expired (but downloaded) content from the package (which are nothing more than definition updates never deployed to clients) the package becomes less than 600 MB.

    Moreover, I create, by a Deployment Rule, a new Upgrade Group for every "Patch Tuesday", containing all the Updates released or revised in the last month; all these Update Groups use the same Deployment Package, adding Patches to it every month. Currently it is not far from 20 GB in size and contains 671 Patches for Windows 7 & 8 and Office 2007 & 2010, including superseded and expired Patches. If i select the ones which are expired and not required, and remove them from the Update Group to which they may belong to, and then delete them from the Deployment Package, I can reduce the package size by 1 GB or more.

    Is this a good strategy, or there may be some fault in it?

    Maybe (sure!) there is a way to automatize this process (via PowerShell, of course), I didn't figure out how (yet...).

    (If one could select the Languages and CPU architecture of the Patches, and include only the needed ones, it could be far better... WSUS guys, think about it!)


    Best regards, Stefano Moretti --------------- Namàrië! Nai hiruvalyë Valimar. Nai elyë hiruva. Namàrië!

    Friday, May 13, 2016 6:01 PM
  • > "Deployment packages can be any size and contain any number of Patches (limited only by manageability and system resources)"

    Correct

    > "Every deployment must involve no more than 1000 Patches, however big; this implies (i think) that every Update Group must contain no more than 1000 Patches, because every deployment is based on an Update Group"

    More or less yes. It is possible to deploy a single update without using an update group, but that's rarely done because it's hard to track.

    - Many Update Groups can point to the same Deployment package.

    No. Update groups don't point to deployment packages at all. The client can pull an update binary from any package that the update binary is part of. Deployment packages are merely containers for the update binaries but are not linked to an update group in any way,

    Your strategy is technically valid and more or less what many folks do.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Friday, May 13, 2016 6:13 PM
  • No. Update groups don't point to deployment packages at all.

    Yes, correct, I used wrong words; what I meant is that (e.g. when using a deployment rule) one could use the same package for Patches which are members of different Update Groups. Moreover, a patch could belong to more than one Upgrade Group, and to more than one Deployment Package.

    Glad to hear I didn't make any major mistake!


    Best regards, Stefano Moretti --------------- Namàrië! Nai hiruvalyë Valimar. Nai elyë hiruva. Namàrië!

    Monday, May 16, 2016 2:42 PM
  • One question.  If i removed some Expired updates,   how the already distributed package will work when i remove the updates?  The package size will decrease?  If it decrease does it do it automatically for all the DP?  Thanks
    Friday, August 12, 2016 10:50 PM
  • Yes, the package size will decrease and yes the deletion will automatically replicate to all DPs containing that package.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Saturday, August 13, 2016 12:36 AM
  • Thanks Jason!
    Saturday, August 13, 2016 3:06 AM
  • Hey Jason,

    Hope you're doing good!

    Regrading to this question I've similar question in fact that's happening with me right now.

    We've a Deployment package 14 GB of size, and the distibution was taking ages to distribute to the DPs. What I've done the mistake now is the 14 GB of which was already got distributed to the primary server and DP's near to it. In two secondary servers one is EMEA and other is in APAC were not able to get the content.

    Now I've deleted the content in the targeted package keeping only the last three months patch, and when I redistributed this, I've skipped the NA region and did it to the APAC and EMEA region. But the problem now is still when I reduced the size from 14 GB to somewhere around 2 GB the package size in the SCCM is showing as same as 14 gb.

    What did I do wrong here, when I curb the package and redistributed to the servers it should automatically update the content library.

    Why I am still seeing the old version of the package and as same size.

    Thanks in Advance!


    Regards, Ragotham

    Friday, May 25, 2018 11:02 PM
  • Hey Jason,

    Hope you're doing good!

    Regrading to this question I've similar question in fact that's happening with me right now.

    We've a Deployment package 14 GB of size, and the distibution was taking ages to distribute to the DPs. What I've done the mistake now is the 14 GB of which was already got distributed to the primary server and DP's near to it. In two secondary servers one is EMEA and other is in APAC were not able to get the content.

    Now I've deleted the content in the targeted package keeping only the last three months patch, and when I redistributed this, I've skipped the NA region and did it to the APAC and EMEA region. But the problem now is still when I reduced the size from 14 GB to somewhere around 2 GB the package size in the SCCM is showing as same as 14 gb.

    What did I do wrong here, when I curb the package and redistributed to the servers it should automatically update the content library.

    Why I am still seeing the old version of the package and as same size.

    Thanks in Advance!


    Regards, Ragotham

    Did you try to update package content ("Update distribution point") by hand? If you delete Patches from a distribution package, this is not automatic.

    Look at "source version" and "stored package version" of the package to see if they change after manually updating.


    Best regards, Stefano Moretti --------------- Namàrië! Nai hiruvalyë Valimar. Nai elyë hiruva. Namàrië!

    • Proposed as answer by Ragotham Saturday, November 16, 2019 1:17 PM
    Saturday, May 26, 2018 5:00 PM
  • Hey Stefano,

    First of all I really sorry for the late reply. I was digging my tons of email and found this notification from you.

    Your 100% correct, after manually updating the package <g class="gr_ gr_538 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling" data-gr-id="538" id="538">content</g> the distribution went real smooth without any hustle.

    appreciate your help on this :) 


    Regards, Ragotham

    Tuesday, August 28, 2018 5:55 AM