I was recently working with a client who were getting extremely frustrated by the understanding that they could only really limit delivery of App-V packages by target operating system. They noticed the option as part of the sequencing process as shown here:
They wanted a much more granular way to control whether a package gets delivered to its target destination or not. In their scenario they had a certain package which they wanted to target to users however they wanted for the package to only be delivered if the user was logging onto their VDI environment, under no circumstances did they want the package to reach a non VDI machine. Although their VDI was based on Windows 10 the same as their traditional desktop environment, they could easily identify a VDI machine by a simple registry key that was written into the image at build time.
The Good News
The good news was that although the sequencing process only provides an option to limit by target operating system there are other ways to condition delivery on a much more granular level including checking for the registry key VDI identifier this client wanted to check for.
Option 1 – Use ConfigMgr (SCCM)
SCCM allows administrators to provide requirements for deployment types which will be assessed at the time of deployment to see if a package is eligible for delivery. Whether it is out of the box checks for hardware requirements or custom WMI queries, SCCM will allow specification of multiple conditions that will limit the delivery of the package. However this particular client did not have SCCM and furthermore wanted a solution that was incorporated and self contained as part of the packaging process.
Option 2 – RollbackOnError
RollBackOnError is a much under publicised feature of App-V scripting and often over looked in terms of its power for controlling where App-V packages end up being delivered. The tag can be used very simply and to great effect in the formulation of package scripts both within the UserConfig.xml and DeploymentConfig.xml. When talking in context of conditional delivery, the tag can be used for the AddPackage and PublishPackage events.
RollBackOnError allows us the prevent the associated event action occurring should there be an error, for scripts this means anything that exits with a return code of anything other than 0. We also have the optional wait parameter which tells the script to wait for a particular length of time to allow the script to complete.
In the example above we have harnessed both the PublishPackage and AddPackage events to ensure that these actions will only occur IF our script completes successfully with 30 seconds, in all other circumstances the add / publish of the package will fail. In terms of the conditional logic inside the Check VDI.ps1 PowerShell script, it is extremely simple:
$VDI=“HKLM:\SOFTWARE\VirtualVibes\Build\VDI”
If (Test-Path $VDI)
{
Exit 0
}
Else
{
Exit 1
}
The example above, a check will be made for the registry key that identifies whether the machine is a VDI instance or not, if this is true then an exit code of 0 will be returned, if it is false then a failure exit code of 1 will be returned. The configuration .xml will then handle these return codes to either complete the add / publish or abort. The great thing about utilising the scripted approach is we can use whatever logic against whatever conditions we desire. We essentially can check for whatever we want and of course it doesn’t need to be done in PowerShell either.
When the package ‘fails’ to deliver (intentionally based on your conditional delivery of course) you can expect the following 4009 event inside your Microsoft\AppV\Client\Admin event logs:
Connection Groups
You can also further develop the approach above for conditional delivery of connection groups. This becomes useful when you want to target connections groups at a user but condition the delivery of particular groups to certain criteria.
The example above utilises the IsOptional parameter in Connection Groups which can be used to specify a mandatory package member, this means if the package is not available on the target machine then the connection group will fail to deliver. In the scenario above Connection Group Two will only deliver to machines that have the mandatory package, using the RollBackOnError logic as previously discussed in this package, we can ensure the package is only delivered to VDI machines and hence also ensure the given Connection Group also only deploys to VDI machines.
