Don't split updates up by product name! It’s a waste of time. The client agent on the local machine will determines product categories automatically and only downloads the updates that are needed! Instead separate and name your software update groups by periods of time. Start with 2003-2010 as updates only go back to year 2003 and all the updates up to 2010 should fit in a single package. Subsequent groups should be broken up by individual year 2011, 2012, etc. Keep update groups under 1000 updates or you will have problems. Make updates REQUIRED for Workstations. Make updates AVAILABLE for Servers. Tell application owners it’s their responsibility to install and reboot their servers. Clarify that “No Reboot = Not patched” in most cases! Reboots must be planned when installing updates! At the same time try to identify those servers that can be patched and rebooted automatically without having an impact on your user base.
Every time a software update group changes the agent has to rescan all the content of that group. For this reason you want to keep automatic update groups to a minimum! This is both in terms of the number of automatic update groups you create and the amount of updates they are allowed to contain. Create static (or non-automatic) software update groups to store your updates from previous years while limiting automatic updates to a timeframe of the last month, week or day. Not only does this make updates easier to manage it also reduces the load on both the SCCM server and the SCCM clients as update agents won’t have to constantly parse a bunch of old updates every time new updates are released! To reiterate: Use static groups for older updates and organize by year! Use automatic update groups for monthly and daily updates only!
When you create the packages for your update groups make sure to name them by year as well. You want to use a year-based package name for your automatic monthly updates as well as they will eventually be moved to a year-based group anyway. So automatic monthly updates that take place in year 2013 should target your "All Updates for 2013" package. You should plan to do yearly maintenance where you move all the automatic updates for the previous year into a static group (almost like archiving) while creating a new automatic group and year-based package for the incoming year. Also using one yearly package for all updates means you only have one package to monitor during deployments. This is done in the SCCM console under “Monitoring -> Overview -> Deployments”. The compliance column there is your exact compliance figure for the collection you are targeting (as opposed to the compliance column in the software update groups view which is for ALL SYSTEMS).
Additional tips and items to consider:
- Microsoft best practice is to patch per month, forget quarterly it’s too complicated.
- Enable delta updates for Distribution Points to get updates out faster and reduce server load.
- Create alerts for updates, start with 75% compliance at first. Then move up to 80, 90, etc.
- Updates need to go out to Pre-Production be 7-14 days out from Patch Tuesday, then wait another 7-14 days before deploying to Production.
- Create Deployment Templates! These will allow you perform manual software update-related actions very quickly. For example: Have a template to push out day 0 critical updates immediately.