Detect Office Bitness to use in Intune app requirement

I was recently tasked to deploy a plugin required for a particular department into Office. The addin was not available to add through the admin portal and came in msi format. The issue we faced was that the plugin comes in both x86 and x64 flavours which usually is no big problem as most people tend to run one version of Office.

However over time I have seen that when there have been manual installs of Office for certain reasons we can often see a bit of a mixture in Office “bitness” which means we then cannot just deploy one version of this plugin to all users. On top of that we don’t want to have to have the users or other IT staff have to go through the motions finding the bitness of the Office installation to determine which version they need to install.

Thinking about a way I could tackle this had me looking to see if there was anything built into Intune to do that. There is nothing there which does this out of the box, however within the Win32 app requirements section there is the ability to use an “additional requirement rule”

Within here we have the option to use a script to be able to determine if the machine or Office meets the requirements to then have the app installed. So we can look to do something in Powershell to determine if the app is applicable depending on the bitness of Office installed.

The script (borrowed)

Before I started to put much effort into creating a script I did some Googling to see if anyone had already done the hard work. This led me to the System Centre Dudes blog where Jonathan Lefebvre had created something similar for SCCM in the past. Link to his Github is here. Thanks for that! Obviously before just executing someone else’s code have a good look through it and make sure it is not going to cause you any issues and if possible run in an isolated/test environment first. There are other ways to be able to do this by checking other registry keys related to the Office click2run keys but the script linked above worked fine for me.

Basically the script will return either “x86” or “x64” as a string which is perfect for my need.

Creating the requirement in the Intune App

When you have uploaded the Intunewin file you have previously created for the application and gone through all the App naming, declaring the install commands etc you will come to the “Program” pane. In here click on the “Add” for the requirement

In the requirement rule you want to choose “Script”

Once script is selected you are given some options to enter and choose, we need to browse for the “OfficeBitness” powershell script you downloaded earlier. For the output you want to select “String” , “equals” and “x86” or “x64” depending on which bitness you want to require.

Then go through the remaining screens in the Win32 app to set all your requirements you need.

Basically what will then happen is prior to app installation the Powershell script will run and return back the “bitness” of the Office installation on the client. In my example above if the string returned is x86 then the requirements are met and the application will be installed.

If x64 happened to be returned the requirements would not be met and the application would not install. You would see in Intune “App requirements not met”.

If needed you could make both the x86 and x64 available to the same group of users and allow the Powershell script to detect which app would be applicable.

There may be better ways around this by doing something as part of the Win32 app using Powershell to first detect the bitness and then depending on the result call one of two msi’s that are both packaged in the intunewin file but the one I was working with had some pre-provided bat files from a vendor that needed to be used also so the way I documented here worked.

%d bloggers like this: