Blogs

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.

DEPLOYMENT STRATEGIES

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.

DEFINING THE NEED

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.

Training

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.

PACKAGING APPS FOR INTUNE

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.

TESTING

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.

DEPLOYING APPS FROM INTUNE

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.

#ITOperations
#Microsoft
#FutureandEmergingTechnologies