SCCM (or MEMCM as is newly branded) offers you the possibility to place Global Conditions for multiple areas of it, including for the Applications. When a global condition is placed on an Application in SCCM, the following actions are performed:

1. When an application is deployed on a MACHINE collection, the condition (requirement) is instantly evaluated, and only if the condition is passed, the application is shown in Software Center for the user
2. When an application is deployed on a USER collection, the condition (requirement) is evaluated when the user clicks install, and if the condition is passed the installation starts, otherwise the user is notified that “the app is not compatible with this system”
3. When an application is deployed as required, the condition is instantly evaluated no matter if it’s placed on a machine collection or user collection. If the condition is passed, the installation starts, otherwise the reports will output a “condition not met” for the failed conditions (requirements)

SCCM offered a great deal of global condition types, such as Active Directory query, Assembly, File system, IIS metabase, registry key, registry value, script, sql query, WQL query and Xpath query.

Requirements in Intune

Intune still offers the possibility to add custom requirements for Applications, and these can be found when you create the application. For the moment, there are three types of custom requirements available: File, Registry and Script. So let’s see how you can add custom requirements:

When you reach the Requirements step in the deployment stage of an application, Intune offers a few basic requirements that you can add, such as Operating System Architecture (32-bit/64-bit), Minimum Operating System (starting with OS Version1607), Disk Space Required, Physical memory required, Minimum number of logical processors required and Minimum CPU speed required. To add additional requirements click on the Add button bellow:

Once you click the Add button, a new window will appear on the right from where we can choose the extra types of requirements: File, Registry or Script:

File/Folder requirements

Let’s say we want to check if a certain file or folder to be present before we install the application. If we click on File, the following options will appear:

First we need to specify the path of our file or folder in which Intune will look for before the installation. Let’s say I want to have a file called Sample.EXE to be present in C:\Windows\Temp before the installation. For this, we are going to place the following settings in the fields. We won’t change the “Associated with a 32-bit app on 64-bit clients” to YES because C:\Windows\Temp is a 64-bit location:

Intune also offers you additional options in terms of files and folders requirements:

You can see if a “File or folder does not exist”:

or you can get the “Date Modified” of a specific file/folder:

or the “Date Created”:

a particular “String(version)” of an executable:

or even the “Size in MB”:

Registry Requirements

As previously mentioned, registry requirements are also available in Intune. It let’s you do simple searches like if a registry exists, or it can do String,Version and Integer comparisons:

For example, if i want to check the string value of a certain registry key, this is how it should be added in Intune:

Script Requirements

Intune offers you the possibility to run PowerShell scripts as a requirement, before the installation is started, and according to what the script outputs  you can continue or cancel the installation. Unlike SCCM, VBScripts are not an option when it comes to scripts.

Now let’s assume I have a script that checks if a certain registry is present on the machine (yes I know you can do this natively, it’s just an example), and if it exists, it outputs the string “install”.

In order to add this script to Intune as a requirement, we will have to configure it like this:

When you add your script, this will be imported in Intune and the Script Name will be populated with the one of your script. Next, you have options to decide if the script will be executed in the 32-bit context or not, if the script will be executed in the user context or system context.

The next option “enforce script signature check” is a bit tricky. Technically, if you leave NO, you don’t have to sign your script with a trusted certificate, but the script will require the end-user confirmation in order to be executed, so if you want to run scripts silently without user confirmation, you will have to sign them.

Next, you can select the output data type of your script. the options are: String, Datetime, Integer, Floating Point, Version and boolean.

So for example, if I have a script that I know it outputs an Integer of 1:

This is how it should be defined in Intune:

Hope you find this article useful, I will next do an article regarding Dependencies and the newly publicly beta added option of Supersedence, so stay tuned.