Hello all!

We have some overlap in our Update Lists. For example we maintain a Windows 7 and a separate Windows Server 2008 update lists. Commonly, a single update will apply to both Win7 and W2K8R2, and therefore the update will appear in both Update Lists.

So every month when I update our Update Lists with the latest monthly patches, I choose to download the updates into a Deployment Package. I have a matching deployment package for each update list. For example: W2K8R2 Update List downloads to W2K8R2 Deployment Package.

This setup appears to waste storage space on my server by downloading the same update to multiple deployment packages. Is SCCM not smart enough to not 're-download' an update that already exists in another package? Is there a way to set this up differently that would work better?

Thanks for any advice provided.

It will download the updates if you tell to do so, but you could use the same package for your monthly update lists.

Thanks. We used to use just one deployment package, but had a problem with it getting corrupted to so we had to re-download everything again. Since then we have tried to keep smaller packages. I may have to look at reorganizing our packages then to save space/download time on the server, if there is no other way to automatically handle this.

For update packages, smaller is definitely a good thing, but unless you have a specific reason to separate the updates into packages by OS, there's no reason to do this. Instead, you can simply create one update package for all updates on a yearly, semi-annual, quarterly, or even monthly basis. There simply is no reason to separate them by OS or corresponding to your update lists or deployments; as you've pointed out, this wastes space.

Thanks Jason. Question: If I re-download all of my updates into non-OS/Product-specific packages, and then delete all my old packages, will all of my existing deployments and update lists be able to 'auto-magically' find the patch files in the new packages? Or will I need to re-create my deployments and update lists as well? Thanks again.

To answer the spirit of the question, no this will not cause issues; ConfigMgr will know where the binaries for the updates are even if located in a "new" location -- it stores the location of the downloaded binaries each time they are downloaded and this location is associated with the update itself thus any and all locations are valid and given to the client when it requests an update. If you delete a package or remove an update from a package (using the console of course) then the reference between the update and that location is also removed.

To directly answer the question though, update lists don't know about the update binaries or their status at all. The update list does list updates, but it's the updates that are associated with the binary location, not the update list.

Thanks again for the great advice and explanation Jason.