How to manage dependencies in INTUNE?

INTUNE application packaging as we know it today, has been around for a while. One of the most common questions I get from different companies that we provide packaging services to is: “Why do we have to package dependencies separately?”. In other words, rip out dependencies from vendor installer, such as VC++ Redistributables, .NET, MSXML, etc.

Since this question seems to become more frequent, I wanted to take the time and share my explanation about how dependencies work and give a little insight as to why we need to rip them out and create a separate package.

Let’s start with dependencies. Why do we have them?

When vendors develop their software, more often than not they use common libraries, for the sole purpose of not ‘reinventing the wheel’ and therefore reducing development time. By doing so, they increase software performance since these libraries are proven and streamlined over the years. For example, “Visual C++ Redistributable” contains DLL (Dynamic Link Library) files, which are required by software or games when those are built using Microsoft’s Visual Studio. So what consequently happens is that whenever software requires a DLL or some other supporting file to run, it automatically looks for dependency on the particular device where software is installed.

Intune has very similar functionality as SCCM, so you can map a dependency to be installed before the main application. This feature works like a charm IF you have Win32 apps (*.intunewin file). Meaning that if you have any other apps but Win32, then you won’t be able to map the same type of apps as a dependency.

There are 3 ways of managing dependencies using Intune:

Include dependencies in the image – it doesn’t matter whether you use SCCM or AutoPilot, you still have to build packages separately or use a silent install switch on the original installer. The benefit of doing so is that you can include the most common dependencies to be installed as part of the image for your business-critical applications. The downside is that you don’t know which application needs which dependency, so if you suddenly decide to upgrade a dependency to a new version, you won’t know if it will impact any other application or not. Therefore, doing it this way you will have them as a separate package, and IF you have a change within your environment you will be able to track back any changes you have implemented: for example, upgraded dependency to a new version.
Install dependencies using vendor installer – when you use a silent switch to install your vendor installer, it also takes care of installing missing dependencies automatically, thus it doesn’t matter what components are installed on devices. The benefit in this scenario is that you don’t need to manage dependencies or even package them separately because the vendor installer takes care of them. The downside is that you might have a very messy environment filled with different software and several versions of those. When something doesn’t work, you might have to spend hours troubleshooting unless you wipe that user’s device. I would personally not recommend this option, however, it is quite common since it saves costs on finding or mapping dependencies, and likely saves costs on the packaging as well, but one will have to bear the potential consequences outlined earlier.
Map dependencies as separate apps within Intune – you have to build packages yourself or buy them as a pre-packaged option (check out our offer HERE) and map required dependency to match each Intune app for the application to install. The benefit is that you will know which dependencies are needed for which app, therefore you will be able to maintain your environment properly. The downside is that you will have to find which app needs which dependency and you will have to extract this dependency out from the vendor installer, but once you do that, you have a better end result in my opinion.

SCCM had always had the option to map dependencies as a separate package, and now you can also perform the same within the Intune environment as well (it has been there for a while), so I recommend using this option to have a clean and productive environment. By doing this you will spend less time troubleshooting application issues. Your initial time investment will be finding dependencies and riping them out from the vendor installer, but if you do it right from the get-go, you have far less headache in the future.

When asked, I always suggest and encourage to package dependencies properly and not just by relying upon the silent switch.

Below is a list of the most common dependencies we recognized and currently offer them pre-packaged for purchase and seamless deployment within your Intune environment:

Microsoft Visual C++ Redistributable 2005 SP1 x86
Microsoft Visual C++ Redistributable 2005 SP1 x64
Microsoft Visual C++ Redistributable 2008 SP1 x86
Microsoft Visual C++ Redistributable 2008 SP1 x64
Microsoft Visual C++ Redistributable 2010 x86
Microsoft Visual C++ Redistributable 2010 x64
Microsoft Visual C++ Redistributable 2012 x86
Microsoft Visual C++ Redistributable 2012 x64
Microsoft Visual C++ Redistributable 2013 x86
Microsoft Visual C++ Redistributable 2013 x64
Microsoft Visual C++ Redistributable 2015-2019 x86
Microsoft Visual C++ Redistributable 2015-2019 x64

In case you need packaging services and/or consultation on Intune apps, UonCloud is happy to help. Here is a link (Common Intune Dependencies) if you’re interested in learning more about the before-mentioned common dependencies.

I hope you found this useful and I’m happy to answer any questions you might have.

Written by Martins Kurtiss