Master schedule to update multiple outdated software packages?
Howdy,
I want to look into having PDQ be able to push out updates to software (Chrome, Firefox, Flash, etc) to all our machines. I know that I can create a schedule for Chrome and a schedule for Firefox but is there a way to just create one master schedule and have it go down the list and install Flash to the ones that need it, Firefox to the ones that need it, etc?
Also, what's the best way to handle machines that might be off at the time the schedule runs?
Thanks!
0
Comments
You can, I've been doing that for a little while. If you hold the Control key and click on multiple packages, you can nest them all into a single package. Then schedule that package to run on whatever schedule you'd like.
If Preferences -> Deployments, you can enable the Retry queue for offline machines.
I knew I could group things into a single schedule but can each package in the group have its own target collection? E.g. I only want to push Firefox to the people who already have it but it's out of date. I don't want to install it for anyone who doesn't already have it.
I got ya now, I was thinking of something a little different.
Assuming that you also have PDQ Inventory, I believe it can be done with a few tweaks. Inventory comes with pre-made groups for old versions of FF, Chrome and Flash. So that part is easy.
On the Deploy side, you can create new packages just for updating software, since this would only work for updating. If we look at the Firefox package, in the Conditions tab, I specified that I want it to only run on computers that show up in the Firefox (Old) Inventory collection. If the computer doesn't have Firefox already installed, or if it's current, then it won't do anything.
So you could make these update packages for multiple software titles, specify in the Conditions for each one what collection that they're allowed to do anything with, then bundle them all into 1 Deploy package. I believe that would work.
Ah OK. That would work. I can point the Deployment at the whole database but use the condition to skip any that don't have it installed. Hmm.
I was thinking of doing this, but this would also prevent these packages from being deployed to new systems as well, correct? If you limit the package to only be installed if they are a member of the 'old' inventory collection then if the software is not yet installed it cannot be deployed.
I use the same packages for installing new software to newly imaged computers and I believe this would prevent that. Does anyone know a way around this limitation?
Would I have to create one package for new installations and one for udpates?
Hi Danny Nichols, create a new collection for computer don't have a specific software (e.g. no Firefox, named as "Mozilla Firefox 64-bit (not installed)") and afterwards create a collection that contains both collections, the new "Mozilla Firefox 64-bit (not installed)" and existing "Mozilla Firefox 64-bit (Old)". Wouldn't that do the trick?
That would resolve the issue of not being able to install the package on new systems without the software, but then when running the weekly update schedule it would also install it on all systems even if they didn't have the software already. I only want it to update systems that already have the software installed and not install it for machines without it during weekly update schedule.
An example would be Adobe Acrobat Reader. Some users have pro and should not have reader also (it can be confusing for users and cause other conflicts). So if the package for reader was set up this way, reader would get installed on systems with pro.
The only workaround I've found is to create two packages, one with restrictions for updates and one without restrictions for new installs. It seems that schedules with multiple packages needs an option to add a collection requirement right in the package list of the schedule.
Or maybe I'm missing something?
Ok, got it!
What about using custom fields (tags) with a collection?
For newly created machines configure a custom field/flag which indicates "if not installed do it now".
Would that help?
I don't know much about custom fields. Can you elaborate? Where would the field be placed, on the collection, package, or system?
Custom fields is how PDQ calls tags.
You can set them e.g. on computer level.
Assigned to a machine:
In you case the condition for filter group needs to be "OR" the get it installed on new machines without any existing version of couse.
This field/tag appears now as "column" information for all computer objects and can be used e.g. for collections:
So that would be manually added to a system whenever I want the software installed on it? I feel like that's more work than just creating a second package that doesn't have the limiting collection information. One marked as new install and one marked as upgrade would provide the same functionality, you would just use the 'new install' package for computers without the software. That's what I was hoping to avoid, oh well.
Thank you for teaching me something new with custom fields, I'm sure I could use those in the future. Thanks for all the help, hopefully the collection option in schedules will become a feature at some point.
Okay, I think I figured out how to do this. I was looking in the schedule but instead you want to create a nested package with all of the packages you want to run in one schedule. This way, each package you add inside your nested package list is able to have it's own set of conditions that you can specify what collection to use. So you can keep your original package available for any installation you choose and specify this one for just those 'old' versions of the software.
One limitation is that you can only choose one collection, so if you need more than that add the same package a second time and limit it to another collection. Here's a screenshot of my setup, I hope this helps someone else trying to figure this out.
I use several 'super' packages