In this blog you will learn a simple way of patching applications deployed via Intune when assigned as available.

If you come from a SCCM background, you probably were using Collections to identify which computers have certain application installed to target updates. If you are using Intune for some time, you probably also know Intune does not have anything like collections, right?? Well, that is where Requirements Rules come into play. Whenever a win32app is targeted and the installation process starts, the app will evaluate requirement rules first (in case any exist), detection rules (if detection is met the software will change to Installed status) and then finally execute the install command line.

To perform an update of a specific application (which is not targeted company wide, meaning its deployed as available) you first need to identify where that application is installed (so you don’t force install it to devices which don’t need it).

I’ve always use PowerShell scripts for detection and requirements rules because it allows me to automate my packaging flow. I have a default script which I always use for my requirements, which is where I am trying to identify if the software I’m targeting is installed on a device. This script uses the built-in package management PowerShell module by leveraging the Get-Package command.

The script will then run and leverage Get-Package to identify if any (older, newer or same) version is installed on the system. That being true, the detection rule will tell me if it needs to be updated or not. I’ve tried to create a diagram with an application installation flow.

Here is a sample of the script and some explanation on how it works.

    try {
	$AppName = '7-Zip ??.?? (x64 edition)';
	$output = 'Required';
	$Installed = (Get-Package -Name $AppName -ErrorAction SilentlyContinue) 
	if ($Installed) {return $output}
        }
    catch { exit} 

The script will run the Get-Package command looking for any entries with the $AppName variable in it. The ErrorAction is in there to suppress any error in case the app is not installed. In case it is, we return “Required” which is the string we are going to configure the rule to expect in case the requirement is met. Any other errors should go to catch which just finishes the execution with an empty STDOUT (meaning requirement not met since we expect “Required” to be returned.)

Note the app name variable ($AppName) can be used with wildcards like ‘?’ or ‘*’ depending on how you want to query.

You could use 7-Zip ??.?? (x64 edition) or 7-Zip*(x64 edition) to the same effect, unless of course 7-zip releases a version 100.01 in which case the first example would not work.

Just please, be careful not to use something like 7-Zip* since that would be coming back positive for both (x64 edition) and (x32 edition) and that might not be your desired outcome.

Once you use requirement rules in that manner you can then assigned your application as required to all devices and it will not even get to evaluate detection rule if the requirement is not met, allowing you to target an application update to all devices in the environment but only deploying it on devices which really need them.

Thanks for reading and I hope that helped you better understand Requirements and Detections in Win32Apps on Intune.