Some aspects of traditional Windows application (win32) deployment using Microsoft Endpoint Manager (Intune) can be frustratingly elusive. Understanding a few things about the program environment and detection capabilities will help you be more successful with this tool.
Please note that in this context, “win32” refers to native Windows applications, not 32-bit applications vs. 64-bit applications.
To prepare a win32 program for deployment with Endpoint Manager, you should copy the EXE or MSI installer to an empty directory, then open a terminal and navigate to that directory and run IntuneWinAppUtil:
> IntuneWinAppUtil.exe -c . -s [INSTALLER] -o .
Anything in the directory will be included in the resulting
.intunewin file, so it is possible to include additional files such as an MSI transform file or any other helpful assets.
Install and Uninstall Commands
Your install command should run silently with no end-user interaction or display, and Silent Install HQ is an excellent resource for this. Your mileage will vary from program to program in terms of available command-line options.
On the target system, the Microsoft Intune Management Extension will download and extract the contents of the .intunewin file to a temporary directory and execute the install command from within that temporary directory.
For the most straightforward scenarios, you can successfully manage your deployments with just these two command lines. However, these may prove inadequate for more complex deployments, and you may decide to use a wrapper script as your install command to give yourself the ability to prepend and/or append additional commands.
CMD Wrapper Scripts
For example, the gVim for Windows installer doesn’t have a command-line switch to prevent the creation of desktop icons, so the wrapper script could (a) perform the silent installation and (b) remove the desktop icons as demonstrated in this simple CMD script:
@ECHO OFF REM install-gvim.cmd REM This script silently installs gVim and removes the desktop icons it creates gvim_8.2.4877_x64_signed.exe /S del /Q "C:\Users\Public\Desktop\gVim 8.2.lnk" del /Q "C:\Users\Public\Desktop\gVim Easy 8.2.lnk" del /Q "C:\Users\Public\Desktop\gVim Read only 8.2.lnk"
To utilize this script:
- Place it in the directory with the gVim EXE and package both files together into an
.intunewinfile using the IntuneWinAppUtil process described above.
- In Endpoint Manager, create a Win32 app deployment and upload the
.intunewinfile. The install command will be
On the target system:
.intunewinpackage will be extracted to a temporary folder.
install-gvim.cmdscript will be called from within the temporary folder.
- The script will run the
- The script will execute the three
delcommands to delete the desktop icons.
So far so good, right?
This is a simple example and should work fine, but as your scripts become more complicated (variables) or if you want to use PowerShell instead, things get a bit more nuanced.
The important thing to know is that on the target system, the install and uninstall commands run in the 32-bit CMD context and this can have unanticipated affects on the outcome. For example, in the 32-bit CMD context, the
%PROGRAMFILES% environment variable contains
C:\Program Files (x86) whereas in the 64-bit CMD context, it contains
C:\Program Files. To verify your install and uninstall commands will work, you should open the 32-bit CMD shell as Administrator for testing:
CMD 64-bit Wrapper Scripts
If you want your wrapper script to run in the 64-bit CMD context and environment, you can call your script using the sysnative CMD path in your install command:
C:\Windows\sysnative\cmd.exe /c install-gvim.cmd
PowerShell Wrapper Scripts
You can use PowerShell to create a wrapper script but as a friendly reminder, deployment will run in the 32-bit CMD context so your install command must call
powershell.exe. You might write an install command like this and think “mission accomplished”:
powershell.exe -File install-gvim.ps1
However, this instantiates a 32-bit PowerShell environment where the Execution Policy is Restricted, causing your deployment to fail. Setting the Execution Policy to RemoteSigned will allow you to run your script, but using an Endpoint Manager configuration profile or Group Policy Object to set the system-wide Execution Policy will not change the Execution Policy for the 32-bit PowerShell context. You can resolve this by setting the Execution Policy on your install command line:
powershell.exe -ExecutionPolicy RemoteSigned -File install-gvim.ps1
Alternatively, you can set a registry value on the your target systems to set the Execution Policy for the 32-bit PowerShell context:
Detection is usually a no-brainer when the installer is an MSI; you can simply choose the “MSI” detection method and the most important details are populated from the package. When the installer is an EXE, however, you’ll need to dig through the registry for help. Most applications will create a subkey of the “Uninstall” key containing (among other things) a DisplayVersion value that can be useful Endpoint Manager detection criteria. The “Uninstall” registry location is different for 32-bit applications vs. 64-bit applications.
The “Uninstall” registry location is:
The “Uninstall” registry location is:
If you are interested in automating the package building process, please see Automating Intune Application Packaging.
For a more in-depth discussion on how Intune works, please see Summary of the Intune Management Extension by Jannik Reinhard.