Today I wanted to bring your attention to some of the challenges we have encountered over the years with application packaging via Intune.
UonCloud has been managing and deploying applications via Intune for the past couple of years and gained extensive experience doing so, therefore we know what is actually working and what’s not running as smoothly as one would like.
A bit of background: @UonCloud has been offering Intune packaging service and application migrations service from Configuration Manager (SCCM) into the Intune environment since 2013.
Not only have we been delivering this service to many of our clients, but we have also maintained applications within their Intune environment. This has given us a broader perspective on how Intune works for a variety of tasks.
Generally, it may seem, that the transition process from SCCM to Intune SHOULD be easy. And it IS…
…BUT it’s heavily dependent on what you currently have in your environment and how your applications were packaged.
What I mean by that is, that IF all apps were packaged following the best practices, then chances are that everything will indeed run smooth and you will not run into any hiccups while transitioning… BUT if that was not the case, here is what I suggest you do with all your current apps:
Wrap your packages with PowerShell App Deployment Toolkit!
WHY?
It adds extra logging that helps you to troubleshoot application deployment issues.
Unfortunately, Intune does not provide the best tools for figuring out why the particular application is failing to install but trust me when I say… there can be MANY reasons. Therefore adding that extra logging would save you a lot of time in finding the root of the problem.
As promised, I want to share some of our biggest challenges/frustrations that we have encountered during application management over Intune:
- UI Repair in Company Portal.
Unfortunately, there is no visual overview to see what happens when you click the ‘Repair’ button in the Company Portal. Once you install the application for the first time, you have a visual sequence of actions: -> Download files -> Installing app -> Message Success or Fail.
If the application failed to install and you click the ‘Repair’ button, all you see is NOTHING.
There is a tinny line-spinner and download notification, but it’s not offering the actual status, on top of it, it ends after some time without notification. All you’re left with is either follow logs or refresh Company Portal every 5 minutes to see if the status of the application will change. This is frustrating.
- Installation Cache is Wiped.
This presents a significant problem when you have an advertised shortcut, plus the application requires source files to repair user settings, that already exist in the package.
Once you run a shortcut that triggers a repair, it searches for source files, but these files are nowhere to be found. That’s because after successful or failed installation the cache of installation source files is wiped. All you can do is try to figure out a custom solution to fix this annoyance.
- Application Upload Failed.
This is an issue with larger applications. You receive a successful import message, BUT it hasn’t finished. Once you open that application within Intune portal you see this message:
“Your app is not ready yet. If app content is uploading, wait for it to finish. If app content is not uploading, try creating the app again.”
Unfortunately, there is nothing you can do to resolve this issue. You cannot access Properties to be able to upload the file again, so all you’re left with is trying to re-import the application again. One thing I noticed is that sometimes this can be triggered by a slow network connection.
- *.intunewil File Corrupt.
This happens from time to time, with both small and large application packages equally. Once you build the *.intunewin file and try to import the app, it fails with the same message as in the example above.
All you can do is try to re-import the application again but if it still is failing, it means you need to build the *.intunewin file again and try to re-import the application.
This is what we have been doing to check if the file is corrupt or not: uncompressing the *.intunewin file with the additional tool and trying to extract files from it, if it fails, that means your *.intunewin file was corrupt.
- Win32 App Dependencies
This is not necessarily an issue, yet I want to bring this to your attention. You can only map Win32 apps as dependencies to the Win32 app. You will not be able to select LOB or any other types as a dependency.
I am hoping this gives you an idea of what challenges you can expect while you migrate to Intune or start deploying apps via Intune.
I hope you found this helpful and feel free to share your discoveries in the comments.
UonCloud is always happy to help with any questions/assistance you may require.