Have you ever tried winning concert tickets by entering a radio show contest? Are you one of those lucky few who were fortunate enough to be caller number 9, netting those coveted Journey cover band tickets? Did you have a strategy to ensure you were the winning caller? Or, did you just call over and over again until you got through?
Don't you wish there was an easier way? Repeatedly calling in can work, but it isn't very efficient. Wouldn't it be great if the radio host could send you a text message telling you exactly when to call in?
Unfortunately, I don't have any advice to help you become the next caller number 9. I do, however, have a recommendation that will help sysadmins keep their hard-to-reach devices up to date, and that's way better than concert tickets and backstage passes, right? Anybody?
The Retry Queue
If you were wondering where I was going with that radio contest analogy, don't worry. You're probably not alone. However, it does a great job of highlighting the inefficiency of repeating the same process over and over again, hoping to get a different outcome eventually.
For the past several years, the trend of working remotely has gained a lot of momentum. The COVID pandemic has kicked this trend into high gear, forcing sysadmins to adapt to an ever-increasing mobile workforce. The challenge of managing devices that no longer constantly live on your production network is difficult, to say the least.
The retry queue in PDQ Deploy was introduced as a means to help get patches and updates deployed to targets that are constantly on the move. When a package is deployed, any computers that are offline and fail to receive the package can be moved into the retry queue. Similar to the person repeatedly calling into the radio show, PDQ Deploy will continuously attempt to re-deploy failed packages to targets until it either successfully deploys the package or runs out of retry attempts.
Configuring the Retry Queue
The retry queue can be configured in a few different locations. For most users, I recommend setting the retry queue options at the package level or the schedule level. This allows you to customize each package or schedule them individually.
To configure the retry queue at the package level:
1. Double-click on an existing package in PDQ Deploy
2. When the package details window opens, make sure Properties is selected, then click on the Offline Settings tab
3. Uncheck Use settings from Preferences
4. Select Put offline targets in Retry Queue
5. After enabling the retry queue, you can configure the number of allowed retries before the targets leave the retry queue. The default is 72 retries, once per hour, for a total of three days.
To configure the retry queue at the schedule level:
1. Create a new schedule or open an existing schedule by clicking on the All Schedules menu option and double-clicking on an existing schedule
2. Click on the Offline Settings tab
3. Uncheck Use settings from package(s)
4. Select Put offline targets in Retry Queue
5. Configure the number of allowed retries
If you prefer full-contact IT and want the retry queue configured for everything you deploy, you'll want to configure it in the preferences menu.
In PDQ Deploy, click Options > Preferences
Click Deployments from the menu options
Select Put offline targets in Retry Queue and configure your retry queue settings in the Retry Queue section
In the preferences menu, you have the option to set the number of allowed retries, as well as the retry interval. The retry interval determines how often the package will attempt to re-deploy. By default, the retry interval is set to run once every hour.
Before you configure the retry queue in the preferences menu, it's important to realize that all packages will default to the behavior configured there, meaning every package that uses the default settings will have the retry queue enabled. So, make sure this is what you want before configuring these settings.
The Heartbeat Trigger
The heartbeat trigger serves a similar function as the retry queue, but it goes about it much more efficiently. If the retry queue is like the person calling the radio show over and over again, the heartbeat trigger is like the radio host sending you a text message telling you exactly when to call in.
A heartbeat is when PDQ Inventory detects that a computer has gone from an offline state to an online state. This heartbeat can be used as a trigger for scans in PDQ Inventory and scheduling deployments in PDQ Deploy. Be aware, scheduling packages with heartbeat triggers requires PDQ Inventory. If you don't already have PDQ Inventory, you can download a free 14-day trial and discover for yourself how it can take your deployments to the next level.
By default, PDQ Inventory sends out a heartbeat ping every 300 seconds. This setting can be configured in the PDQ Inventory Preferences menu.
In PDQ Inventory, click Options > Preferences
Click the Network menu option
Here you can enable or disable Auto Heartbeat and configure the interval between heartbeats:
Adding Heartbeat Triggers to Schedules
Adding a heartbeat trigger to a new or existing package is super easy. Keep in mind that unlike the retry queue, which can be configured in preferences, schedules, and at the package level, heartbeat triggers can only be attached to schedules.
In PDQ Deploy, click on All Schedules to edit an existing schedule, or click on New Schedule to create a new schedule
Click the Triggers tab
Click Heartbeat to add a heartbeat trigger
It's important to remember that schedules can have multiple triggers, and adding a heartbeat trigger to a schedule with an existing trigger is a common configuration.
Once you've added the heartbeat trigger, you can customize it by adding a specific starting date and time. If you want the trigger to stop running at some point, you can select the Ending option and set an end date and time. If you want to ensure the heartbeat trigger only runs during certain times of the day, you can enable the Only run during the following time frame option and set your run times.
Wrapping up
While the retry queue and heartbeat triggers accomplish similar things, they go about it in entirely different ways. The retry queue is sort of the brute force method. There is no built-in logic to help the retry queue determine when it should deploy to a target. It will attempt to push packages out on the schedule you set, and it will stop trying after it reaches the max number of attempts.
On the other hand, the heartbeat trigger will only deploy packages to targets when PDQ Inventory detects that the status has changed from offline to online. In almost all cases, we recommend using heartbeat triggers over the retry queue.
Now, before you start cranking out packages to those hard-to-reach devices, let me give you some advice. Use caution when utilizing the retry queue or heartbeat triggers when deploying packages that require a reboot. Your users may not be thrilled if their computer has to restart shortly after turning it on. Or, maybe they love sudden coffee breaks. Who am I to say?
