There’s no question that when it comes to deploying applications, PDQ Deploy is the bee’s knees. Nothing’s easier than downloading an application from the package library, pointing it at a bunch of computers, and smashing the “Deploy Now” button. It’s fast, doesn’t require much thought, and most of the work is done for you by the wonderful folks here at PDQ.com, thanks to the pre-built packages in the package library. This approach, for the most part, is fine, especially in smaller network environments. However, once you start managing and deploying to thousands of devices, this approach of deploying first and asking questions later may lead to sluggish deployments and unnecessary network traffic.
PDQ Inventory, speeding up your deployments
PDQ Inventory is the MacGyver of the sysadmin tools. On its own, PDQ Inventory is incredibly versatile. If you want to learn more about some of the things PDQ Inventory excels at, check out our "Most Asked Demo Questions" blog post, where I highlight a few of my favorite features. Today, we'll focus on PDQ Inventory features that help take our deployment game to the next level. If you don't already have PDQ Inventory, don't feel left out. You can still follow along by downloading our 14-day free trial.
Breaking down dynamic collections
Dynamic collections are your deployment's best friends. Instead of just blasting out deployments to your entire organization, dynamic collections make it easy to target only the machines that need what your deploying. Let's see how it works.
The image above is a screenshot of PDQ Inventory's Collection Library, which itself is made up of a ton, and I do mean a ton, of pre-built dynamic collections. To be a little more precise, PDQ Inventory comes with over 1,100 collections baked in. While it's true that we don't have a collection for every single application or trojan available on the internet, we pride ourselves in covering a vast majority of the popular and even some not-so-popular applications.
To understand how these collections work, let's focus on one specific application and break down what's going on.
Here we have the PDQ Inventory's dynamic collections for Chrome. The keyword here is "dynamic." Dynamic means that the members of the collections change as different conditions are met. By comparison, a static collection's members never change unless someone manually changes the memberships. As you can see, the Chrome dynamic collection is broken down into more specific sub-collections, Chrome Enterprise (Latest), Chrome Enterprise (Not Installed), Chrome Enterprise (Not Installed - Workstations), and Chrome Enterprise (Old). The collection names are pretty self-explanatory, but you can click on any of the collections to view a more detailed description.
If you want to know how any of the dynamic collections work, you can double-click on them to see the specific collection filters. Here are the filters for the Chrome Enterprise (Not Installed - Workstations) dynamic collection.
From this screenshot, you can see that this collection is filtering for computers that do not have an application installed with a name that matches the variable $(AppNameGoogleChrome), which is just a placeholder for Google Chrome. It's also checking to ensure the computer has been scanned before and that the O/S name doesn't contain the word Server in it. So if a computer doesn't have an application installed called Google Chrome, it's been scanned before, and the O/S doesn't contain the word Server, then the computer will meet the conditions of the collection, and it will automatically be added as a member.
Dynamic collections and PDQ Deploy
Now that we have a pretty good understanding of what dynamic collections are and how they work, we can start to see how they can benefit our deployments. Let's look at two different deployment scenarios, one using dynamic collections and one without dynamic collections.
Scenario A: No dynamic collections
A new version of Google Chrome was recently released, which fixes a major security vulnerability. You have a thousand workstations, some of which already have the latest version of Chrome, some which are still running an old version of Chrome, and others that don't have Chrome installed because they don't need it. Since you don't have a collection specifying which computers have the latest version, which have an old version, and which don't need it, your only option is to deploy the latest version of Chrome to every single workstation. This scenario results in unnecessary network traffic, Chrome being installed on computers that don't need it, and lengthy deployment times.
Scenario B: Targeting dynamic collections
The same situation as Scenario A, a new version of Google Chrome was recently released, and you need to ensure it gets deployed to all of your workstations to fix a vulnerability. Since you have PDQ Inventory which has a built-in dynamic collection for Google Chrome, you can quickly discern which computers already have the latest version of Chrome, which do not, and which don't have it installed at all. The Chrome Enterprise (Old) dynamic collection shows that only 200 computers are running an old version of Chrome. In PDQ Deploy, you target the Chrome Enterprise (Old) collection with your Chrome deployment, which deploys Chrome to only the 200 computers that needed it, saving you bandwidth and time.
The results between these two scenarios are drastically different. The best part about scenario B is that it didn't require any extra effort. The dynamic collection is already built into PDQ Inventory. Once PDQ Inventory scans your environment, computers will automatically be distributed to the various dynamic collections depending on which filter criteria they meet.
Targeting Dynamic Collections
Okay, you get it, you're sold on the idea of dynamic collections, and now you want to see how it works.
With PDQ Deploy open, right-click on the package you want to deploy, and click Deploy Once. I'm going to stick with the Chrome package since pretty much everyone uses it.
With the Deploy Once window open, click Choose Targets > PDQ Inventory > Collection.
Expand Collection Library > Applications > Internet Browsers > Chrome Enterprise, then select Chrome Enterprise (Old) and click OK.
Note - You'll notice that since I only had one computer in the Chrome Enterprise (Old) collection, only that one computer was selected for the deployment.
Click Deploy Now
That's it; you've officially deployed a package to a dynamic collection. Once the deployment finishes, as long as all the computers were online at the time of deployment and no errors were encountered, you'll see the computers moved out of the Chrome Enterprise (Old) dynamic collection and moved into the Chrome Enterprise (Latest) collection.
Scheduling your deployments with dynamic collections & heartbeat triggers
If you're like me, doing things manually is the last thing you want to do. That's where schedules in PDQ Deploy come in handy. Schedules will automate your deployments for you. Combine that with dynamic collections and heartbeat triggers, and you've got yourself a winning combination. What's a heartbeat trigger? Heartbeat triggers are the best way to ensure packages get deployed to offline targets. Instead of using an aggressive schedule or the retry queue to reach those offline targets, which can put a lot of strain on network bandwidth, the heartbeat trigger will kick off a deployment when PDQ Inventory detects that an offline computer has come online.
Here's how to create a schedule with a heartbeat trigger that targets a dynamic collection.
In PDQ Deploy, click New Schedule.
Enter a Schedule Name.
Select the trigger you'd like to use. I'll select both a Weekly trigger which will run every Tuesday at 5 PM and the Heartbeat trigger. If you want, you can configure the heartbeat trigger to run only during a specific time frame.
Click the Targets tab.
Click Choose Targets > PDQ Inventory > Collection.
Select the Chrome Enterprise (Old) collection and click OK.
Click the Packages tab.
Click Attach Packages.
Click the Google Chrome Enterprise (version #) package, then click the > button to include the package. Click OK.
Click the Options tab and ensure Stop deploying to targets once they succeed is checked.
Select any other options you may need and click OK to close and save the schedule.
Congratulations! Not only have you set up your deployment using best practices, you've also configured it to run on its own, so you don't have to deploy it in the future manually.
Wrapping up
Keep in mind that all we did was set up a schedule for one application. Imagine setting this up for all your frequently deployed applications. The amount of time, effort, and bandwidth dynamic collections and schedules with heartbeat triggers can save you is impressive. Another thing to note is that while our dynamic collection library is impressively large, it may not contain a collection for your favorite application. Don't fret; creating your dynamic collection is super easy, and you can watch our resident professional Lex as he guides you through the process with this YouTube video.
With PDQ Deploy and PDQ Inventory, doing things the right way doesn't mean doing things the hard way. More often than not, it means doing things the easy way.
