Hi there

Currently we have different deployment packages and software update groups based on year, product, etc.

In the near future i'd like to rearange our software deployment process in configuration manager 2012:

1x Deployment Package for all updates
1x "Full" Software Update Groups with all updates in it. Additional to that we'll create a "Diff" Software Update Group at the Patchday and merge the updates later via edit membership in the "Full" Software Update Group.

Are the following steps which i would perform correct?

1. Select all updates which are deployed and not expired and not superseeded
2. Create a new Software Update Group "Full"
3. Select the new Software Update Group --> Download --> Create my new deployment package
4. Deploy the new software update group to my collections
5. Delete the obsolete software update groups / deployment package
6. Delete the old updates source folders on our filer.

I current don't know if the redownload process let the updates "forget" the old deployment package. With the above described steps i should get rid of all expired and superseeded updates.

Thanks for any advice :-)

Regards,

Simon

Should work, but I'd move steps #5/6 before step #1. #6 should happen automatically if you're on SP1.

Great, thanks for the quick answer.

But if i first delete the software update groups i will loose all the deployed updates which are the base for creating the new full software update group.

• Edited by SimonD_CH Monday, December 30, 2013 9:30 AM

Sorry, I mis-read your question then. I thought you wanted to delete the expired/superseded updates (not the update groups). So you can leave

Perfect, thanks :)

Simon, the steps above will do the trick but I would like to ask why you want to change the stuff. I imagine that you can bump into issues with maintenance Windows if you to mange objects in your update Groups.

I would strongly discourage you from doing the above.

Having one monster package that is multiple gigs in size is not a good thing -- what happens if you need to assign that package to a new DP or the package is corrupted in some way? Using a single package provides no advantages whatsoever but has multiple potential downsides.

Also, using one update group for all updates greatly increases the processing and storage requirements of the clients and has been linked to WMI bloat as well as task sequence failures. You should have at least a couple of different update groups to target subsets of managed systems.

Well, my understanding was, that the client only receives and install any updates which are needed, like the wsus agent.

How about creating a software deployment package for every year? Let's say: "Software Deployment Package 2013".

During the year i would create come software update groups called "January 2013", "February 2013", etc.

At the beginning of 2014 i would move all 2013 software update groups to one single "2013" update group.

Is that better or are there any best practices for woking with software updates?

• Edited by SimonD_CH Friday, January 03, 2014 3:44 PM

That is correct they only receive and install the updates they require, but don't confuse the metadata and deployments with the updates themselves. They will still receive the metadata and the policies for every update you deploy to them and that's where the problem lies. Each and every update assigned to a client (using a deployment) has it's own policy which of course must be downloaded by the client and stored in WMI causing the bloat. Note that I haven't experienced this first-hand but am relying on the accounts of others here in the forums but to me, if there is any chance of this being an issue, I would avoid it.

For Update Groups, just a few categories is sufficient to break things up and I typically do three: workstations, server, office. These are often on different patching schedules anyway so it makes sense to have three separate ADRs for them anyway.

For packages, I typically organize based on the calendar creating a new package every 3-6 months with the package containing all updates. There's really no need to divide the package up by product unless you have DPs dedicated to a specific product. Note that pre-R2, to change the package an ADR referenced you had to use PowerShell -- it's been added into the GUI in R2 though.

Thanks for the detailed description.  In our organization there are currently 320 Updates deployed (Windows 7, Server 2008 R2, Office 2010, and a few minor products).

We only distribute the updates which are required by the clients. I've search the deployed updates by year, i will have approximately 60 updates per Year which are deployed to all our devices.

Is my way with creating a software depl. package every year really a "no go" with, i think this little, infrastructure?

• Edited by SimonD_CH Friday, January 03, 2014 4:08 PM

First, don't confuse software update packages with software update groups -- they are two completely different things.

As for a package every year, I do recommend creating them on some type of calendar basis and yearly was the traditional way I recommended. Lately though, the updates have been increasing in size causing the update packages to get bigger and thus less manageable and thus the reason I've shifted my recommendation to every 3-6 months. There is no increase in overhead or effort by breaking them down more often than yearly.

Hi jason,

At the end of each 3 month period how do you point your ADR to a new Deployment Package for the new 3 month period?

Do you delete the old ADR and create a new one or run a PS script to change the Deployment Package target? (We are on SP1 so don't have the extra tab for this that's present in R2)

Thanks



• Edited by andrewjohnporter 5 hours 23 minutes ago

Hi jason,

At the end of each 3 month period how do you point your ADR to a new Deployment Package for the new 3 month period?

Do you delete the old ADR and create a new one or run a PS script to change the Deployment Package target? (We are on SP1 so don't have the extra tab for this that's present in R2)

Thanks



• Edited by andrewjohnporter Wednesday, July 22, 2015 2:27 AM

Either upgrade to SP2 or use PowerShell:

http://www.petervanderwoude.nl/post/changing-the-deployment-package-linked-to-an-automatic-deployment-rule-in-configmgr-2012/