In Part 1 of this blog series, “PDQ Automated Software Deployments,” you created and set up schedules, and now you’re patching your machines. But, what if you didn’t want to patch all of your machines at the same time? Maybe you want to set up a pilot group to test patches before rolling them out to production? In Part 2 we’ll cover how to create some inventory collections and duplicate your auto-download packages to do just that.
First things first, we need to setup our collections so we can effectively target our test group. For my test group I’m going to use five machines:
The first thing I’m going to do is create a static collection of these machines called “Testers,” (this could also be a dynamic collection, but getting our test machines into a single collection is the goal):
Duplicating a Collection
Try PDQ Deploy
Next, I’m going to duplicate a Collection Library collection so I can modify it. We’ll use the “old” collection for this so that we can test the latest and greatest patch from the library. For this case, we’ll set up our pilot group to test out Mozilla Firefox ESR:
After the collection is duplicated, it will show as a regular dynamic collection we can modify. We’ll change this collection so that it still evaluates computers to see if they have an old version of Firefox ESR, but will also only assess against our five testers.
At this point, we now have our targeting setup. We can shift gears to PDQ Deploy and set up our auto-download package, and schedule for these testers. First, we’ll download two copies of the ESR package; the first will be for our testers, the second will be our package for production, make sure to rename them, so they don’t get confused:
Modifying the Default Auto-Approval for Our Automated Software Deployments
Next, we’ll modify the default auto-approval window on our “testers” package, so it immediately updates after there is a new version in the library while leaving the production package set to our default approval window:
At this point we have two packages for Mozilla Firefox ESR, one that will immediately update itself for our testers, the next will update based on your preferences. All that is left to do now is set up a schedule for your production package (see Part 1) and set up the second schedule for your testers.
To set up a schedule for our testers, we’ll get a bit aggressive with our triggers to make sure that it gets quickly deployed. Then, we can start to get feedback from our pilot group. If something should go horribly wrong you have some time to disable the schedule targeted at your production.
That’s it! You’re done. You now have two packages, two schedules, and two collections to target. Computers in your test group will get updates for ESR immediately, and you have some time to make sure that everything goes off without a hitch. Wash, rinse and repeat this process for as many other packages as you wish. You can now rest easy pushing out packages using PDQ’s automated software deployments. Check out this video too, if you missed it in my first post.