To Retry Queue or to not Retry Queue

Purpose

The Retry Queue is designed to ensure offline targets receive the patches they deserve. When a target is offline during a deployment it will get added to the Retry Queue. This will create a new deployment attempt for the number of retries allowed on an interval set in the preferences. This is helpful when using PDQ Deploy while PDQ Inventory is not available. But this can increase the workload on the server because it will trigger a deployment whether the target computer is online or not. When Deploy and Inventory are both installed, this can also increase the workload on Inventory's Background Service. This is due to Deploy initiating a "scan after" task in Inventory when finished, there is also the scan step that can be added which will attempt a scan even if the computer is offline. If you are not aware, there is a more efficient and targeted method to achieving the same goal using Inventory.

The Efficiency of Inventory Integration

Since Inventory integrates with Deploy we are able to target Dynamic Collections that will hold only the targets that need the package we are deploying. Take for example Chrome Enterprise, when a new patch is published, the great folks in our packaging team will update the built-in collections for you behind the scenes, any computer you have that does not have that new patch dynamically gets placed in the Chrome Enterprise (old) collection. Of course, you will need a trigger on a schedule for this package that will kick off every so often, maybe it is once a week or on a weekly interval to catch all the computers that are always on, but we know it is common not every computer gets the update because maybe Sally has her laptop at home and Johnny shuts his desktop off when he leaves. That is where the Heartbeat trigger comes into play, adding this piece of gold to your schedule will ensure that any target still in the (old) collection will get what it deserves when it is ready instead of Deploy needing to fire off so many deployments to potentially offline computers.

Conclusion

If you are running Deploy without Inventory then the Retry Queue is super helpful, but if you have Inventory then utilizing the collections and a Heartbeat trigger is the way to go because Inventory determines if the computer is online and allows for better and more efficient targeting whereas the Retry Queue blindly attempts redeployments which can use more resources.

Resources

Please watch Lex go over the example of Chrome Enterprise scheduling with a heartbeat