Jump to content


SMSNewb

Software Updates Structure

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.