Conditions

Overview

Conditions are the logic engines for which groups and steps run during a task sequence. Typical usecases are when to apply a driver pack. This is a much smaller use case in DeployR due to the auto matching of models using the "Inject drivers" or "Inject drivers from cloud" steps which will automatically match your DriverPack content items based on Make & Model, however ConfigMgr heavily leveraged conditions to apply the appropriate driver pack to a device. Other common examples were to only apply specific steps during WinPE, or to perform additional steps based on the OS Version being applied, or perhaps having entirely different operating systems applied based on the hardware running the task sequence. Lets say you're running the task sequence on a laptop, and you want to ensure it's not on battery, or if it is, you skip several items just to make sure it completes more quickly, it's all possible. Leveraging conditions allows for several "branches" off the main task sequence, covering additional scenarios without the need for additional task sequence deployments.

Adding a Condition

There are two types of Conditions that can be added onto a task sequence step or group:

• Script (PowerShell)

• Query Builder

To add a condition, first enter edit mode, then find the group or step you wish to place the condition. Click the step or group so it is highlighted, then go to the Options tab. One there, use the drop down to pick from PowerShell or Query builder.

Once you've picked the option from the drop down, go ahead and create the query.

Script

This method provides the most extreme flexiablity, as PowerShell and query for a file path, registry property, or anything in WMI. For highly specific steps that are geared to very unique situations, scripts are the go-to method. I like to compare this to a Discovery / Detection script in Intune or ConfigMgr. The script only determines if remediation (the step) should run.

There is some logic behind how the script feature works, so the scripts need to be written with specific output:

• If the return code is non-zero (either explicitly returned or generated because of a pipeline/script error), skip the step.

• If the return code is zero and there is pipeline data returned, execute the step if there is a "true" boolean on the pipeline; skip the step if there is a "false" boolean on the pipeline. (If there are more than one, only the first will be considered.)

• If the return code is zero and there are no booleans, execute the step if there are any objects returned from the pipeline. Skip the step if there are none.

In summary, scripts that return a boolean true (run) or false (skip). Or a script return objects (run) or no objects (skip). And any non-zero return code will always skip.

Examples, having the step run on a hyper-v virtual machine, these two would cause the step to run:

PS C:\Users\BC Bob> if ((Get-CimInstance -ClassName Win32_ComputerSystem).Model -eq "Virtual Machine"){return $true}
True

PS C:\Users\BC Bob> Get-CimInstance -ClassName Win32_ComputerSystem | Where-Object {$_.Model -eq "Virtual Machine"}
Name             PrimaryOwnerName    Domain              TotalPhysicalMemory Model               Manufacturer
----             ----------------    ------              ------------------- -----               ------------
VM-2CM-ZBG10-01  BC Bob              WORKGROUP           4293808128          Virtual Machine     Microsoft Corporat…

The first example would follow the logic that it returns a 0 exit code (No errors) and returned a boolean of "True"

The second example would follow the logic that it returns a 0 exit code (No errors) and returns an object

Adding the Script option into the Conditions

From the drop-down box, select "Script" which is also the default, then insert your script into the editor. In this example, the script is set to make the Drivers group run on all devices that are NOT virtual machines.

Note, if you have other hypervisors in your environment, they might not match this model name of "Virtual Machine", in which case, this step will still run. To accommodate additional models, the script would just grow a bit, like so:

Script Example for disabling peering on specific subnets based on gateway

As mentioned in the Peering & Content Basics page, there might be times you wish to disable peering, here is an example of using a condition to disable peering on specific networks based on the gateway.

$NoPeeringGateways = @(
'192.168.20.1'
'192.168.214.1'
)

$gwList = @()
Get-CimInstance -ClassName Win32_NetworkAdapterConfiguration -Filter "IPEnabled = 1" | ForEach-Object {
	if ($_.DefaultIPGateway) {
		$_.DefaultIPGateway | ForEach-Object { $gwList += $_ }
	}
}

#If any gateway is in the no list, return true
foreach ($gw in $gwList) {
    if ($NoPeeringGateways -contains $gw) {
        Write-Host "Found Gateway $gw in No Peering List"
        return $true
    }
}

Query Builder

The Query builder is a simple and effective way to quickly add logic into the task sequence.

The logic is like this: [Task Sequence Variable] equals (or not equals) [String]

There can be several different queries added, common ones would be having both a Model & OSCurrentBuild for applying a specific driver pack for a model with a specific OS.

In this example, it shows that this condition would only be true and run the step if the device was an HP and that it was running Windows 10 22H2 (19045).

Conditions can leverage either And (as used in the previous example) or Or logic. Examples would be if the step should run if any number of things were true. In this example, a new group is added with an "Or" logic, so now, besides being an HP device running 19045, this step will also run on any laptop, even if it's not an HP or running 19045

When condition queries get more complex, you'll need to set them in groups to ensure the outcome you like. This shows the Group of having to be an HP device AND running 19045, or IsLaptop equals True. If either of those "statements" are True, then the step will run.