Back to basics: Deploying applications with Custom Global Conditions in Configuration Manager

Introduction

This past week I went back to basics with Configuration Manager, as I was working with some applications where I needed the deployments to behave differently based on various factors.

Some may resort to creating individual applications or even packages for each specific need, but there are more clever ways of doing it.

For instance, in this specific case, I had different sets of binaries to be used, varying based on the architecture of Office 365 ProPlus installed. I also wanted something different to happen, whether the installation was happening with a task sequence or not.

So again, this is something a single Application in combination with the proper Global Conditions can cater for. No need to create several Applications or Packages. Curious? Continue reading 🙂

Office 365 ProPlus bitness

As mentioned in the introduction, it’s not uncommon to have a piece of software which installation will vary, depending on if the target device is running Office with 32-bit or 64-bit architecture.

To cater for this in a deployment of an application, you can create and use following Global Condition:

  • Device type: Windows
  • Condition type: Setting
  • Setting type: Registry value
  • Data type: String
  • Hive Name: HKEY_LOCAL_MACHINE
  • Key Name: SOFTWARE\Microsoft\Office\ClickToRun\Configuration
  • Value Name: Platform

Application

When browsing the selected Application on the Requirements tab, you have the option to insert your newly created Global Condition and specify the required value.

In this example, I’m installing a 64-bit add-in to Outlook, which therefore also requires that the target device has Outlook installed in a 64-bit version.

Requirements

Deployment Types

For this particular Application, I have several Deployment Types which have different sets of Requirements.

This allows me to install the same Application with a different set of options.

The highlighted Deployment Type below, is the one also used in my example above and is the installation run with the Powershell App Deployment Toolkit (PSADT).

This sort of deployment, oftentimes requires a user to be logged on in order for the user to interact with the installation. This is to potentially allow the user to defer the installation, close running process etc.

Task Sequence Running

Continuing with the same piece of software as an example and the interactive requirement. This type of installation is not suitable to be run during deployment of the Operating System (OSD).

To cater for this situation, you have another option in creating and using below Global Condition:

  • Device type: Windows
  • Condition type: Setting
  • Setting type: Script
  • Data type: Boolean

  • Script: [bool] (Get-Process tsmanager -ErrorAction SilentlyContinue)

Application

Taking a look on the Application in question again, still on the Requirements tab, you have the option to insert your newly created Global Condition and specify the required value.

In this case, I don’t want this Deployment Type to ever run coming from a Task Sequence. As of such, the value is set to False.

Requirements

More Deployment Types

As you noticed previously, I have several Deployment Types. The remaining and yet unexplained in this case, are the remaining 2 I use for deployments happening with a Task Sequence which translates into primarily OSD.

The Requirements on these are opposite of previously. This time I allow Task Sequences, but I also do something custom for the Processor Architecture. The latter is something I found necessary in order to have ARM devices evaluate the Requirements properly (I will extend this post once I have an ARM device at hands again).

AppIntentEval.log

Rounding this post off with a look into the log file which evaluates the applicability of each Deployment Type in each situation.

Running from outside of a Task Sequence using PSADT

  • Current State = Installed, Applicability = Applicable, ResolvedState = Available, ConfigureState = NotNeeded, Title = PSADT Install Pronestor 8.2.10 x64

Running from inside of a Task Sequence

  • Current State = Installed, Applicability = Applicable, ResolvedState = Available, ConfigureState = NotNeeded, Title = Outlook add-in for Pronestor – Windows Installer (*.msi file) x64

ENJOY 🙂

1 thought on “Back to basics: Deploying applications with Custom Global Conditions in Configuration Manager”

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.