Intune vs. Microsoft Configuration Manager: Packaging and deployment comparison

After more brand-tweaking, Intune and Configuration Manager are now part of the Microsoft Intune product family. Whilst you could compare them endlessly across a host of use cases, for this article, I’ll concentrate on how effective each is for application packaging and deployment. Before I do, it’s best to start by getting an overview of what they are and what they do. 

Configuration Manager, previously known as SMS (Systems Management Server), then SCCM (System Centre Configuration Manager), and more recently Endpoint Configuration Manager, has been around in one format or another since 1994 and is, at the time of writing, at version 2203. It was traditionally used to manage domain joined on-prem Windows devices. Whilst it can now be extended to cloud joined devices via Co-Management and a Cloud Management Gateway (CMG), it’s still only for Windows devices (including servers). It can also be used for bare-metal provisioning and has powerful reporting tools built-in. 

Microsoft Intune, originally Windows Intune, has been around since 2010 and is a cloud-based Mobile Device Management platform that supports all main devices, including Windows, Android, iOS and macOS. As well as some support for Linux. It can’t do a bare-metal build but instead uses Autopilot to take an off-the-shelf build and adjust it accordingly. 

As it’s cloud-managed, there’s no requirement for devices to be within an on-prem network, and devices no longer need to be domain joined – known as hybrid joined. Devices can instead be joined directly to Azure Active Directory, which increases the security posture and management. 

With the Coronavirus outbreak of 2020 forcing the vast majority of staff to work from home, companies soon discovered that even after improving VPN capacity, managing devices which aren’t connected to the corporate network on boot-up is more difficult. This has led to increased uptake in Microsoft Intune usage. 

With that out of the way, if you’re looking at which of these to choose or are already using Config Manager and considering moving to a cloud-managed estate using Intune, we’ll look at the application packaging, deployment and management options of the two tools. 

Configuration Manager

Deploying applications from Configuration Manager uses source files stored on a UNC path, usually on the primary server. For multiple sites, you can then add distribution points, including a cloud one in Azure, for machines to download the files from the nearest location, which is set via Boundaries.

It’s worth noting that there are Azure storage costs for the source files if you’re using a cloud distribution point.

Supported application types

There’s native support for the usual application types, including MSI, MSIX, and AppX, as well as executable installers providing they support silent parameters.

On top of this, you can deploy Edge for Business and the M365 app suite using the Office Configurator. This requires an additional plugin to be enabled within the console. 

If you’re using App-V in your environment, that’s also supported directly from within Config Manager, which isn’t something available within Intune. This is an alternative to the full management App-V environment with a management and publishing server. 

For anyone just starting out, App-V is no longer being maintained and is scheduled for end of life in 2026. Whilst that’s been extended from 2023, it’s recommended you look at the newer packaging formats like MSIX. An App-V package can be converted to an MSIX package using the Microsoft MSIX Packaging tool. 

Application installs, updates and deployment

With machines accessing files directly over the LAN to the nearest distribution point, Config Manager handles larger app installs with ease. 

Applications can be deployed during imaging in the task sequence, force installed after-the-fact, or marked as available for users to self-service within Software Centre. You can also configure installation dates/times to ensure critical applications or application updates are installed before any deadlines. 

You can also group applications so, for example, a user in your HR department could automatically receive all of the apps required for the role. 

Application updates are handled exceptionally well. You simply package up the new version and deploy it as a replacement. The client will handle the rest for you. 

Another useful feature is the ability to simulate a deployment which will evaluate your install, uninstall and detection methods with the application you’re trying to deploy. 

You can target your application installs based on Collections, either at the user or the device level. This gives you extremely granular control over who receives which applications, including Active Directory OU based, or even drilling down to the device make/model/hardware specs for those more complex applications. 

The reporting functionality in Config Manager is excellent. The client sits on your machines and regularly reports on install status, discovered apps, and so much more which you can query with the powerful SQL-based query tools – Config Manager runs off a SQL database. 

Intune

Now, moving on to Intune, which is entirely cloud-based, as previously mentioned. Users on Azure AD joined machines can still access on-prem resources seamlessly if you configure Cloud Trust, which is, thankfully, a very seamless process. 

Applications are stored and deployed in Azure blob storage, meaning machines simply need internet access to receive applications. It eliminates the need for distribution points and cloud management gateways but will obviously be slower than your typical on-prem 10Gb network connection. 

There’s no cost to store your apps within Intune. The storage is included in the licensing, but it’s also not in an Azure Storage account you own. So, whilst there are ways to find and extract the files, it’s best practice to keep a copy somewhere readily available.

Supported application types

Out of the box, Intune supports MSI Line-of-Business (although not recommended, it is better to wrap them into a win32), MSIX, AppX, Store for Business and your standard win32 executable apps, again, as long as you have the silent install parameters. 

As mentioned earlier, App-V packages are not supported in Intune, but you should be looking to migrate these to a newer format anyway. 

Win32 applications take the source files and ‘wrap’ them into an intunewin format using a tool direct from Microsoft. This intunewin file is an encrypted archive file that compresses all of the files in the directory you have pointed the tool at. 

Never build from your downloads! 

When deploying to a device, it downloads, unencrypts, extracts and then runs the install command specified. 

On top of this, there are GUI tools available for Edge and M365 apps, but most tend to re-package M365 into a win32 app for more reliable deployments. 

Application installs, updates and deployment

Applications can be installed in the System or User context, and there are workarounds for apps which need both. 

You can configure custom requirement rules to restrict applications from installing onto unsupported devices, similar to the collections in Config Manager. 

Application supersedence is supported for Win32 applications. You can set the replacement application to either install over the top or to fully uninstall the old app and install the new one. You can also add dependencies so that if an application requires something else in place first (often a runtime), it will automatically install the dependant application before pushing out the intended application. 

Out of the box, Intune is restricted to installing files of up to 4Gb, but this can be expanded by logging a support request. Keep in mind that these installs are over the internet, so a particularly large software install could take some time to download. Consider whether using a VDI environment connected to the Microsoft backbone may be a better option. 

On the targeting side, applications are deployed to Azure AD groups which can be static or dynamic. For a static group, you simply add the users or devices into the group, which will then receive the application. You can also configure groups to be excluded from an application install as well as a target for uninstallation. 

A dynamic group can be configured to automatically add users or devices based on the criteria, for example, users in a particular OU or office location. 

One important thing to note is to never mix user and device group targeting. If you target a user group for installation and then exclude a device group, the rules are processed individually, so there’s a chance the user group will be processed first and the application installed before the device group finishes processing. 

A relatively new addition is the ability to add filters so you could target all users or all devices and then add a filter at the device level on top of that, which is especially useful for hardware-specific applications and does not require the processing of dynamic rules.

Similar to Config Manager, applications can be installed during ‘imaging’, and you can force a specific subset of applications during the Enrollment Status Page (ESP) in Autopilot, which will block users from accessing devices until these applications are installed. Post-imaging, applications can be force installed, as required apps, or self-service via the Company Portal application as available apps. 

Again, you can set an application deadline to force installation at a specific date/time. However, occasionally, it isn’t quite as precise as using Config Manager, largely because it’s internet rather than on-prem based. 

Which would you recommend?

For a new environment, moving to cloud-managed, Azure AD Joined devices with Autopilot is the clear direction of travel from Microsoft. To utilize this new technology fully, use Intune for your app packaging and deployment. 

There are some niche use cases for Config Manager, such as environments with very restricted or no internet access, but on the whole, with users increasingly wanting flexible working locations, Intune is the sensible option. 

As a platform, it’s constantly evolving and improving, plus it gives you the ability to manage your non-Windows devices from a central location. 

I’m just starting out. Which format would you suggest for my apps?

Initially, it’s always worth checking what’s in the Store as that takes the packaging and updating work away. Still, often these apps are stripped-down versions of applications, so make sure the functionality is all there and it’s an official app. 

As mentioned earlier, App-V is scheduled for end-of-life, so that’s not a route to go down in 2023. 

MSIX is constantly improving and does show potential, especially if you’re using AVD (App Attach is a very useful tool), but it’s reasonably resource intensive as the apps all need to be re-packaged and also requires signing with a code-signing certificate which brings with it additional cost. You can use a self-signed certificate, but that’s more overhead to deploy it to your devices. 

Win32/Intunewin is the best option for packaging your applications as of the time of writing. It offers all of the extra features available and is tried and tested technology. 

It’s also worth monitoring the Windows Package Manager (Winget), which powers the Microsoft Store. An easier configuration of a private repository is in the pipeline and should make deploying and updating applications easier. 

What if I’m already using Configuration Manager?

The good news here is you have several options available to you. 

Firstly, you can take the applications deployed within Config Manager, grab the source files and wrap them into an intunewin to deploy to Intune using the same install commands and detection rules. 

You’ll either need to re-build or set up Co-Management to get your machines to see these apps. 

Once you’re enrolled into Co-Management, you can configure workloads. 

In this case, you can switch Client apps over to Intune, which keeps the Config Manager client on the device, but tells it to use Intune for all application deployment and updates. 

You can also deploy the Config Manager client to your Autopilot devices, which would normally be installed during the task sequence, so you get the best of both worlds. 

Final thoughts

Now is the time to look at your move to Intune, whether it’s starting fresh or migrating from your current platform. 

Whilst it isn’t perfect, the recent improvements are excellent, and you can see from the roadmap that this technology is being heavily focussed on. Azure AD Joined machines are more secure and easier to manage in the new mobile, flexible, hybrid workplace.