The Microsoft Win32 Content Prep Tool is a fundamental tool for making your Line of Business (LOB) applications ready for Microsoft Intune. The tool converts application installation files into the .intunewin format which is required for publishing applications via Intune.
I’m currently working on a Digital Transformation Project where we’ll migrate close to 1.250 LOB Apps from SCCM to Intune. This is an amazing project, and I’m lucky to work together with MVP Adam Gross which most of you probably already know from IntuneTraining. Needless to say, I’m pretty sure I’ve got a trick or two to share with the community as we dig down the Rabbit Hole!
If we go back like 15+ years or so I was the person responsible for making sure that the Applications provided by the SMS team was working properly in our Multi Session Environments (Citrix MetaFrame and later Citrix Presentation Server) at a huge Oil service company in Norway. Fast forward and I’m in the same spot, only now everything is Cloud managed which is an amazing thing IMHO.
With these huge numbers of applications, a manual process is out of reach if we want to to finish this up in 2021! Besides from that, just manually uploading an .EXE or .MSI using the Intune wizard won’t get you far. You don’t get extended MSI installer logging as an example, which makes troubleshooting even worse than it already is.
When starting out on a Digital Transformation Project like this, you first need to build out a PoC and that’s what I did. What I’m going to share with you in this blog post is a PowerShell script that reads a very simple XML file with the application details required to automatically build and upload an .intunewin file to Intune (EXE/MSI/PS1). Needless to say, as the project moves forward I’ll be able to share more details on looping through a network share, doing Evergreen or exporting SCCM Applications directly to Intune. But first let’s get down to the basics.
My previous blog post series Building a Hybrid Cloud has all the details on how my lab is running. I’m running Windows 365 Enterprise (W365E) and if you want to learn more, please check out this blog post from the World’s First Windows 365 MVP Sune Thomson – How to configure Windows 365 Enterprise in Microsoft Endpoint Manager.
The only thing I want to add, is to setup a Server with Active Directory Domain Services (AD DS) in Azure, close to your W365E workloads. That way the logons will be faster, and if all of your Site 2 Site VPN links goes down, you’ll still be able to log on (going away soon with Azure AD join support).
EXE with MSI Product Code
In this example we’re going to start out with a simple .EXE for the newly released Microsoft Remote Help for Windows. This one is really simple, because the detection method and uninstall string is a MSI product code so we don’t need to hunt down a Registry Detection Method nor an Uninstall command.
EXE without MSI Product Code
This type is very common and requires some more details in the XML file. We need to find the uninstall program, path, silent switches and a registry value for the detection method. In this example we’re going to use Notepad++.
Best Practices is to use DisplayVersion from the Uninstall registry key (used by Add/Remove Programs) for the detection method which is located in either location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
MSI with MST
MSI is straight forward, but in many cases you need to customize the installation. In this example we’re going to use System Center 2012 R2 Configuration Manager Toolkit which contains CMTrace.
Out of the box the MSI will install both Server and Client tools, so we’re going to use Master Packager to create a MST file that only installs the Client tools and also registers the file extensions.
As you can see below my PowerShell script will automatically configure MSI logging and add a MST file if it exists. Pretty cool?
My script is based upon the amazing PowerShell module IntuneWin32App from MVP Nickolaj Andersen. From all the research I’ve been doing, this is the de facto standard everyone is using.
How Does It Work?
Basically we’re using an AppID for the application location on our Content Share. Place the installer in a sub folder called PKG, and Config.xml and Icon.png in the root of the AppID folder. This can of course be edited to suite your needs. The script can be found here on my Github repo.