Hello Guys,

There is a wealth of information regarding Software Updates, via SCCM 2012, on the web. This actually seems to make it quite difficult to develop a Patch Process via SCCM.

Would appreciate any comments or thoughts to what we are planning.

Requirement: To patch our desktop clients (not Servers) using SCCM SU. Products include Win7, 8.1, 10, Office 2007, 2010, 2013, Silverlight. I did not want to split Products up, as I understand the local WU client will only install the updates it requires.

Advice from many sites was to group Software Update Groups into years

SUG: All Updates 2003-2011, 2012, 2013, 2014 and 2015 (Product filter as above was applied)
Each SUG is then deployed to the appropriate collection.

However there are some suggestions about Non-Deployed SUGs? I would not be able to create a general SUG without breaking the 1000 limit, or is that ok if it is not Deployed?

Deployment Packages: Same as above

ADR: Patch Tuesday ADR, runs every second Tuesday, creates new SUG, goes to a Pre-Test/Pre-Pilot Collection with Deployment Enabled. Deployment Package called Patch Tuesday Updates selected.

This Monthly Patch Tuesday SUG will then be deployed to the Pilot Collection a couple of days after release, after 1 week the deployment to the Production Collection.

The updates from that SUG will then be manually added to the All Software Updates 2015 SUG

After the Monthly Patch Tuesday do I manually have to remove the updates in the Patch Tuesday Deployment Package or will the ADR create a new Deployment Package or append updates to the existing package?

To minimise workload, I presume I can create other ADRs to apply the Patch Tuesday Updates to the Pilot Collection and Production Collection without Enabling the Deployment?

Any advice would be fantastic

I STRONGLY suggest you you divide everything by product. The reason is that if you need to troubleshoot it will be easier. The package created with the ADR will be smaller.

The ADR rule can create a new update group every time it run so you will be safe with the 1k limit in software group. SO you don't have to remove the other software group as client will still need them to get the patch. SO here what i would do is i would manually creat software update group for the past year or to what ever you need. Create a new ADR that will run each mount and only contain the update for the past month and make sure they are all divided by product.

With the ADR rule you can't have it create a new package each time it run. So if you put all the update in the same package you will end up with huge package. This might cause issue to distribute to DP and update and like i said will be a pain to troubleshoot.

What i would do with the ADR is enable the auto deployment to the pilot collection. When you are happy with the result manually take that Software update group and deploy it to the other collection.

This is just my 2 cents. I like things clean might require a little bit more work but so much easier in the long term. Think that you might be running this for the next 3 years so as to be clean. Looking at all the product you got if you put all of them in 1 package 1 years would be over 30 gigs

• Edited by Frederick Dicaire 18 hours 32 minutes ago

Thanks for replying, however I am still struggling to see benefits of splitting products.

The ADR will create a new SUG each time which is good for the Compliance Reporting and Evaluation. I don't want the historic SUGs constantly being updated!

As the ADR will always use the same Deployment Package, would I then need to regularly ensure the previous months updates are added to the existing yearly deployment package appropriate for that year?

http://blogs.technet.com/b/server-cloud/archive/2012/02/20/managing-software-updates-in-configuration-manager-2012.aspx - Doesn't really suggest splitting products, but years. Allows Server Teams to create their own Deployments specific to their needs etc.

http://www.windows-noob.com/forums/index.php?/topic/11955-update-compliance-in-need-of-serious-attention/ - looking at a similar setup to this, however this guy doesn't have any Static SUGs so the Compliance Reports struggle as always evaluating

http://www.acupofit.com/2013/08/sccm-how-to-structure-software-updates.html - Some simple and good tips? But not much detail

What i do is i let the ADR run for 1 year. After that i go in the rule and change the package to a new one.

Remove all those software update group and manually make a new one for the past year.

It's about having everything clean. Like i said if you don't split the product the day you will want to update/redistribute or add the package to a new DP it will be huge. Also this might cause other issue i have seen a lot of people in these forums having issue with huge update package.

But this is all what i would do from my experience. It doesn't mean that it would work for you or that it is the best thing to do. 

So let's say you have a windows 7 SP1 gold image. I would manually do 1 software update group for each of the following year 2010,2011,2012,2013,2014 and make one from 2015 to now. i would start my new ADR for next patch Tuesday and for everything in the past month. Keep this up until 2016 than i would add all those update to the 2015 one.

each year il make a new ADR with a new package