Drilling into why we follow certain practices
Introduction
This will appear as quite a "we already know" kind of article, but there is a purpose for this as well :)
Everybody may not be aware, savvy or know the full picture behind why we do certain practices, follow a best practice or any kind of practice at that! So this article is really to outline specifically the process in which we use to create applications within Endpoint Manager, especially around Windows applications.
There are many different types of applications we can create in Endpoint Manager and it's important to highlight as to why we go with certain options when we make our selection.
The topic itself has been discussed numerous times before and may overlap somewhat, but what I want to achieve with this is to centralise a lot of the reasonings, practices and understanding and for one which may grow overtime as well depending on new changes or new updates which may come along in the future.
Line of Business Applications
So to summarise quickly, Line of Business Applications (LOB) are primarily applications which are packaged within Intune which are using MSI file extensions. They are used because they bring the most convenience in terms of just a quick upload of the file and pre-filling a lot of the windows which you would normally have to do if you were to construct a different application type such as a Win32 application or a Microsoft office 365 Application.
With its instantaneous setup you also have the command-line arguments preconfigured on the assumption that you will of course go with a silent installation and one which will not suddenly reboot the machine as you would prefer to control this from other areas within Endpoint Manager.
Below in
Figure 1.1
is the example of a Line of Business Application configured in Endpoint Manager.
Win32 Applications
Win32 Applications are a very similar process which you would see in the Applications process within SCCM when packaging an application which doesn't use file extensions which pre-fill majority of the fields such as MSI, App-V etc
Instead of having an easier configuration with the LOB applications you have a much wider range of options to configure the overall package and also deployment of the application, options in which we will cover a lot closer in the sections below.
Win32 applications take on a .intunewin extension which have the requirement of source files being converted into a .intunewin file extension before it can be uploaded and configured into an application. Below in
Figure 1.2
is an example of a Win32 application configured within Endpoint Manager.
Why we choose Win32 Applications over LOB Applications
The title does seem bias, and it is :)
There has been a lot of real case scenarios as to why we go with one over the other but isn't without good reasons. And some if not all of the categories below I'm pretty sure a lot of us are familiar with. But what we want to do is perhaps dive a little bit more in the perspectives of other roles which people might have as reasonings can always differ depending on the situation or scenario at hand.
More Options for Deployment
Though the benefit of convenience gets robbed from us when we go through this type, there are a lot of benefits which give the administrator a lot more authoritative control over the whole packaging process. And that is very important taking into account the requirements you have.
Here are the following categories which we get when going through this option;
- Program
(Install/Uninstall Commands, Return Codes)
- Requirements (OS level and system requirements)
- Detection Rules (How the application is detected as Installed or Installed)
As much as we would love to have every package as an MSI (might not be a shared opinion) in a real-world scenario not every application is going to be configured that easy, in fact MSI packages also would be subject to the same drawbacks which we will also cover later.
Program
Here we define what the commands will be for Installs and Uninstalls, as well as its behaviour for installs and restarting.
Now in comparison to an LOB application installs and uninstalls are configured as well as the assumption of suppressing a reboot and notifications. But what if we require a reboot to take place? And if we do how are we able to have better control on its behaviour?
The return codes can also be an important factor as various applications may not be built to end with a return code or exit code of 0. And if we look at that from an MSI package perspective if it wasn't a 0 (depending on how its built) it could always be perceived as a failure. So being able to understand the return code output and having control over that is very important.
Requirements
This is also a very important section where we can define as to which applications will actually receive this deployment which would be determined by its OS and System Requirements. This does in fact bring us some level of convenience here. As with an LOB application we don't get this configuration, so we would have to carefully configure an equivalent by creating a group which would then have a similar configuration within its dynamic membership rules.
You can of course have a manual membership rule which would be a lot harder to maintain, but it would assure which devices are receiving the deployment and which should.
Detection Rules
Having more control of knowing how to detect whether an application has been installed/uninstalled is also a very handy option to have.
Again very similar to SCCM where we have options for using Registry, File/Folder detection methods as well as MSI and defined custom scripts. We will have more on detection methods in another article in the future.
The LOB Application using MSI simply just uses the MSI product code to detect its install, but depending on our requirements it may not be as simple as that unless its packaged within the MSI the correct way to check all of this, then we would need an alternative method which would be accurate for us.
Packager Perspective
This one is quite interesting especially if you are a packager and then uploading applications into Endpoint Manager for deployment.
When we package applications, there are so many things to take into account when it comes to the decision as to which option we would go with and the majority of the time it would tend to be Win32 Applications and here are the reasons why.
See the output when we normally package applications is going to be MSI. But of course as you would have seen from a lot of the options we get from a Win32 Application template, there can easily be a lot more bits to consider when it comes to the overall configuration of the application especially when further customization is involved. And if they are not already in an MSI then the additional configurations can derive from an
MST
file.
Sometimes not even an MST file, but we could also have loose .CAB files which contribute to the MSI application being installed and configured correctly once deployed.
So lets step through for example the
Programs section. Now with the install and uninstall commands, we can of course use an msiexec command, there's nothing that stops anyone from using an MSI package from being configured as a Win32 app, the reasonings and further experience configuration is what drives us to use this. Within a LOB application configuration you can upload an MSI yes, but you won't be able to upload the MST
and the additional
CAB files which are required for it though. You maybe able to do this if you compress an MSI file with the CAB files to be embedded but depending on the application you are packaging it could be come quite sizeable so that's something to be mindful of.
It's installation behaviour is also something to take into account as the application packaged may very well require a reboot to take place so this is where the behaviour experiences become a lot more important. And the even more important one of course is the return codes! We may have multiple return codes depending on how we have built the application so we want to reflect that so when it comes to collecting logs we can analyse further as to if something has been successful or not as well as the default mechanism within Intune.
Issues with mixing LOB & Win32 Apps
The general rule has always been not to mix the two of them in the same processes, specifically naming the Autopilot process.
Reason being? Is because it's a lot more prone to errors. I have seen a lot of cases where within Autopilot provisioning you will see applications literally hang or not move when it gets to a certain application. And though this is randomized if you have a mixture you could have a good guess as to the type of application which could be causing this.
There isn't really an easy way of getting around this so its best to just not mix the two to avoid complications.
Error Handling
When we troubleshoot failures from deploying applications in Intune, and MSI packages in general the most common return code you will most likely come across is
1603
which is a custom action error. This can cause a lot more issues when it comes to troubleshooting overall.
Logs within
C:\ProgramData\Microsoft\IntuneManagementExtensions
will only reveal so much which is really more around the error code itself. So really the more detailed logs will come from the msiexec switch being /l*v <LogFileName> , which could be placed in the same location as mentioned above which can also help when collecting logs from the Endpoint Manager buttons.
Doing this troubleshooting may be trickier in a LOB only because you might use the same switch and discover the issue but if its related to a missing CAB file related to its MSI tables, or an MST is missing it could lead to more repackaging or just longer amount of time to understand what is happening.
Conclusion
In closing there are a lot of things to consider when it comes to selecting any option when it comes to creating applications or migrating applications across to Endpoint Manager. Any decision made shouldn't go without its testing but also analysing the scenario in which you have and how to best configure the application correctly as well as it working on the endpoints in which it is distributed to.
