Software Updates Structure

[SMSNewb]

Hello everyone,

 

I was wondering if anyone could give me some help setting up my software updates.

 

I understand the concepts and such, but I struggling with setting up the Update Groups and Deployment Packages.

 

From what I am reading, a lot of people are saying to create a Update Group per month, every month, then eventually roll these updates into a yearly software update group. This makes sense to me. My question is, should I have software update groups per product? Example, one for Windows 7 and one for Windows 8.1? Or should I just have one software update group per month, with all the products I need to support? I'm aware that the client will only grab the updates it needs if its all in one.

 

Should I have one single deployment package? Or several, one for each product?

 

I'm really looking for best practices. Or any "gotchas" from people who have been doing software updates through SCCM for awhile.

 

I realize the general answer will be "it depends on your environment", so I'm really just looking for some tips/suggestions/guidance that will help streamline the process

 

Appreciate any help/suggestions

[nry]

I've only ever followed the guides on here, so we have one group for Win7, one for the Server OS, one for Office, one for SQL Server...

 

Seems to work fine here.

[wilbywilson]

I would suggest breaking them into different update groups, but not necessarily 1 per operating system. The way I like do it, is to put all of the "workstation" (Win7, Win8, Office, etc.) patches into 1 group, all of the "server" (Windows 2008, Windows 2012) patches into another group, and perhaps special/custom apps (IIS, SQL, Exchange, etc.) into yet another group. Once those are built and deployed to some test machines, then I set up a deployment for each group. The deadlines for workstations is obviously different than servers, so that's why I like to build my update groups like that.

 

So you may be different, but I like to build my update groups based on the "type" of machine they were targeting, and then set my deadlines accordingly. And yes, I do recommend consolidating these update groups at least once a year; otherwise there are just too many deployments running, and it's hard to make sense of what's what.

 

 

Hello everyone,

 

I was wondering if anyone could give me some help setting up my software updates.

 

I understand the concepts and such, but I struggling with setting up the Update Groups and Deployment Packages.

 

From what I am reading, a lot of people are saying to create a Update Group per month, every month, then eventually roll these updates into a yearly software update group. This makes sense to me. My question is, should I have software update groups per product? Example, one for Windows 7 and one for Windows 8.1? Or should I just have one software update group per month, with all the products I need to support? I'm aware that the client will only grab the updates it needs if its all in one.

 

Should I have one single deployment package? Or several, one for each product?

 

I'm really looking for best practices. Or any "gotchas" from people who have been doing software updates through SCCM for awhile.

 

I realize the general answer will be "it depends on your environment", so I'm really just looking for some tips/suggestions/guidance that will help streamline the process

 

Appreciate any help/suggestions

[SMSNewb]

Will grouping all the desktop level operating systems get you close to the 1000 update limit for the software update group?

 

Are you relying on ADR's to do your monthly SUGs or are you manually doing this?

 

How many deployment packages do you utilize? 1 for desktops, and 1 for servers?

 

I would suggest breaking them into different update groups, but not necessarily 1 per operating system. The way I like do it, is to put all of the "workstation" (Win7, Win8, Office, etc.) patches into 1 group, all of the "server" (Windows 2008, Windows 2012) patches into another group, and perhaps special/custom apps (IIS, SQL, Exchange, etc.) into yet another group. Once those are built and deployed to some test machines, then I set up a deployment for each group. The deadlines for workstations is obviously different than servers, so that's why I like to build my update groups like that.

 

So you may be different, but I like to build my update groups based on the "type" of machine they were targeting, and then set my deadlines accordingly. And yes, I do recommend consolidating these update groups at least once a year; otherwise there are just too many deployments running, and it's hard to make sense of what's what.

 

 

[Garrett804]

I do mine by Months, Quarters, Years.

 

I have an ADR that runs once a month that makes a new group each time it runs. Then when I get past a Quarter I make a Q1 group which has all the updates released or revised between 1/1/2016 and 3/31/2016. etc.. Q2, Q3.. Q4..

 

I consolidate the months to quarters removing the individual month groups and the same goes to Quarters to make a yearly group. I make sure not to hit over 1000 updates which does cause usually the Q3 or Q4 groups to stick around because of the amount of updates. Once I can consolidate a group down I do though.

[SMSNewb]

Is the 1000 update limit on the Software Update Group or the Deployment Package?