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.
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.
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.
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.
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.
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 on a regular basis to simplify software deployments in PDQ Deploy. 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.
