Software Update Management strategy should be decided first. Most of the readings and articles that I have read was telling creation of Software Update Groups based on products. Because that approach of SUG management is too hard for the administrator, I thought that there must be an alternative way of doing it. Finally I found a video named " SCCM 2012 SP1 and the new way handling Software Updates explained" which is made by MVP Kenny Buntinx. Kenny Buntinx advises creating software update groups not by product but by the date updates released. In my article, I am implementing Kenny Buntinx's strategy.
The idea is,
Creating Software Update Groups yearly as 2003thru2010, 2011, 2012, 2013. We will create these yearly SUGs manually. These are our year based SUGs. Then we will create manually month based SUGs 2014 1. month, 2014 2. month, 2014 3. month and so on. We will also have a Automatic Deployment Rule (ADR) for new SUGs. New updates will be created by the ADR.
We will have a separate SUGs for every month. Because if we were using the same SUG, its content would be changed with new updates every month. This cause client agent to scan the same software update group which also has old updates every month. That is a burden for both SCCM and client. Therefore SUGs should be kept monthly for year 2014 (current year). We will have only one Software Deployment Package for every year.
We need to do maintenance yearly. When year 2014 is over, We will create a new Software Update Group named 2014AllUpdates and we will edit the membership of the monthly updates of 2014. Basically we will be moving 2014monthly updates to the SUG named 2014AllUpdates . Then we will delete the 2014 monthly SUGs because they will be empty and unnecessary. The number of updates in a SUG should not be more than 1000.
Update Packages:
Critical: Broadly released fixes for specific problems addressing critical, non-security related bugs.
Security:Broadly released fixes for specific products, addressing security issues.
Update Rollups: Cumulative set of hotfixes, security updates, critical updates, and updates packaged together for easy deployment. A rollup generally targets a specific area, such as security, or a specific component, such as Internet Information Services (IIS).
Feature Packs: New product functionality usually included in the next full product release.
Service Packs:Cumulative sets of all hotfixes, security updates, critical updates, and updates created since the release of the product. Service packs might also contain a limited number of customer requested design changes or features.
Tools: Utilities or features that aid in accomplishing a task or set of tasks.
Updates: Broadly released fixes for specific problems addressing non-critical, non-security related bugs.
I will just update my computers with Security and Critical updates. You can decide what updates you will download according to the information above.
Now we will create a SUG for 2003-2010 updates. Navigate to Software Library/SoftwareUpdates/All Software Updates. Click "Add Criteria" button (It is located next to the search box). We will exclude Beta updates,we will search for updates between 1January2003 and 31 December2010, We will also exclude Superseded and Expired updates, update classification will be security and critical updates.
Title
Date Released or Revised
Expired
Superseded
Update Classification (Add this twice)
After you add and specify the criteria, hit search. This brings the updates based on your search criteria.
Select all updates and right click, then select "Create Software Update Group"
Give a name to this SUG, I named it as 2003-2010AllSUGroup. Right click on the SUG and select "Show Members". In search box type in Itanium and hit enter. Select all the updates and right click on them, choose "Edit Membership"
Remove the check from next to 2003-2010 All SUGroup. This will remove Itanium updates from our SUG.
SUG for 2003-2010 is ready. Now you need to create SUGs for other years 2011, 2012, 2013. The steps are almost the same, just make sure in your criteria, Date Release or Revised should be covering years 2011, 2012, 2013.
You also need to create SUGs manually for the passed months of 2014 (in other words the year you are in)
You can see the end result in the picture below.
Deployment Packages:
We created all the SUGs. Now we need to create Deployment Packages. First create a folder for each yearly SUG under \\sccmserver\Sources\Updates\. Updates will be downloaded to these folders. Create these folders:
2003-2010AllUpdatesSUFolder
2011AllUpdatesSUFolder
2012AllUpdatesSUFolder
2013AllUpdatesSUFolder
Right click on Software Update Group named 2013-2014 All Updates SUGroupand select Download.
Select Create a New Deployment Package, browse the folder path you just created. This action wil create the deployment package.
Right click on other yearly SUGs (2011, 2012, 2013 SUGs),and select download and create the Deployment Packages.
For 2014 monthly SUGs, it will be a little bit different. First create a folder named 2014AllUpdatesSUFolder under \\sccmserver\Sources\Updates\. Right click on 2014 1-Month SUG and select Download. Choose Create a new Deployment Package and name it 2014 All Updates Deployment Package. When you completed creating the Deployment Package, you can select other 2014 monthly Software updates groups and select download but make sure you DON'T select "Create a new Deployment Package". You should select "Select a deployment package" and browse 2014 All Updates Deployment Package. Our goal is to have multiple monthly SUGs but to have only one Software Deployment Package for each year.
After you created all SUGs and Deployment packages, you can deploy them to the target collections. Just right click on the SUG and select Deploy. For the coming new months we will be using Automatic Deployment Rule (ADR). ADR will create SUGs automatically and keep them in a Deployment Package. This subject will be mentioned in the next reading.