Why Your Manually Installed Applications Count Should Be Zero
Nowadays, with Windows 7 running out of extended support, for those organizations who have not migrated to Windows 10 yet there is a race against time.
They are trying to do whatever they can to speed up the whole process and get all their applications up and running on Windows 10.
All this, to minimize their costs and avoid a big bill from Microsoft for the Windows 7 Extended Security Updates.
Usually, all this rush leads to bad decisions.
One of the most common ones, in terms of Application Packaging, is to manually install the application rather than to create a package for it and push that package to production devices via the deployment tool.
One of the application packaging’s main purposes is to reduce the pressure over the administrative and support budgets.
But what happens if the administrative and support cost is lower than the cost of packaging the application itself? Will it ever be the case?
Manual Installation Scenario
Let’s say you have an application that needs to be used by a single user on a single device. Does it worth packaging it?
At first glance, it does not, because it seems that the effort put into packaging it, is much higher than the effort put into manually installing it. But, this is something arguable.
I have come across multiple situations in organizations where an application used to be requested for one or a few users initially, only to end up with it installed on a bunch of devices later on.
Do not forget also, that every Windows product has a lifecycle and starting with Windows 10, Microsoft introduced a new model to build, deploy, and service Windows, known as Windows as a Service (WaaS). And with this new WaaS model, you will not be able to cherry pick only the updates you want to install as you did on Windows 7. In case any Windows updates breaks your application, you have no other choice but to manually upgrade the application to a newer version (if any available) or manually fix the existing version of the application on all the devices where it has been manually installed.
Here many organizations fall into the trap. If the application will be needed by ten users instead of one which was initially foreseen - then it could get far more costly to manually install it rather than packaging it.
Also, keep in mind that there are applications that require some sorts of pre or post configurations, and sometimes those configurations cannot be added within the package for a certain reason.
A good example here are those applications that require to manually add and activate the license. Whilst it looks like not the desirable alternative, it is still a good choice to package the application itself, without the license, and the licensing and activation to be manually done later by the end-user.
You must also take into consideration that there are still many vendors who don’t care too much about the uninstall of their product. So, there will be some clutter left behind, if you decide later on to remove an application which was manually installed in the first instance. Or even worse, the application might fail to uninstall. And this goes against the organizations’ aim of having a standardized environment.
Which is easier to track - a packaged app or a manually installed one?
From an application management perspective, it is much easier to keep track of your applications if they are packaged and then deployed via your deployment tool.
Most known deployment tools, like Microsoft System Center Configuration Manager (SCCM), come with their functionality for monitoring and reporting, which is very handy.
Although it is not recommended to install applications manually, if, from whatever reason, you still decide to do this, at the bare minimum, you must:
- Keep track of all your manually installed applications;
- Document all necessary details related to the applications;
- Do some diligence checks and make sure that the application installs without any issues and works as expected within your organization environment before you manually install it onto a production device.