Best practices for deployment of Windows desktop applications in the Enterprise

The packaging and deployment of an application is often a neglected step from its development life cycle. Learn what are the key features required in a professional installation package.

When building and testing an installer most developers think about simply running the setup manually with full UI, neglecting the enterprise deployment scenarios. This is what we'll focus on in this post, i.e. how to package your desktop application (Java for example) for enterprise deployment.

Most of these advices can be applied and for applications written in other programming languages, as long as they target Windows OS.

The standard deployment technology for Windows

Since the launch of Office 2000 Microsoft has introduced Windows Installer. This is their recommended technology to be used for the installation, maintenance, and removal of software on Windows OS. There are other third party solutions that don't rely on the Windows Installer technologies, but we'll not get into comparing them, that is for another talk.

Building a basic MSI package with Advanced Installer is very easy. An MSI built with our default settings is a big step towards preparing your package for enterprise deployment, helping you to get rid of all the support tickets where you explain and assist the admins to deploy your application in their companies.

An MSI package will allow admins to:

• install it silently
• configure it using Windows Installer properties, e.g. change the default install path
• edit/customize its contents using specialized MSI editor tools
• easily leverage the OS power for system restore points and automatic repairs for broken installations
• gather verbose logging for debugging purposes

Enterprise deployment friendly design

Deployment through SCCM, or similar systems, is largely adopted by large companies. For a package to be capable of deployment in these environments you must ensure the following design rules are applied:

• has a command line to install silently (built-in MSI support)
• is configured to install in the per-machine context
• the custom actions from InstallExecute sequence must not display UI
• if it has custom actions which require user input, make sure they can get that input from the MSI command line too, by using public properties or transforms
• if your product requires activation, it is recommend to have the option to activate it during the installation (eg. using a transform file, or a serial number passed through the command line). Or, at least allow the end-users to activate it manually without requiring administrator privileges, as usually these are limited-right user accounts.

Prerequisites distribution

To run your Java application on the end-user machines the targeted JRE version must be there too. The easiest and safest way to make sure the JRE required is available is by bundling it into your installer.

The only downside of this option is the increased size of your package, which can be noticeable if you have a small application.

If you develop a .NET application you will need to instruct your clients to have the machines with the required .NET framework installed. The admins will know how to deploy it. Also, enable the .NET Framework predefined launch condition, so the installation will fail if the required version is not found on the target machines and the installation log will mention why.

Application user data

Installation

When installing per-machine packages through SCCM or AD/GPO the installation runs under the system profile. This means that all the user data installed by this MSI gets placed under the profile of the currently logged in account, i.e. the SYSTEM.

By user data we mean registry entries under HKCU or files stored in the current user profile folder.

The standard method for installing this data for the end-user is to exploit the self-healing built in support from Windows Installer. The entry points for triggering an automatic repair are advertised shortcuts and file extensions.

What this does is to empower the system to automatically install the user data for the end-user the moment the application is launched for the first time, through an advertised shortcut or by opening a file associated with it.

Make sure that your user data is under the same feature as the entry points, otherwise Windows Installer will not detect the resources as missing and will not trigger the self-healing mechanism.

Another method which can be used if the application does not have shortcuts (or shortcuts cannot be advertised) is the use of Active Setup.

In short, the Active Setup mechanism is executed only once per user early during logon. This compares if the Active Setup key placed in HKLM is also present in HKCU. If the key is present, that means that the Active Setup was executed, if not, then the specified application is executed for the current user.

As a best practice, if files are needed in the user profile during self-healing of Active Setup, these must be placed on a per-machine location (for example in a sub-folder from the application directory in Program Files) and copied via a Custom Action that is placed to run only at Maintenance.

Storage

For storing the application user data you have two options:

• local profile
• roaming profile

The local profile is always stored only on the PC where it was created. If you are on a Domain / Active Directory setup, as most enterprise users are, the Roaming profile is copied to a central server when the user logs out, and from the server when the user logs in. So it is accessible from any PC where the user can log in with his Domain credentials.

The Application Data folder from Advanced Installer is the roaming profile folder, which we recommend to be used for the obvious reasons.