SCCM - How to deal with Software Update Groups & Deployment Packages

[rom1984]

Hi,

Bit of a SCCM question that I'm not sure about...

 

I've started pushing Windows update out via SCCM and wanted to check that I have understood it correctly. I've gone to All Software updates then filtered just the updates that I need (i.e Server 2016, no expired, required etc). I create a software update group which includes the filtered updates and call it "Server 2016 Updates October." I then deploy this update group by creating a deployment package called Server 2016 updates.

 

My question, next month when I do the Server 2016 updates for November. Do I use the same deployment package? I.e do I create a new software update group called "Server 2016 Updates November" and then deploy it using the package called "Server 2016 updates" or do I need to create a new deployment package for it?

 

Thanks

[sparkeh]

You can do it like that, but I don't.

 

I have an ADR for each OS I want to update, that runs once a month and updates the software update group and deployment package with the current, applicable updates. Makes it more simple.

[Linfit]

Short answer is yes. For monthly updates its recommended you create a new update group, as otherwise they get very big and there is a limit of 1000 I think on the number of components they can have.

The best way for monthly updates though is to create an automatic deployment rule - this will do the exact same process but automatically, so you don't need to remember to go back and create a new deployment. Its very easy to do once you understand how updates and packages work, and there are lots of guides on the interwebs

[rom1984]

Great thanks for the replies.

 

So an ADR to create a new software update group, but then you use the same deployment package? So over the year there will be say 12 x Windows 10 software groups, but only one Windows 10 deployment package that will contain all the relevant software update groups.

[Geoff]

I do my ADRs like this:

 

I have a 'Security Patch Tuesday' ADR and update package for each Windows OS and MS Office. This has three deployments, 'Zero day' to my Test VMs, '1 Week' to my testing group (IT, HR trainers, volunteers), '2 week' to everyone else. This runs monthly on Wednesday morning after Patch Tuesday.

I also have an 'Office Update Tuesday' ADR and package for MS Office, same deal as above, but for office critical updates etc. These come out on the first Tuesday of the month so that is what it is scheduled for.

 

For 'historic' stuff, I have a package for each OS / Office split per year. I used a powershell script to create this.

 

http://www.scconfigmgr.com/2016/03/26/create-a-software-update-group-defined-by-date-in-configmgr-with-powershell/

 

The bottom line is it is up to you how you do it, what ever works best for the amount of time you can spend on SCCM and how 'curated' you want it to be.

Edited October 19, 2017 by Geoff

[Linfit]

Great thanks for the replies.

 

So an ADR to create a new software update group, but then you use the same deployment package? So over the year there will be say 12 x Windows 10 software groups, but only one Windows 10 deployment package that will contain all the relevant software update groups.

 

Yeah, thats it, because you only need to defined the scope of the updates you are looking for (date, type, product, etc) once, but obviously the bundle of updates that catches will change each month.

Edited October 19, 2017 by Linfit

[rom1984]

Yeah, thats about the size of it.

 

Cheers bud much appreciated!

[psydii]

Using the method described above, how are cumulative updates (windows 10 and Office) dealt with? So say a freshly imaged Windows 10 1703 machine is in scope for updates: Does the client install all the cumulative updates since its March release, or is only the latest one offered?

[sparkeh]

I set my ADRs to only deploy current update so every time a new CU comes out it evaluates the updates , removes the old one and adds I the new one.

[gaz350b]

(Probably more info than you want but here goes)

 

We have 1607, 1703 and now 1709 device collections with a query based upon Build number.

 

Each asr has its own deployment group. We also have additional separate asr rules for defender updates etc.

 

As for ASR’s for Windows, We have 2 asr rules for each windows 10 build, 1 for critical updates and 1 for “updates and roll ups” I think. These are then deployed to unauthenticated computers and the device collection and an early test group.

 

The critical ASR groups have filters based upon title (%1703% for example) superseded = no and Windows 10 product group.

 

We give 5 day plus 3 day deadline for critical updates and 4 weeks +3 days on updates.( test collection is half the time)

 

All our desktops have maintenance windows between 7.30-8.30, 12.00-1.30pm and 3.40-6pm. In our client settings we have also given the restart notification of 2hours before its forced upon them.

 

We have also educated users on why we force it upon them but give them the flexabilty to do some work and restart at a natural time for them (lunch breaks for example)

 

Also becareful on where you store your deployments. We mirror our storage layout o be similar to our asr groups.

 

Windows 10

-1703

— updates

—critical updates

1709

—updates

 

If you accidentally store a software deployment in the lower folder structures you will end up with empty folders the asr will delete files, even though sccm will report the updates as deployed at the DP. (Green pie chart) and your clients will fail to download the update!

Edited October 19, 2017 by gaz350b

[ADMaster]

I do mine a bit different from everyone else here, maybe I need to rethink it so reasoning welcome.

I have a deployment package for each year and create a new one each January.

I have 3 fairly current deployment groups +n years back.

The only ADR I have is definitions.

 

Each month I filter for 'needed' updates of all my supported products and put them in an update group

2017-10 for this month.

I then would take the previous months updates 2017-09 and put them in the 2017-all group.

Then I delete the now empty 2017-09 group.

Anything in the 2017-all group is scheduled for immediate install and reboot regardless of maintenance window.

The current month is scheduled with a two week deadline and a prompt to reboot, but it can be suppressed.

 

This effectively gives them a month to do the updates.

 

This is workstations of course, I never force a reboot on servers ,but they do have maintenance windows.

[free780]

I'm swaying to a ADR with a 3 day delay for a fast ring (10% of clients) and slow ring for the rest. Servers need grouping off low,med,high critical and manual. Though the time it takes for updates to install means the WUA will continue past the maintenance window.

[Geoff]

The rest of my IT team doesn't trust it for servers yet. I just have it on a few non-critical servers at the moment. Need to build some trust up.

[sparkeh]

To be honest I still don't use it on servers, I like to patch manually and test each server. But then I don't have many to patch

[Geoff]

70 VMs

8 Pyhsical.

 

[owen1978]

I have just started delving into using SCCM for patching...

 

Trying to get my head around a few things...

 

I have followed some youtube videos & some articles, where they suggest creating SUG based on year and not products.

 

So for 2018 for example, have security updates pulled down for Server 2012 & Windows 8.1, which have been filtered so they have not expired and not super ceded. and then add them to a SUG called Year 2018.

 

And then deploy that... the reason being I think that the SCCM client which then deploys the updates will automatically update the correct machines with the correct patches.

 

So splitting SUG by product is a waste of time.

 

Is this correct?

[sparkeh]

Personally I don't see the benefit in grouping updates by years and group them by products as below:

 

 

This way, each software update group used by the ADRs can be targeted at a collection with the machines that need the updates. So for example, the Windows 10 1903 machines only need to evaluate the updates for 1903 to see if they need them. Why make machines evaluate loads of updates that you already know they don't need?

[browolf]

will sccm install software on windows installs that have been deployed by fog?

[sparkeh]

will sccm install software on windows installs that have been deployed by fog?

Yeah, as long as the sccm client is on it doesn't matter how the OS is deployed.