Oops, we are packaging apps again!

Lots of things are happening in the packaging arena and I wanted to share some insights. Recently we’ve been heavily involved in various INTUNE projects related to application packaging, where companies are migrating their applications from ConfigMgr to INTUNE. Given the amounts of requests constantly coming in, my prediction is that these migration cycles might never end. I know, I know….never say never, but let me elaborate on that because INTUNE has its own twist.

There are several options available for how to build and deploy applications through INTUNE, however, the Win32 app seems to win the popularity contest. In my opinion, overall it’s very similar to the ConfigMgr application deployment type. So where’s the twist?

The tricky part is that there is no way to automatically convert your existing applications into the Win32 app type, but that’s exactly what you need to do first in order to build your app! The good news is that even though it’s manual, the process is actually quite simple, you just run EXE (IntuneWinAppUtil.exe) with a couple of command lines, and Voilà, your app is converted into the Win32 app.

Yes, I’m anticipating that you may not be a fan of manual labor, but I still think it’s a good way to do things. Hear me out.

Rationalizing your application list. Again. YES, I know you did just that for Windows 10, and here I am suggesting it’s a great idea to do it again (easier said than done, since all of this takes valuable time), BUT not only will you declutter your app list, and most importantly this notion seems to be permanent, hence doing it every so often may be less painful after all. So whatever you choose to do, you may still find yourself at these crossroads, unless you implement a proper application lifecycle process OR until your vendors take care of the application maintenance OR you move to the SaaS apps.

But until that time comes, you can still find yourself having few old applications that you don’t actually use/need anymore. Those either ran out of support, yet you still keep it, or you have multiple versions of one, and you’ve never cleaned that up from the old app.

Kinda similar to the way some of us have our garage ”organized”. Tons of stuff we think might be useful, but has been collecting dust for years, until we have circumstances forcing us to declutter! For those of you who are on top of their decluttering game and have all things in order (life and otherwise), I salute you!

Now to the ‘fun’ part aka how to audit your App list.

Pull the data from your Software CMDB, compare and update the list, making sure you only have an active application list. If by chance you don’t have such Software CMBD, I strongly advise you to start building one, as you will surely need it in the future. Check out our way of building CMDB and tracking application list and lifecycle process here: https://www.uoncloud.com/APM for your reference and inspiration.

So, let’s get back to our main question on the agenda – Do we have to package apps for INTUNE?

The short answer is YES, but let me give you a couple of reasons why:

1. Your goal is to provide the best user experience possible. In this day and age with almost everything being remote, you want to ensure seamless installation of packages, that include user configuration, so you eliminate errors and prevent frustrated calls or support tickets from your end-users.
   • When you build a package with configuration settings included, it assures that all your end-users are getting the same application configuration. Then, it’s all for one and one for all, meaning if one of them fails, they all fail.
2. You want to be able to upgrade your applications whenever you release a new version. Sadly not all vendors are maintaining their versions properly, so you might have to force a Required uninstall before installing a new version, and sometimes that could be tricky if you use vendor Silent switch.
   • When you build a package, you can fully control the Upgrade codes through that building process and thus ensure that those codes automatically remove the old version. I must say that one of the most commonly made mistakes I’ve seen companies do, is trying to clean up end-users devices with custom scripts or PowerShell. Why do I consider that being a mistake? It’s such a time-consuming task, that can be avoided!
3. It’s no secret that remote troubleshooting for application installation can be quite challenging if we compare it with doing the same on the local network. The end-user device in question may not be available (via remote network) hence by building your packages you may already pre-assess the root of the issue.
   • When you build a package, you can include extra logs and find out failure reasons. You can educate your users on how to send their logs when something is not working, thus you don’t have to try and coordinate a remote session with them.

Trust me, I sympathize with you on your unwillingness to package all your applications because, let’s face it, once you do it, you have to do it again and again, BUT that’s just the reality of it and it’s called ‘proper application packaging’ for the lack of better wording. You get my point.

I would sincerely suggest completing the minimum on the ‘self-help’ list by adding logs or brand keys to your packages. At the very least you’ll know if the package was installed or not. INTUNE has the logic to verify application deployment status, but it’s not always giving you the required instant feedback if the application was installed successfully or failed, therefore you’re giving yourself an advantage ahead of time, by adding those logs or keys.

RECOMMENDATIONS

Here are a couple of steps that we @UonCloud cover when we deliver packages to our clients:

1. We wrap them by using PowerShell App Deployment Toolkit because it has a built-in log mechanism and you can manage exit codes. Internally we use the Master Wrapper product to create PowerShell files. Super easy and user-friendly. Check it out https://www.masterpackager.com
2. We add custom brand keys in registries aka tattoos. Doing it this way ensures that we have all the details like installation date, name, version, vendor, etc. You can always create a custom PowerShell script to check if registries exist or not, to be on the safe side.

If you’re still contemplating whether you should or you shouldn’t follow the above recommendations, as it may mean that you’ll have to examine each application you have and this task sounds daunting… I’m afraid the not-so-great news is that you may have to do it anyway since it’s required for conversion to the Win32 app. Why not beat it to the punch and create more value once and for all, by investing extra minutes per app and minimizing your potential future headaches?

To summarize the above: My sincere advice is to perform the audit and package all the apps according to the best practices aka ‘the right way’ because INTUNE is not as agile as ConfigMgr, thus troubleshooting may become your norm.

If you are looking for application packaging experts, I’m happy to jump on a call and chat about migration, packaging, or anything else that UonCloud can do for you.

Stay tuned for future posts.

Written by Martins Kurtiss

#win32 #mem #intune #packaging