Why not to mix Win32 and MSI LoB applications in Intune

by

After a recent Reddit thread and some queries around it at the MEM Summit in Paris, I felt it might be a good idea to get this in writing rather than just word of mouth.

We all know that mixing Win32 and MSI LoB apps is a recipe for disaster for Autopilot, but there is a lot of misinformation and no-one really explains why.

Firstly, for anyone who claims it’s always worked and it’s not a thing, here is the official guidance from Microsoft:

Source: https://learn.microsoft.com/en-us/intune/intune-service/apps/lob-apps-windows

 

Some points on this before we get into the why:

  • This ONLY applies to MSI LoB, don’t worry about your AppX, MSIX packages, they work differently
  • Whilst this only causes an outright fail in Autopilot, it’s still a risk if users get trigger happy on available installs
  • The source of the MSI DOES NOT MATTER

MSI LoB was an easy option for quickly throwing apps into an estate without having to do any wrapping, testing or anything and in fairness, they do deploy earlier than Win32 apps.

But you are also missing out on supersedence, dependancies, delivery optimization, custom requirements, custom detection, the list goes on.

 

But why?

Now the bit you are here for, why does it cause issues?  As you can see in the blue box, it’s because they both use the Trusted Installer Service, but what does this mean?

When you deploy a Win32 app, it uses in the Intune Management Extension (IME) to grab the app details, kick off the installer, wait for the exit code, detect it and then trigger the next one.  All nice and straight forward and you know the IME is putting them all in a queue for you.

MSI LoB on the other hand is just sent straight to msiexec on the device.  Intune will stagger your MSI LoB installs, but it has no awareness of them so will add your Win32 ones soon afterwards.

If you are lucky, the apps will have completed installing before the first Win32 hits, but if not, your Win32 app will start the installer, trigger msiexec which will get extremely unhappy because it’s already in-use.  We’ve all seen the familiar “there is already an installation in progress” screen, only this time it’s in the SYSTEM context AND during ESP so no-one sees it at all.

The end result is no-one can click the retry button, the app is stuck in limbo and eventually times out, fails to install and your whole ESP comes crashing down around you

 

So there you have it, if in doubt, always wrap as a Win32, it’s extremely easy, I even have a guide on it here

 

Thanks for listening, more like this to come (requests always welcome)

 

Leave a Comment