Question - What is the best way to make sure updates to core products don’t break existing workflows?
Answer - Deploy new updates to a specific list of machines whose users volunteered (or were volunteered - it’s okay, we don’t judge) prior to deploying to the general population.
It doesn’t matter which industry you’re a part of, whether you’re in the government, education (K-12, Higher Ed), banking, or just a little office with two employees - a bad update or incompatible new software can bring your business to a standstill in an instant. Being able to test updates or new software ahead of time outside of the general user pool is crucial and will keep your business and users safe.
In this post we’ll be going over how to:
Create a group of machines (pilots) to use as test environments.
Create a deployment package for a new update or program.
Create a schedule to automatically deploy that software to those targeted machines.
What Are Pilots and Why Do They Matter?
A Pilot (program, user, group) is a user or machine identified as a viable target to test out new, unknown, or recently updated hardware or (as in our case) software.
Some common reasons to use pilot groups - Chrome Enterprise updates, Microsoft Windows updates, driver updates, GPO changes, or that new “game changer” software solution from your supervisor.
In this example we’re going to schedule a deployment of the most recent Google Chrome Enterprise version - you’ll need to grab the auto-download package from the Package Library beforehand if you want to follow along. We’ll use these filters to target the right computers:
Computers that are under a specific OU in Active Directory (Chrome Pilots).
Computers that do not already have the most recent version of Chrome Enterprise.
This ensures only machines that need this update will have it applied.
How to Create a Pilot Group
Identify users or hardware that would be the most likely to run into any unknown issues. These are power users, specialized machines, machines with legacy hardware or software, machines without AHCI enabled, and any other requirement you have.
Identify how you want to track these machines, as well as what they need to have (or not have). There are countless ways you can do this with Inventory.
Create your collection. We are using the Chrome Enterprise (Latest) collection found in the Package Library.
How to Create Your Pilot Schedule
1. Create a new schedule.
2. Choose your triggers (when the schedule will run). We’re using just the Heartbeat trigger here because we want to ensure that all pilot machines are updated as soon as they come online.
3. Choose your targets. Here, we’re going to be using the collection we created in Inventory.
4. Finally, attach the Chrome Enterprise package from the Package Library.
Conclusion
That’s all there is to it. In our example above, computers in the Chrome Pilots OU in AD that do not already have the latest version of Chrome Enterprise will now have it installed. Thanks to our dynamic collection in Inventory and the auto-updating package from the Package Library, this process is now completely automated!
All you need to do is ensure your computers are in the right OU in Active Directory, and PDQ will handle the rest for you. Keep in mind that this is the most basic and barebones way to handle this within PDQ - there are countless ways to customize each step of this process to meet any requirements you have.
A lot of times when deploying to pilot groups you may find the need to roll back your software which we also have covered.
