Microsoft Update Tuesday…Blah!
I absolutely dread Microsoft Update Tuesday. I think I dread it the most because I use System Center Configuration Manager (SCCM) to deploy software updates. Originally, when first deploying SCCM, I’ll admit that I didn’t spend quite enough time thinking through how sustainable the methodology that I configured would be. Now that I have 3 years worth of updates in SCCM, I decided that some changes need to be made to our methodology because it takes me too long to deploy new updates. So let’s see what configuration settings I can change to make this process a little easier and less time-consuming for me.
A Little About Our Environment
I have configured our SCCM environment with 1 Primary Site and 11 Secondary Sites which are geographically dispersed throughout the state, Ohio and Massachusetts. The Primary site has the Software Update Point site system installed. I utilize Update Lists to keep the updates organized and categorized. I categorize by update type (i.e. Security, Critical, Updates, Update Rollups, Service Packs, etc.) and year (i.e. 2009, ’10, ’11). This makes it easy to find specific updates and to later combine them into packages.
In the past I would divide the Deployment Management Advertisements along these lines as well. This was a terrible idea originally as I soon found out after 1 year of doing things this way that it would continue to take more time in the long run–as more years accumulated.
So instead of having multiple Deployment Packages, I combined all of the Security, Critical, Updates and Update Rollups into one package. Judging by the size of the source folders of the updates (since I’ve already downloaded them all on the Software Update Point at the Primary site) I am under the 4GB package size limit (yes there are size limits and can include a maximum of 2000 updates). All of these updates weigh in at 1.81GB. I also should add that I screen updates that go into the Update Lists initially and we are not a multi-lingual company; English is all that’s required.
Go into Update Lists and in the right pane select the Update Lists that you wish to combine the updates included into one Deployment Package. Right-click and select Deploy Software Updates.
In our environment we give users the option to install updates at their convenience giving them 7-days to do so. At which time, the updates will automatically deploy. We also do not reboot machines during work hours except during designated Maintenance Windows. We have a mid-day Maintenance Window from noon-1pm and a countdown of 60 minutes for Advertised Programs (which includes Software Updates deployments). Thus, setting the deadline to 11:00 AM will ensure that updates fire at the beginning of the Maintenance Window.
This schedule is different for our servers as we only give them 24-hours for updates to be deployed so there is a different Deployment Template for servers.
When the wizard is complete all of the updates will be re-downloaded to the new source folder that I designated and in turn copied to the Distribution Points that were selected. Now the Deployment Packages are centralized in one place and cumulative.
The Future and Beyond
When new updates become available from Microsoft, I simply add the updates to the correct Update List and also to the 1 Deployment Package. Then create another Deployment Management Advertisement for the month to redeploy the updates again and that is all I will have to do for next month. So at most I will have to create 2 Advertisements–1 for servers and 1 for clients.