Introduction

Buckle up, as this is a long one. Why? I thought it would be good to get a bunch of Intune packaging concepts out there in one adventure, such as packaging a piece of software with unique behaviors. It didn’t go perfectly smoothly, so I got to show some troubleshooting around removing necessary software when an installer is more than one application with Winmerge.

Regardless, there are lots of nuggets, from how application packages should be requested to the research you would undertake and the actual packaging of the application. So, let’s get to it and package an application!

Package Request

To request an application package, please provide the following information to ensure a smooth and efficient packaging process:

  • Application Name – The full name of the application.
  • Application Version – The specific version of the application being requested.
  • Manufacturer – The name of the company or developer that produces the application.
  • Application Installer – The installation file or package required to install the application.
  • Hardware Dependencies – Any specific hardware requirements needed for the application to function.
  • Printing Requirements – Details any printing capabilities or dependencies the application may have. (great info for testers!)
  • Software Dependencies – Any additional software required for the application to operate correctly.
  • Documented Software Installation – A step-by-step record of how the application (and dependencies) should be installed and configured.

This information upfront helps minimize delays and ensure the application is packaged correctly. For this blog, I will be packaging DotNetHosting, which is more middleware than an application but has some unique challenges packaging it that I think are worth sharing.

Package Naming Standard

To maintain a structured and consistent catalog of Win32 applications, the following metadata must be included:

  • Application Name – The standardized name for the application package. This name should remain consistent across versions unless the vendor introduces a change.
  • Application Version – The specific version of the application included in the package. This helps track which version is deployed on devices.
  • Package Version – An internal versioning system used to manage multiple iterations of a packaged application. This is useful when an application is repackaged for testing, modified before deployment, or requires a patch.

Example Naming Convention:

DotNetHosting-V3.1.8-R1

  • DotNetHosting → Application Name
  • V3.1.8 → Application Version
  • R1 → Package Version (indicating the first release of this package)

This naming convention ensures clarity and consistency across all Win32 application packages.

I.E. DotNetHosting-V3.1.8-R1

Additional Metadata for Complex Environments

In more complex environments, additional metadata such as location codes, language identifiers, and application architecture may be required to manage regional variations, language-specific deployments, or different system architectures.

Extended Naming Convention Example:

DotNetHosting-V3.1.8-YYC-EN-x64-R1

  • DotNetHosting → Application Name
  • V3.1.8 → Application Version
  • YYC → Location Code (e.g., airport code for Calgary, indicating a regional deployment)
  • EN → Language Code (e.g., English version of the package)
  • x64 → Application Architecture (e.g., x86 for 32-bit applications, x64 for 64-bit applications)
  • R1 → Package Version

Incorporating location, language, and architecture metadata ensures precise application deployment, helping organizations efficiently manage compatibility, localization, and regional requirements.

i.e.DotNetHosting-V3.1.8-YYC-EN-x64-R1

Research the Package

Before repacking an application, detailed information must be gathered to ensure a smooth deployment and maintenance process. Understanding the application’s installation behavior, dependencies, and uninstallation process will help prevent deployment failures and user disruptions. Below are some key factors and approaches to researching the application installer.

Key Information to Collect Before Packaging

To properly prepare for application packaging, the following details should be documented:

  • Application Name
    • The application’s official name as recognized by the vendor or your organization.
  • Manufacturer
    • The company that develops and distributes the application.
  • Version
    • The exact version of the software being packaged and deployed helps manage updates and compatibility.
  • Category (Optional)
    • A classification of the application (e.g., Productivity, Security, Development, Utility, etc.), which can be helpful for software cataloging.
  • Owner (Optional)
    • The business unit or individual responsible for the application within the organization, which helps with licensing and support inquiries.
  • Installation Command Line
    • The command-line syntax used to install the application silently without requiring user interaction.
    • Considerations:
      • Determine if switches are available for silent installation (e.g., /qn for MSI, –silent for EXE).
      • Identify if any prerequisites or dependencies are required.
      • Verify whether the installation may trigger a system reboot and ensure it returns standard installer exit codes (e.g., 0 for success, 3010 for reboot required).
  • Uninstall Command Line
    • The command-line syntax used to remove the software silently.
    • Considerations:
      • Verify that the uninstall command does not leave residual packages or dependencies.
      • Identify whether a reboot is required and ensure standard exit codes are used.
      • Check if user confirmation is required and suppress prompts where necessary.
  • Detection Method

The detection method determines if the application is installed on a device. A variety of approaches are available to make detection methods, and they should be considered as the detection method should confirm application presence, including version, if possible.

    • Common detection techniques include:
      • MSI product code: Windows Installer uses what is a product code to register with the operating system that the application is installed.
      • Registry-based detection: Checking for the presence of a specific registry key, value, or GUID under HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ for MSI-based applications.
      • File-based detection: Verifying the existence of a specific file or folder (e.g., C:\Program Files\Vendor\AppName\app.exe).
      • PowerShell detection scripts: Custom scripts that check installation criteria dynamically.
    • Version-based detection:
      • Ensuring that the installed application version matches the packaged version. This is not required but encouraged.
    • Detection Method Preference:

The detection methods of preference are simple and less prone to failure, but some packagers prefer the accuracy of script-based detection methods.

      • MSI Product Code: Highest confidence of detection.
      • File: Detection of a file, especially with file version, is a choice.
      • Registry: It is possible to check for an application’s presence in the registry, but determining its version can be challenging.
      • PowerShell: Although sometimes discouraged because of its complexity, it does offer the most extensive set of features for application detection.
  • Company Portal Logo
    • The official application logo is used for branding in the Microsoft Intune Company Portal or Windows Software Center.
      • Considerations:
      • It must be a high-resolution PNG file (preferably 256×256 pixels).
      • Ensure it matches the official branding guidelines of the application.

Additional Research Considerations

Beyond gathering the above information, it is advisable to research the following aspects before proceeding with repackaging:

1. Source Installer Type

Identify the type of installer package:

  • MSI (Microsoft Installer) – is preferred for enterprise deployment due to its built-in support for silent installation, custom transforms (.MST), and a wide array of deployment options.
  • EXE (Executable) – This requires switches for silent deployment and may involve repackaging. Some use standard switches, while others require research.
  • APPX/MSIX – Microsoft’s modern packaging format for UWP and Win32 apps, suitable for security and containerized deployment.
  • Script-Based Installers – Some applications use PowerShell, batch files, or third-party scripting tools.

2. Dependencies and Prerequisites

Identify if the application requires the following:

  • .NET Framework, Visual C++ Redistributable, or Java Runtime.
  • License keys, activation requirements, or user credentials.
  • Connection to an external server or service during installation.

3. Customization and Pre/Post-configuration

Determine whether the application supports pre-configured settings using:

  • MSI Transforms (.MST) is used to customize installation behavior.
  • Answer files (e.g., .iss files for InstallShield EXE installers).
  • Registry edits for default configurations.

4. Testing and Validation

Conduct a test installation in a controlled environment (e.g., a virtual machine or test device).

  • Launch the installation from a command prompt to verify exit codes.
  • Verify silent installation and uninstallation behavior. User prompts are to be avoided for silent installation.
  • Check logs for errors (C:\Windows\Temp\*.log or %APPDATA%\*.log).

Common Command Lines

Common Command Lines for Application Installers

Many application installers support command-line parameters that allow for automation, silent installation, and custom configurations. These parameters vary based on the installer type, but some common patterns exist across Windows Installer (MSI) and executable (EXE) installers.

Windows Installer (MSI)

Windows Installer (MSI) packages support a standardized command-line switch set for silent installations, logging, and customization. Below are some commonly used commands:

  • Basic interactive installation with minimal UI:
    • msiexec.exe /i <msiname.msi> /qb-!
      • /i – Specifies that the MSI package should be installed.
      • /qb-! – Uses a basic user interface with no modal dialog boxes (the -! suppresses the “Cancel” button).
  • Completely silent installation (no user interaction):
    • msiexec.exe /i <msiname.msi> /qn
      • /qn – Runs the installation with no UI at all.
  • Logging installation details for troubleshooting:
    • msiexec.exe /i <msiname.msi> /qn /L*v install.log
      • /L*v install.log – Enables verbose logging to capture detailed installation information in the specified log file.
  • Uninstalling an MSI application silently:
    • msiexec.exe /x <msiname.msi> /qn
      • /x – Specifies that the MSI package should be uninstalled.

For a comprehensive list of Windows Installer command-line options, refer to the official Microsoft documentation:
Standard Installer Command-Line Options

Executable (EXE) Installers

Unlike MSI-based installers, EXE-based installers can vary widely in their supported command-line parameters. However, most follow some common conventions:

  • Silent or unattended installation (no UI, no prompts):
    • Installer.exe /s
    • Installer.exe /silent
    • Installer.exe /verysilent
    • Installer.exe /quiet
    • Installer.exe /passive
    • /s, /silent, /verysilent, /quiet, and /passive are standard switches used for silent installations.
    • /passive often provides a progress bar but does not require user interaction.
  • Uninstalling an EXE-based application silently:
    • Installer.exe /uninstall /silent
  • Checking available command-line options for an EXE installer: Some installers provide a built-in help function, which can be accessed using:
    • Installer.exe -?
    • Installer.exe /?
    • Installer.exe /help
    • Installer.exe -help

Running one of these commands will often display a list of supported parameters.

  • Example: Silent installation with logging
    • Installer.exe /silent /log=install.log
    • Some installers allow for logging, making it easier to troubleshoot issues.

Finding the Right Installer Parameters

Since EXE installers do not follow a universal standard like MSI, checking the vendor’s documentation or testing different parameters is often necessary. Here are some methods for determining the correct silent installation options:

  1. Check Vendor Documentation:
    Many software vendors provide documentation on their installers, listing available command-line switches.
  2. Try Help Commands (/?, -?, /help)
    As mentioned above, many installers will display supported options when launched with these parameters.
  3. Inspect the Installer Type:
    • If an EXE installer is wrapping an MSI, you may be able to extract and use the MSI directly.
    • Run the installer and check the temporary folder (%TEMP%) for extracted MSI files.
    • Use tools like 7-Zip to open the EXE and inspect its contents.
  4. Use Installation Monitoring Tools:

By leveraging these command-line options, IT administrators can automate software deployments, enforce standard configurations, and streamline application management in environments using tools such as Microsoft Intune, Configuration Manager, or Group Policy.

AppDetails.com

This site redirects to a ChatGPT agent equipped with packaging knowledge, which can serve as a resource for packaging the application. In this example, I search for dotnet hosting 3.1.8 and get a possible silent command line for the application, which can then be tested to see if the application is installed silently.

In this example, I run the command line from a command prompt.

And accept the UAC prompt.

After that, the application installs, but notice the progress bar; we will likely install more than one software package, which will be helpful later.

I can then take this information and make a simple batch file. The process is to prepend the EXE with %~DP0 to signal that the command is to be executed in the current working directory, which can prevent issues when running installation commands in Intune. As the packager, we will build an install.bat file with the following command:

%~DP0dotnet-hosting-3.1.8-win.exe /quiet /norestart

Pro tip: Batch files are simple to make and usually have the least issues. PowerShell can be used to provide more rich of a scripting environment but may require more troubleshooting.

Winget Manifests

Another method to check for software installation command lines is to search the Winget GitHub manifest library for possible matches with the software you are deploying.

Based on the folder structure, the version of .NET Core we are deploying is older than what is available with Winget, leaving a couple of options. One is to look at what information is available about the installer but use your existing installer, or consider possibly using a newer installer that Winget is using.

If you open one of the folders, you will see a set of YAML files that help Winget install applications. These files are straightforward to read and allow us to glean information about installing this application.

When opening the Microsoft.DotNet.HostingBundle.3_1.installer.yaml file, I can verify the installer switches for silent installation. An MSI product code can also be helpful with application detection or removal. Also, there is a URL to the application installer and its hash in case you are missing the source media or want to package a newer version of the application.

Application Detection and Removal

In this example, we have potential information to help identify the application installation by using the MSI product code found in the Winget installer.yaml file. However, since the YAML file does not match the version of what we are installing, it is best to check to see if the application uses the same MSI product code or not.

Additionally, Winget manifests do not always have the information you need to remove an application. Sometimes, an EXE is placed on the system for uninstalling rather than purely package-driven removal, such as using an MSI product code to remove an application.

AppFinder

AppFinder is a PowerShell script that looks for signs that an application is installed. It reviews the uninstall information most applications register with the operating system to provide a better indication of what to use to detect and remove the application (if needed).

Install the dotnet-hosting-3.1.8-win.exe while testing your silent command line. Next, download and run the following AppFinder.ps1 script to look for the application installation.

When searching for an application with AppFinder, some things can be difficult to find. For example, if we use the keyword net to search for (1), click search (2), and look at the results (3), we will see many possible matches. Click Notepad (4) to export the results to a text file.

The results are then shown in Notepad.

Go to the file menu and select Save As.

Go to C:\Temp, if the folder does not exist then create it. Name the file as 1.txt and click save.

To uninstall, double-click the dotnet-hosting-3.1.8-win.exe.

Click Uninstall.

Accept the UAC prompt, and at the end of the uninstall, click Close.

Next, go back to App Finder, click Search, and click Notepad.

For this file, go to Notepad’s file menu, select File, then Save As.

Save the text file in the same folder you used earlier as 2.txt.

To compare the files, we will use Winmerge, which can be found here: https://sourceforge.net/projects/winmerge/

Please select file, then the Open… menu.

For the first file, click Browse…

Select the C:\Temp\1.txt file, then click Open.

For the second file, click Browse…

Select C:\Temp\2.txt, then open.

Click Compare.

After comparing results, we see that three different pieces of software make up this installer.

Looking at all three entries, this one looks like it might control all three as it is an EXE, while the other two are MSI.

—————————————————

DisplayName: Microsoft .NET Core 3.1.8 – Windows Server Hosting

UninstallString: “C:\ProgramData\Package Cache\{7186a742-a2d9-4dab-80df-80aa5e8013e3}\WindowsServerHostingBundle.exe” /uninstall

Version: 3.1.8.20421

Publisher: Microsoft Corporation

InstallLocation:

—————————————————

To verify the assumption for the uninstall, go through the above steps but use the following command with the passive switch to remove all three packages. Add the following to an uninstall.bat file and try running it with an elevated command prompt for testing.

“C:\ProgramData\Package Cache\{7186a742-a2d9-4dab-80df-80aa5e8013e3}\WindowsServerHostingBundle.exe” /uninstall /passive

You may notice that the command has what looks like an MSI product code {7186a742-a2d9-4dab-80df-80aa5e8013e3}. So, you may wonder why I don’t uninstall the MSI via the command line instead. Sometimes, following what the vendor does is better, as you may not know how to uninstall logic in the EXE.

With the package uninstall command confirmed, we can create a detection method. In this method, we will use a script to detect the MSI.

Application Detection Script

It is recommended that a script is used to detect application installation. While it may seem scary at first, using a template will go a long way to making the process fairly painless.

Before proceeding, visit the Appendix: Installing and Configuring VS Code. You must edit a detection script template for your Win32 application in Intune.

We have identified a product code for the application installation that should be the preference for application detection. Go to the following code.

https://github.com/kkaminsk/Win32PackagingExamples/blob/main/Detection%20Methods/Detect-MSI.ps1

Click the download icon.

To tailor the detection method script, change the following variables.

  • 1: $applicationname – use the application name assigned to the application.
  • 2: $version – use the package version assigned to the application.
  • 3: $packageversion – use the package version of that specific package.
  • 4: $msiproductcode – replace with the MSI product code used by the application installer.

Open an elevated PowerShell prompt and run the script to see if it detects the installed application.

If you check in the C:\windows\temp folder, the log for the detection method is found.

Making a Win32 Application Package for Intune

When importing a simple package or a wholly repackaged piece of software, it is important to understand the process of creating an .intunewin file and populating the application information in Intune.

Package Files

I’ve put a copy of the package files on GitHub for you to use with this section if you did not build the install, uninstall, and detection scripts.

Win32PackagingExamples/DotNetHosting-V3.1.8-R1 at main · kkaminsk/Win32PackagingExamples

Also, because of the size, I have included the installer here.

https://storage1cactl.blob.core.windows.net/public/dotnet-hosting-3.1.8-win.exe

This application is old and should not be deployed to production. Find a newer release, if possible, in these situations, but my mission was to package this old version.

Building a Test Group

Devices or users can be targeted for testing, but generally, unless there is a reason to test user-triggered installation, a device test group would be used. To test the software, build an Entra ID group for test devices. In the Intune portal, select Groups, then New group.

Name the group according to the naming standard. I’ve added a test so we know it isn’t in production yet. Under Members, click No members selected.

Select the device to use for testing, and it will appear on the right-hand side of the screen. Click on Select to continue.

Select Create.

Preparing for Making an .IntuneWin File

I usually have a temporary area on the root of C:, such as C:\Temp, to make the file. The source files, excluding the .intunewin, should be backed up to OneDrive or a common file share. These files may need to be revisited, so ensure that at least one previous version of the package is backed up.

File Structure

There will be a series of files in the working area, such as C:\Temp.

  • IntuneWin32AppUtil.exe
  • Detect-MSI.ps1
  • Logo.png
  • DotNet_Hosting3.1.8
    • dotnet-hosting-3.1.8-win.exe
    • Install.bat
    • Uninstall.bat

IntuneWin32AppUtil

In order to wrap files for delivery with Intune, they must be wrapped as an .intunewin archive. Once the archive is made, it is uploaded to Intune and, after a successful upload, is no longer of use.

To get the tool, download it from Github over here:

microsoft/Microsoft-Win32-Content-Prep-Tool: A tool to wrap Win32 App and then it can be uploaded to Intune

Select the file.

On the left side of the screen click the download button.

Copy the file to C:\Temp. Open a command prompt, and run intunewinapputil.exe.

For the source folder specify dotnet_hosting3.1.8.

To specify the setup file just use install.bat.

For the output folder, specify C:\Temp.

Do not specify a catalog folder as we are not packaging for Windows S Mode. Press N then enter.

When complete your screen should look something like this.

Creating a Win32 Application in Intune

First, as an Intune Administrator, log into https://intune.microsoft.com and select Apps, then Windows.

Click Add, then expand the drop-down menu below App type. Select Windows app (Win32), then click select.

Click Select app package file.

Select the folder icon.

Go to C:\Temp and select the install.intunewin file and click open.

Click OK.

Enter the Name per your naming standard, then describe the application. Generally, the description doesn’t need much detail unless the software targets users as available software they can install. Be sure to fill out the publisher; the version is usually part of the object naming standard but is not required.

If you want to specify a logo for the application the end-user sees in the Company Portal application, scroll to the bottom of the screen and click Select Image. Ideally, you have created an icon image with AI or downloaded it from images.google.com. In this example, we will use a Windows Installer logo downloaded from images.google.com.

Beside the Logo field, click the folder icon.

Click the logo file then the Open button.

You should see the graphic. Click OK to continue.

Click Next.

Enter the install command as install.bat and the uninstall command as uninstall.bat. Leave the rest as defaults and click Next.

Under requirements, set the operating system architecture to 64-bit and the minimum operating system to Windows 10 22H2 since you should not run anything older than that. Click on the Next button to continue.

Select Detection rules, Use a custom detection script, and then the file icon.

Select the C:\Temp\Detect-MSI.ps1 file and click Open.

You should notice that the script has been uploaded. Click Next to continue.

This application has no dependencies, so click next.

There are no applications that this will supersede, so skip this section by clicking Next.

In the assignments page, under Available for enrolled devices, click Add group.

Search for the group and select the checkbox beside the group name. The group will appear in the right-hand corner of the screen. Click on Select to continue.

Click Next to proceed.

Click Create.

Wait to make sure that the application is uploaded.

Eventually there should be a success message indicating that the upload is complete.

Testing

Using the Company Portal application testers can trigger the installation of software by usually finding it under Recently published apps.

A screenshot of a computer AI-generated content may be incorrect.

After selecting the application, you can click the Install button on the next screen.

A screenshot of a computer AI-generated content may be incorrect.

On the top right, you will see the installation status.

A screenshot of a computer AI-generated content may be incorrect.

You may notice a toast notification before the Company Portal application updates.

A screenshot of a computer AI-generated content may be incorrect.

In the top right corner of the Company Portal application, you will see an Installed success message.

A screenshot of a computer AI-generated content may be incorrect.

Conclusion

As you can see, even if you think you know enough about your application, the packaging process can be full of challenges that require problem-solving to produce a working package. Hopefully, you won’t be packaging out-of-date software like me, but it does show how we can figure out the necessary details with sound methodology.

As a parting idea, I recommend keeping notes when packaging because some application packages are time-consuming to test and can be very difficult to package. Especially when the complexity is high, you need those notes for future documentation and troubleshooting. Be organized when tackling these issues, as you don’t want to be second-guessing what has been and has not been tried to fix a problem.

Anyway, I hope you learned something and till next time!