Hello everyone, I hope you are all safe and well.

I’ve been thinking about writing this for a while and I hope it helps some of you new to app packaging.

“How do I build apps?”

It never hurts to brush up if you’re a seasoned app-packager. App packaging isn’t going away any time soon, everyone needs apps. The Microsoft app store has gotten better but I don’t feel it’s quite there yet in terms of broadly available applications. Sometimes, companies can have line-of-business applications that they build in-house and as system administrators, you may be responsible for packaging and distributing those applications. How do you tackle it? where do you begin?

First, terminology; this is important because often terms are mixed up, and I’ll be honest it can be confusing for a newcomer. OK, here goes (I hope this makes sense). ‘Packaging’ something simply describes the process of taking a piece of software and making it “ready for deployment” so that, you can use whatever your chosen deployment method is, to distribute that application to devices in your estate with minimal administrative effort. Normally, the distribution methods in environments these days are (System Center) Configuration Manager (Commonly known as SCCM) or Microsoft Intune. Both very good products, although I favour the former.  The two combined now collectively known as Endpoint Manager & you’ll notice some branding changes trickle through but I think it’s safe to say those of us using these technologies know a little of their history.
Let’s go one at a time here, starting with Configuration Manager, within the console, on the Software node, under Application Management you can see “packages” and “applications” (this is where it starts to get confusing. Software, made deployment-ready, in Configuration Manager, can take the format of a “package” or an “application” and I find that this is where the terms get muddled up).

“Package me an application, please”
“Can you package this up for me?”
“Can you make the software into a package?”
“Can you deploy this application?”
“Can you deploy this package?”

… you can see how this starts to get confusing, I hope.

Lets make sense of it.

In all scenarios, the requester is simply asking you to take their software and make it ready for distribution across the systems so nobody has to go and install it manually on each computer.  In Configuration Manager, Packages, are simply deployment-ready items that take your source files, you create a “program” to install it and this can be deployed to devices.  These are still quite popular to use for operating system deployments because they are simple in nature, and there’s little that can go wrong, once you’ve tested them fully and the command line is correct and added them to a task sequence correctly.  Applications, are a little more complicated than packages but come with much more functionality such as better reporting, logging and more granularity.  Both can be used in all scenarios (including operating system deployment), although some might argue that the two have different areas they fit best in.  Personally, I always use applications, yes they are a bit more work, but they’re worth it.
In Microsoft Intune, the software is referred to as apps. 

As Intune is an MDM (Mobile Device Management) solution, these “apps” can take the format of Windows apps, IOS apps (Apple OS), Android apps… including many others.  There are sometimes different formats of apps that reside with a category.  Windows apps, for example, generally take the form of (but are not limited to) “Win32” apps, or “Microsoft Store” apps. . It’s important that as you start to explore these consoles that you take note of the terms used and continue to speak and write the same terms in your day-to-day activities to better distinguish to what you are referring to.  Remember so far we’ve used the terms “Packaging”, “Package”, “Application”, “Apps”, “Win32”, “Microsoft Store apps”

Here are some links that may help you.
Deploy applications – Configuration Manager | Microsoft Docs
Packages and programs – Configuration Manager | Microsoft Docs
Win32 app management in Microsoft Intune | Microsoft Docs
Manage VPP apps from Microsoft Store for Business – Microsoft Intune | Microsoft Docs

Discovery

OK next up, discovery. in order for your application to install without any user interaction, you’re going to need to discover firstly whether that’s supported, and secondly how to do it.  There are many resources available on the internet to help you with this, but also some basic tricks that I suggest you learn. Normally, I start to interrogate the installer files provided by the requester.  This might be a setup.exe file, or if you’re lucky, a .msi file.  In some cases, you might be required to write scripts to facilitate the install and there maybe configuration or settings files that you need to apply.  I’ve come across all manner of software with all manner of intricate ways to install and configure with no user-interaction (referred to as silently).  Let’s take a practical example of both.  Starting with a .exe (hardest).

.EXE Discovery

Place your installer files into a folder and open a command prompt window in that folder.  To interrogate any installer you need to ask it, “what switches are available to use?”.  You can usually achieve this by trying to run the software with a query switch.  Examples would be “/?” (most common) or “/help”,  which should result in the software throwing out a window to let you know what you can do with it, if you’re lucky enough to get one, examine it for silent install command lines and then begin to test them.  Often they take the format of switches you can throw such as “/quiet” (or “/q”), “/silent” (or “/s”) or some other connotation

In this example a window is thrown out that’s quite large so I cut down what I need to show you.


… “/verysilent” sounds great! We’ll use that.  This method of querying the application will work 9.5 times out of ten.  You’ll then have to go and test that it installs the application silently and that you receive no end-user prompts whatsoever.  As always, test on throw-away VMs.  Not production.  Once you have the command that installs the software silently, you have your “install string”, which is one part of the discovery.  Next comes the uninstall string.  Normally you can retrieve these from the registry in one of these two locations depending on the architecture of the application.
32bit Registry Hive
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

64 Registry Hive.  Note: On a 64-bit computer you will need to check both the key above and the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
Warning! – I have seen some programs that don’t use these two standard registry locations so if you can’t find what you’re looking for, then you’re going to have to search for what you need.
Once you’ve explored the registry and found the key for your particular software, there’s usually a subkey you can discover to help you find the silent uninstall string.

I wrote some code to go get some useful information for you from the registry.  It may help save some time

Clear-Host
$Hive = Get-ChildItem -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
$Hive2 = Get-ChildItem -Path HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
Write-Host -ForegroundColor Green "x64 Registry Hive - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall "
$Hive | Get-ItemProperty | Select-Object -Property PSChildName, DisplayName, DisplayVersion, UninstallString | Sort-Object DisplayName | Format-Table -AutoSize -Wrap
Write-Host -ForegroundColor Cyan "x86 Registry Hive - HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall"
$Hive2 | Get-ItemProperty | Select-Object -Property PSChildName, DisplayName, DisplayVersion, UninstallString | Sort-Object DisplayName | Format-Table -AutoSize -Wrap

A colleague of mine, told me about an application that’s quite useful in this space, Geek Uninstaller, which is free for personal use.  You may wish to investigate that if you prefer not to use PowerShell or dig around in the registry.  I don’t personally use this, but some of my team do and they like it.

This now arms you with being able to silently install and uninstall the software.  Once you can do that we can create our deployment-ready item.

Again, please test.  Does it work as expected?  If so, now you have your “uninstall string”.   You won’t always get lucky and sometimes you might need to do some research and further testing to get the end results you need.  For the majority of cases though, this will work.

MSI Discovery

For MSIs the process is pretty straight forward.  Every MSI normally takes the same install and uninstall string, like so;

Install:  msiexec.exe /i yoursoftware.msi /qn
Uninstall:  msiexec /x yoursoftware.msi /qn
(/i = install, /x = uninstall, /q = quite/silent, the ‘n’ signifies no user interface, so completely silent)

All MSI’s accept a query switch if “/?” and from the output, you can see that you can get quite granular with the options.
In a live environment, you may also see a long GUID for the uninstall string.
Like this:  msiexec /x {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} /qn

This represents the ‘Product Code’ for the software and should be unique although I have seen instances where it’s not, so tread carefully.

More information here: Command-Line Options – Win32 apps | Microsoft Docs

.. sometimes, even MSI’s can take extra switches for items such as registration or activation code, or you may be able to customise the install, for example with a company name.  These extra switches can normally be found in the documentation for the software, via internet research or if you wish, you can even examine the database for the MSI and see if there are any switches you can find.  Out of scope for this article, but there is a program inside Microsoft’s Software Development Kit (SDK) called Orca, that you may wish to take a look at if you get stuck. Using Orca, you can open the MSI database and search for fields that can be taken as parameters.  I’ve used this right back from the early days, but it can be confusing.  I’m sure there are others available too. Vendor documentation normally has them.
Worth noting, never underestimate looking in the vendor’s documentation, you will normally get what you need.  I say normally, but those well versed at app packaging will start to recognise companies that do better at this than others.

So let’s think about the components we now have.  We have the source files (see below about Intune source files), we have identified a silent install string and a silent uninstall string.  We have tested that these work as expected on a throw-away virtual machine and we’re ready to place those items into our deployment tool to be pushed out across our estate.  But which one?  Well, that totally depends on you really.  What tools do you have at your disposal?  What are you licensed for? (Intune requires licenses) Is this going to be for on-premises, or will your users be ‘in the wild’?  Once you know you will be able to decipher which will be the best tool to use to meet those requirements.

Intune Source Files for Win32 apps cannot be the raw files you have when creating applications inside the Configuration Manager console.  You will need to collect them up and use the Win32 Content Prep Tool, that will take your raw source files and concern them into a single .intunewin file which you then upload to Intune.  This will compress and encrypt the source files for a quicker transfer.  You may have noticed I have linked some documents in this paragraph, those will help you.

Next up, Detection Clauses, these are quite important to your packaging journey, you need to identify a way to detect that the software is installed.  Most of the time, this will be the existence of a registry key.  Using the example from above, we could set the following key to be our detection clause:

So we’ll tell the system “If this key exists, then the application is installed”.  We will need to check whether or not it is removed during the uninstall process first, just to be sure its not left behind as an orphan and therefore would lead to a false detection if removed.  In some cases you cant leverage the root-level registry key, you may need to go deeper such as detecting whether or not the version number is equal to or greater than something.  For example in the case of an app that might self-update or update often the registry key will always be present but the version number might increment, you’ll need to tread carefully around these apps to ensure that you don’t get false detections.  Again, take each app as it comes and start to build up your exposure and experience with it.  You’ll start to notice common registry key places (like the ones mentioned earlier) and soon, it will become second nature.

Deployment

Finally, Deployment, this bit isn’t really part of the packaging process but I thought it would be important to mention to just tread carefully with your deployments, don’t assume that your clean Virtual Machine is a true representation of real-world machines.  Always try to test a few machines in a ‘pilot before production’ mentality.  Don’t, for example, rush an app them blast it out to 1000+ production machines and then wonder why your service desk is rammed with tickets the next day.
I think, above all, don’t be scared to ask for help if you’re struggling.

I truly hope this helps anyone starting out on their application packaging journey.
Thanks for reading,
Jonathan.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *