Automatic rule and package size
Hi Guys,
We've set an automatic rule for windows patching... to download on patch Tuesdays and deploy to our pilot machines. However, the deployment package is getting bigger and bigger. It's up to 2gb now. I only want the package to have last months patches
and purge the rest. Is there anyway to accomplish this?
Thanks in advance.
- Edited by
gdpt
Monday, February 10, 2014 11:49 PM
February 11th, 2014 1:38am
Yes, just go to the package itself and remove the updates.
Why would you not want to have older updates available though? What happens when a new system enters the organization? How will it get all of the updates?
February 11th, 2014 6:12pm
Thanks for your reply Jason.
So there is no automated way of cleaning up the updates in the package? I was hoping it could somehow be done as part of the automatic deployment rule. How have you kept the software update package size to a minimum?
The older updates are available from a different software update group. We've grouped it every quarter.... 2013 Q4, 2014 Q1 etc. So this package will only hold a maximum of 2 months worth of patches to avoid the 1000 item limit and size. If you have
any recommendations, please let me know, and I'll take it on.
- Edited by
gdpt
Tuesday, February 11, 2014 11:17 PM
February 12th, 2014 2:07am
There is no 1,000 update limit in a package -- don't confuse packages and update groups, they are two very different things. So which are you talking about? Both is an invalid answer because as mentioned, they are completely different things.
February 12th, 2014 5:45am
Sorry, I meant package. And thanks for correcting me on that one.
February 12th, 2014 6:11am
So, you are saying that you have the same update in multiple update packages? If so, why'd you do this in the first place? You do know that there is no connection between update groups and update packages whatsoever and that a client will pull an applicable
update from *any* available package regardless of any other factors?
Ultimately, it's not a big deal though as one of the main reasons that they created the single instance store content library is for duplicate updates in multiple update packages.
February 12th, 2014 5:32pm
Appreciate your reply.
No, the update group prior to 2014 are just there to check compliance. There is no deployment packages created with it.
Yep, I now understand there is no correlation between the 2.
So with the ADR, how have you kept the package size to a minimum? As new patches just keeps adding to it. Can't seem to automatically create a new package. Any best practice or ideas would be great.
Thanks again
February 13th, 2014 8:15pm
Yes, just go to the package itself and remove the updates.
Why would you not want to have older updates available though? What happens when a new system enters the organization? How will it get all of the up
February 13th, 2014 9:32pm
For the package size, you simply create a new one manually every 3, 6, 9, ... months (take your pick) and then reassign the package in the ADR. Pre-R2 you will have to do this with PowerShell. Post R2 you can do it in the UI.
As for the compliance groups for older updates, what happens when a system comes online that needs an update? Older updates typically already have exploits in the wild for the vulnerability that they fix so that system is at risk (as is the rest of the organization)
because the update isn't available.
February 13th, 2014 9:44pm
Absolutely its realistic. What's the cost to doing this? A few GB of cheap disk space?
Deploying updates as they are required is being reactive which IMO is asking for a vulnerability to be exploited. IMO, being proactive is a much safer course of action with really no true down-side (except disk space which is cheap).
February 13th, 2014 9:47pm
Cool. Looks like we'll create a new package every quarter. Thanks
- Edited by
gdpt
8 hours 40 minutes ago
February 13th, 2014 10:44pm
Absolutely its realistic. What's the cost to doing this? A few GB of cheap disk space?
Deploying updates as they are required is being reactive which IMO is asking for a vulnerability to be exploited. IMO, being proactive is a much safer course of action with really no true down-side (except disk space which is c
February 13th, 2014 11:25pm
Cool. Looks like we'll create a new package every quarter. Thanks
- Edited by
gdpt
Friday, February 14, 2014 3:39 AM
February 14th, 2014 6:39am
Yes but only for products in-scope in the organization. I have never seen anyone do server applications so typically its just for the various Windows and Office flavors and Silverlight.
February 14th, 2014 11:28am