You might have tried following this guide in order to deploy Office Pro Plus (Click-to-Run) via Intune, resulting in the MSI being deployed but the Office bits not being streamed. I’ve found many people in my inbox struggling and eager to find a solution. I’m glad that Pouyan Khabazi and Paul Huijbregts (both from Wortell) have spent time investigating and came with a workaround/fix. This guide is 100% their work and all credits go out to them:
Leveraging the Office Pro Plus Install Toolkit we generated an .MSI installation file for use with Intune and Configuration Manager in a Hybrid setup. When testing deployment we noticed the installation would not continue – the installer would run but no Office installation followed. We then added our problem description to an existing Github issue after which an engineer made some modifications to the Toolkit.
After receiving confirmation from the engineer we continued to test and found that the installation would complete successfully using Configuration Manager in tandem with Intune. Oddly, the same installation package would not execute using an Intune-only MSI through MDM deployment targeted to Users (status code 60 ENFORCEMENTFAILED in the registry, no further errors in the Intune console).
We started troubleshooting, focusing on potential differences between a deployment through Configuration Manager + Intune and through Intune-only (even though there shouldn’t be any). We noticed that upon adding the installer to Configuration Manager the installation behavior “Install for user” would be automatically set:
We then noticed that the failed installation through Intune would leave behind a registry key that indicated the installation attempt was performed using a Device targeted MSI deployment:
(Our deployment was set to All Users – Required Install. Other deployments from Intune that are similarly targeted have the User’s SID in the resulting registry key as expected)
This led us to believe the installation was executing in the machine context when deploying through Intune MDM where we expected the installation to run in the user context instead. So we took a look at the .MSI file using an MSI editor (Orca):
The Property “ALLUSERS 1” show the package installation type is indeed set to a per-machine installation context. We then compared an older .MSI package (as generated by Pieter Wigleven) and found the “ALLUSERS” property was not present:
We used the MSI editor to remove the “ALLUSERS 1” entry and saved the package. The resulting package then installed without any problems to an Intune MDM-managed Windows 10 machine.
Note: using “Save as” in Orca resulted in a much smaller package that didn’t work. Just hitting save did the trick.
Thanks Pouyan Khabazi and Paul Huijbregts. Please leave some comments if their work has helped you.