Skip to content

One Zero One

Code for Your Node

  • Home
  • Posts
  • Contact

Demystifying Microsoft Endpoint Manager Win32 App Deployments

  1. Home
  2. Demystifying Microsoft Endpoint Manager Win32 App Deployments
  • Andy Lievertz
  • May 12, 2022
  • 0
Posted in Systems AdministrationTagged in azure, endpoint manager, intune, microsoft, windows

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.

Installer

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 .intunewin file using the IntuneWinAppUtil process described above.
  • In Endpoint Manager, create a Win32 app deployment and upload the .intunewin file. The install command will be install-gvim.cmd.

On the target system:

  • The .intunewin package will be extracted to a temporary folder.
  • The install-gvim.cmd script will be called from within the temporary folder.
  • The script will run the gvim_8.2.4877_x64_signed.exe installer.
  • The script will execute the three del commands 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:

C:\Windows\SysWOW64\cmd.exe

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:

Path:HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
Name:ExecutionPolicy
Type:REG_SZ
Value:RemoteSigned

Detection

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.

64-bit Applications

The “Uninstall” registry location is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

32-bit Applications

The “Uninstall” registry location is:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall

  • Share:  
  • Facebook
  • Twitter
  • Google+

Andy Lievertz

View all posts by Andy Lievertz | Website

Previous post

Making Libvirt User-friendly in AlmaLinux

Next post

Update Visual Studio Code Updates Settings with PowerShell

Related Posts

Update Visual Studio Code Updates Settings with PowerShell

  • Andy Lievertz
  • June 2, 2022
  • 0

On Windows systems, Visual Studio Code settings are stored in a subfolder of the User profile. %APPDATA%\Code\User\settings.json There is no global settings file, so if you are deploying in an […]

Read More

Making Libvirt User-friendly in AlmaLinux

  • Andy Lievertz
  • January 6, 2022
  • 0

In AlmaLinux (and Red Hat Enterprise Linux, Rocky Linux, and CentOS), libvirtd defaults to the user URI. When a regular user executes virsh list, they will see only the KVM […]

Read More

Recent Posts

  • Update Visual Studio Code Updates Settings with PowerShell
  • Demystifying Microsoft Endpoint Manager Win32 App Deployments
  • Making Libvirt User-friendly in AlmaLinux
  • Example AlmaLinux Kickstart
  • Customizing the AlmaLinux Installer Media

Categories

  • Bash
  • Emulation
  • Linux
  • PowerShell
  • Scripting
  • Systems Administration
  • Uncategorized
  • Virtualization

Search

Copyright © 2021 | All Rights Reserved.

Loading