Everything you need to know about conditions in PDQ Deploy

Brock Bingham candid headshot
Brock Bingham|May 15, 2023
Illustration that shows logo of PDQ Deploy
Illustration that shows logo of PDQ Deploy

Deploying applications and updates across a network of devices is an intricate process. In a perfect network environment, all your computers would be the same make and model, have the same hardware specs, run the same architecture and operating system, and contain the same applications and updates. Instead, our networks are bustling with devices from every PC manufacturer under the sun and probably even a few custom-built rigs running who knows what. Thankfully, conditions in PDQ Deploy can help ensure your deployments target the correct devices.

What are conditions in PDQ Deploy?

In PDQ Deploy, conditions are settings you can configure to ensure specific target requirements are met during deployments and when running deployment steps. For example, if you have a package that you only want to deploy to Windows 11 devices, you can set a condition to target only computers running Windows 11. Conditions are an efficient way to ensure your packages and package steps deploy to the correct targets.

What’s the difference between package and step-level conditions?

Conditions can be set at the package level and the individual step level of a package in PDQ Deploy.

How to set package level conditions in PDQ Deploy.

Conditions set at the package level evaluate targets as soon as the deployment begins to ensure they meet the requirements. If the target meets the conditions, the deployment continues. If the conditions are not met, the deployment stops with an error message stating the target didn’t meet the conditions. The remaining steps do not run.

How to set step level conditions in PDQ Deploy.

Conditions set at the step level evaluate the condition requirements at the start of each step during the deployment. If a condition isn’t met for one step, the deployment proceeds to the next step and evaluates that step’s conditions. This process proceeds until all steps have run.

What types of conditions are there?

As I mentioned, most sysadmins deal with a large assortment of devices ranging in specs, architectures, and configurations. PDQ Deploy has several different condition settings to ensure you have enough options to streamline your deployments. Here are the various condition options you’ll find in PDQ Deploy.

  • O/S Version

  • O/S Architecture

  • PowerShell Version

  • Logged On State

  • File requirements

  • Registry requirements

  • PDQ Inventory Collection membership

Let’s look at each of these conditions and identify how to use them to increase the accuracy of your package deployments.

O/S Version

As the name implies, the O/S Version condition allows you to set the operating system requirement for the deployment or step.

A list of the various O/S conditions available in PDQ Deploy.

Many software vendors limit support to newer operating systems. Setting the O/S Version condition can ensure applications deploy only to supported operating systems.

O/S Architecture

The O/S Architecture condition allows you to select 32-bit architectures, 64-bit architectures, or both. While 32-bit applications can be installed on both 32- and 64-bit systems, 64-bit applications can be installed only on 64-bit systems. Configure this setting accordingly to eliminate errors encountered by deploying applications to unsupported systems.

PowerShell Version

The PowerShell Version condition lets you set the required PowerShell version running on the target device. Older versions of PowerShell may not support newer cmdlets and functionality utilized by scripts created on systems running newer versions of PowerShell. As the PowerShell platform has matured and older systems were updated, this condition isn’t needed as often. But if you have devices running very old versions of PowerShell, you may want to consider this condition before deploying your next PowerShell script.

Logged On State

Some installations or scripts may require a user to be logged onto the target device to run successfully. For example, the Dropbox package in the Package Library has a command step that restarts the Dropbox client. However, this step is required to run only if a user is logged on. If you have issues with deployments that require services to be stopped or started when a user is logged on, consider using the Logged On State condition.

Configuring the Loggged On State condition in PDQ Deploy.

File requirements

The File condition allows you to require that a file exist or not exist on the target device. This condition can be used for some pretty creative purposes, including identifying members of a pilot group. However, be careful with this condition because files can easily find their way into the wrong directories, especially when the file doesn’t reside in a directory that requires admin rights to manipulate.

Configuring file conditions in PDQ Deploy.

Registry requirements

The Registry condition behaves similarly to the File condition but evaluates if a registry key exists on the target device. While you should always be careful when working with the registry, this option is pretty harmless since it doesn’t actually modify the registry in any way.

PDQ Inventory Collection membership

The last condition is the PDQ Inventory Collection condition. This condition checks to see if a device is a member of a specified collection in PDQ Inventory. This condition can be very useful as long as the collections in PDQ Inventory are up to date. The best way to utilize the PDQ Inventory Collection condition is to run a scan step prior to running a step that uses this condition.

Conditions vs. collections in PDQ Inventory

While there are some overlapping use cases between using conditions versus targeting collections in PDQ Inventory, it’s often best practice to utilize both with your deployments. For example, if you want to ensure iTunes never gets installed on a server, uncheck the server options from the O/S Version condition on the package level. You can then target any PDQ Inventory collection you want with the iTunes package and never have to worry about it being accidentally installed on a server.

Condition yourself to use conditions in PDQ Deploy

While I’m probably not conditioning my hair as often as I should, I definitely utilize conditions in PDQ Deploy on a regular basis. Conditions can ensure your deployments target the correct devices, resulting in more successful deployments and less time looking at error logs.

Ready to take the stress out of device management? Try out PDQ Deploy and Inventory free for 14 days. Got a large fleet of remote endpoints? PDQ Connect can help keep you connected to your remote workforce. Try PDQ Connect for free for 14 days.

Brock Bingham candid headshot
Brock Bingham

Born in the '80s and raised by his NES, Brock quickly fell in love with everything tech. With over 15 years of IT experience, Brock now enjoys the life of luxury as a renowned tech blogger and receiver of many Dundie Awards. In his free time, Brock enjoys adventuring with his wife, kids, and dogs, while dreaming of retirement.

Related articles