Tune Up Your App Deployment with Microsoft Intune

By Daniel Creaney posted 01-08-2024 16:01


Microsoft Intune is a cloud-based, agentless, infrastructure-less, VPN-less endpoint management solution (MDM) designed to manage workstations, laptops, tablets, and mobile devices with similar operating systems and configurations with the settings available via Microsoft’s API. This post lays out some strategic thinking around how to provide good, scalable, and repeatable application deployment work to the business around Microsoft Intune.


When I think about application deployment, I broadly see five points:

  1. Defining the need for an application
  2. Packaging of the application
  3. Testing the application
  4. Deploying the application
  5. The follow up

Each of these points marks a conceptual stage in the application deployment cycle. The technical details of installation of a particular application are (with luck) already well documented and provided, or easily findable on the web. What is less known is the practice of smoothly applying ones and zeros to a machine in active use. In any environment you are likely to encounter that the process defining success will be different. Naturally the human, business, and technology stack will vary. What will generally be the same is the ‘out of the box’ application up for deployment. My aim here is to suggest a loose framework for standardizing how a team might go about streamlining their workstation application deployment work in a cloud forward manner using Microsoft Intune.


When thinking about the 'need for an application' you will either have a new application or an update to an existing one. Each need will come with deadlines and when deploying a new application to your environment you will hopefully have some flexibility on the rollout schedule. When upgrading existing applications, encompassing thought toward security, reducing technical debt, and adding features (value), getting updates out sooner is best. Thereto I’ve laid out four deployment facets worthy of consideration when designing an app deployment strategy. Further, each of these would be paired with good thought to end user training.

1. Just in time deployment

This method I see as having a template 'package' ready to go once you receive the .msi, .exe or whatever form it might take (the ones and zeros, or ‘The Bits’). Perhaps a script with your library of functions developed over the years to cover most customization eventualities. Add the bits, change a variable or two, and off you go. A reusable blank stating point that can be copied, pasted, and modified quickly.

2. Getting ahead of the curve

A somewhat aspirational strategy involving awareness of each vendors release schedule, receiving ‘The Bits' quickly, slotting them into a package and rolling out.
We find that news of releases and updates come in different forms and places across vendors. Signing up to vendors mailing lists if possible is a good start from which a task board could be automated for the team.

3. Maintaining up to date applications

Concerning nuances in maintaining current versions of applications. Some applications auto-update and save us time so there may be no need to repackage- until the base version on your workstation image becomes woefully far behind. How often do you update the baseline package for auto updating applications? When a new machine is deployed it will typically contain the base level application version that was published in Intune at the time it was imaged/deployed, and over time the app will self-update. At some point there will come a tradeoff between effort spent repackaging the update to the base version, and time taken letting the new machine come up to speed via auto updates- and potentially being vulnerable while it does so. My recommendation is to repackage for base versions quarterly or semi-annually- though may be dependent on vendor release schedules.

4. Shortcuts

How can we get some time back when application updates come ever thick and fast and demands to patch bugs ever more urgent. For general third-party apps (think Zoom, Notepad++, Google Chrome, etc.) there are shortcuts like PatchMyPC (PMPC for short) that will automate the retrieval of the package from a vendor, the packaging, and deployment.


Do you need it or not? For most small, incremental applications probably not. But for core business apps training and awareness is vital and integral to a successful rollout if there are material feature changes, or even perhaps minor UI tweaks. I’ve never regretted consulting the training team and good telegraphing of changes to the Firm.


I am going to focus on the most common Intune app format that I have used being the Windows app (Win32) for Windows 10 (1607) and above. This app format covers most scenarios for deployments and customization. Within the Win32 app Intune has its own filetype that packages must be compiled to so that they can be uploaded to Intune. The file extension for this filetype is the extension .intunewin. We use the Microsoft Win32 Content Prep Tool to wrap our packages in the .intunewin format ready for uploading to the Intune service.

Aside from the bits from the vendor the real meat of what defines the package and how it gets installed is best handled in my opinion by the PSAppDeployToolkit which is free to use. PSADT gives you a starting point of prebuilt functions to install/repair/remove applications. It provides a UI notification and deferral system for when a deployment hits a user’s machine, all built in PowerShell making it easy to reference and modify.

There are going to be some specific customizations for your firm that fall outside of the prebuilt toolkit that can be added into the script, and it’s here I refer back to the 'Just In Time Deployment' idea and making your 'one off’ customizations into PowerShell functions that can be called quickly the next time that ‘one off’ regkey needs to be modified in a specific way.


Now that you have a viable package in hand, before sending it out I recommend a five-stage testing plan on the runway to production:

  1. Individual testing
    a. This is your personal smoke test. You as the packager will want to try the deployment on your test machines to ensure, as best as possible, that when someone else sees the install process that they don’t receive an easily avoidable error
  2. Team Testing
    a. Have your immediate team members validate your experience from step 1. 
  3. Department Testing / Piloting
    a. Send it to the IT department to feel the experience on a range of configurations. If possible, include a friendly group of ‘super users’.
  4. Training Team Testing
    a. If possible, let the professional testers take a look, for errors and crucially for functionality. These are the folks that know what all the buttons do and can provide the best feedback.
  5. Change Management & Awareness
    a. Lastly and arguably most importantly before sending an application out to the user base is awareness. Of what is happening, and when.


So, we have our tested application package uploaded in the correct format to Intune. Here I will touch on some of the currently available and most useful options for defining the deployment parameters.

We can do some interesting things when defining the parameters for an application to be installed. A step that has helped me a bunch is being able to skip an install if a particular legacy application is present on a machine via the requirements definition page. This is a decent way to ensure that the legacy app is removed before the new app comes down, say in the case of conflicting versions, or replacement of one vendors solution with another. This comes in handy also with apps that self-update, ensuring that if an app is updated Intune doesn't revert the app back down to the published Intune version.

Dependencies / Layering

We may have bundled any dependencies into the main package via PSADT or created separate packages we need to string together in the Intune console. We can get creative with dependencies, creating an installation chain that ensures all pre-requires are installed prior to the main package, for example things like Visual C++, Edge Webview, etc., possibly third-party apps that we are now having managed for us by a tool like PMPC. A deployment will be recorded as successful in the Intune status pages once all pre-reqs are successfully installed along with the main application.

When targeting our audience for an app, we device if it will be Required, meaning forced to a machine or user. Or Available, meaning a user can choose to install it for themselves if they wish. The dates and times for installation can also be defined here, along with the ability to pre-stage the content in the background for installation at a specified time.


The supersedence page allows us to automatically update or replace an installed app with the new one we are about to publish- particularly useful for Available self-service applications that may not be installed on every machine, but nevertheless need to be updated when a new version comes out.
Detecting Installation
We can get very granular with detection rules to ensure that all aspects of an application have been installed correctly. I find the MSI, and Registry options to be the simplest measure, and would layer multiple rows of criteria for most robust success. To get deep we can assign a PowerShell script to detect more of the minutia of the installation. This is an important step to get right, as I’ve seen apps functionally install, but return as failed in the Intune status page for faulty detection rules.


Intune provides some useful metrics for gauging the progress of an ongoing application deployment and the success or failure of installation for users and devices. From the status pages we can discern how many installs are pending, inflight, and have completed, very useful for providing status updates and heading off issues. We can use these statistics to measure against what we advertised to the business in our change management and awareness initiative that preceded the rollout. It is vital to know if you have been successful, or not.

Thinking about the strategies and environment surrounding technology I believe will help us to wield it most effectively. Microsoft Intune and the eco system coming up around it are powerful tools in the application deployment professional’s toolbox, however success lies in the surrounding processes, departmental relationships, and operational strategy employed. Thank you for reading.