17 Recommendations to Package Your App for Enterprise Use

Your application's installer is the very first direct interaction of users with your product. And, a positive first impression is essential for the success of any software.

However, dedicating more time and resources to the installer building phase could result in having less time to work and develop your main product.

When it comes to Enterprise and B2B software products, an application packaging process must be in place to deal with the installation package - as these kinds of products are eventually repackaged or transformed.

To find out more about the IT Pro’s tasks and activities, we highly recommend reading The End-to-end Application Packaging Process - Best Practices and Tips for Success.

At Advanced Installer, we work closely with developers and IT Pros in enterprises and see their struggles and successes. Through our experience, we've learned steps and procedures that work best for them when preparing a reliable installer.

Following up, we will share what we consider to be the software packaging best practices for enterprises:

1. What are some basic rules for software application installers?
2. Enterprise Software Deployment: Best Practices
3. Testing your Software Packaging Installation in an Enterprise Environment
4. Document and note all your actions
5. Conclusion

What are some recommended practices for software application installers?

1. Choosing the right installer: MSI vs. EXE package:

It depends on the market and use the application will have.

If your application will be used in an enterprise (e.g. Network Monitoring app), then you may want to create the package as an MSI installer - since sysadmins usually prefer MSI due to its customizable nature (e.g. removing shortcuts, disabling automatic updates, etc).

However, if your application is targeted towards the end-user, you may want to go with an EXE package type. The difference is mainly that you’ll be able to get creative with your UI for the installation and overcome MSI limitations.

2. Supporting command line switches for silent installation (and configuration)

As a best practice, we recommend documenting any switches that the installer may use during the installation process (e.g. if a particular action is executed based on a specific condition).

By default, all installers created with Advanced Installer support silent installation.

You can find the command lines supported by Advanced Installer here:

• https://www.advancedinstaller.com/user-guide/msiexec.html
• https://www.advancedinstaller.com/user-guide/exe-setup-file.html

3. Create an upgrade package to update to the new version

It is best to create an upgrade package to update a version as it provides more options for changes than patches.

Some of the reasons why an enterprise sysadmin will always use the upgrade package are:

• It’s significantly easier to modify an upgrade package than a Microsoft Patch (MSP).
• Patch installations can fail. When IT Pros perform changes on a base MSI ( a common practice in managed infrastructures), there are high chances that the patch will fail due to internal Windows Installer validations.
• It could be a nightmare to administer - patches need to reference their base applications so using patches in the enterprise infrastructure could turn complicated.
• It takes more time to build a patch than an upgrade package on the vendor’s side.

Here's an article that goes into how to build an upgrade for your application: Creating an upgrade package to deploy application updates.

4. Make your installer 100% offline: do not make Internet access mandatory at installation time

To avoid problems with low internet speed and large download size, installers should contain all the resources inside, requiring no internet connection during the installation process.

Try to provide the offline version of the installer just for your app, without including any prerequisites (if your default version is a web-based installer).

There are situations when the installer also appoints some runtimes that are required by the application (e.g. .Net Runtime or Java runtime, etc). This will add an extra load to the size of the installer. If the number of users that do not have that runtime already installed on their machines is small, you may want to add those runtimes from their online location - to reduce the size of the installer.

In case any runtime is required for installation, the installer will download them at installation time.

Enterprise Software Deployment: Best Practices

Try not to bundle multiple packages/MSIs into a single one. Provide them all separately and specify the order of installation, if required.

In Enterprises, the installers are usually installed one by one. So, if you have other installers bundled, specify them and provide all details that may be needed such as installation order, if any.

All this will be managed by the sysadmin using a configuration management tool.

Provide a command-line switch to disable automatic updates (if you have this support included in your application).

We believe all IT Pros need this option to avoid additional support inquiries, add transparency and disable automatic updates through dedicated switches.

Since updates are handled by the sysadmins, on-demand, and after the update is verified and confirmed in the Enterprise environment - they should consider disabling the auto-updates in an application.

Otherwise, the installer will be repackaged and packaged into a new installer where updates are disabled (e.g. if the update is done through a service, then the new installer will not include that service).

If you have deferred custom actions (the code that modifies the system), also build rollback custom actions (to revert the changes if something else crashes during the installation).

Rollback custom actions are performed during the installation rollback with the purpose to reverse a custom action that made changes to the system, e.g. a deferred custom action.

A rollback custom action always precedes the deferred custom action as it reverses in the action sequence.

Never modify system resources from immediate custom actions - only deferred ones.

Although it is convenient to make everything from an immediate custom action as it gives you access to the installer properties, the only changes that should be made are the ones that influence the installation process, such as setting and verifying properties - therefore only modify deferred custom actions.

If you want to read more about this, check out our article: Don't Do It: Use Immediate CustomAction For Changing The System State .

In case of an error, changes cannot be rolled back if they were made by immediate custom actions.

Avoid triggering restarts during the installation.

The forced reboot during installation should be avoided as much as possible. Instead, you may want to instruct the user to reboot at the end of the installation.

Store your application data in the Roaming AppData folder.

Information stored in the roaming AppData folder is synchronized between devices - which is useful for enterprise use that often involves multiple devices to access one account. , With this synchronization, the application user data will always be the same - avoiding the need of manually copying to multiple devices.

If you want to get more information about the reasoning behind this, check our AppData | LocalAppData | ProgramData Explanations, Differences, Use Cases article.

Testing your Software Packaging Installation in an Enterprise Environment

Check the package for UI blocking custom actions on InstallExecute sequence - make sure you do not include error messages given by your custom actions.

When the installer is deployed from a central location (e.g. a server), there should not be any messages that require manual input.

Use PsExec tools to Test your package installation under the SYSTEM account.

In Enterprises, the installation needs to be successfully deployed under the SYSTEM account. LOCAL SYSTEM is the account performing the installation for most deployment tools e.g. GPO deployment, SCCM.

To ensure that your application is installed successfully, you need to act as the LOCAL SYSTEM account. To test this, use the PsExec.exe from Sysinternals which is the standard.

Test your package in VMs (virtual machines), on multiple systems, to cover all your users.

With Advanced Installer, you can use the Run in VM option to start the installation in a virtual machine, or you can copy-and-paste the installer into the virtual machine to test it in all supported environments.

Document and note all your actions

Document the command line switches/options in a dedicated download page (or PDF) for the IT pros.

An installation manual is a best practice so that your users know how to handle the installation.

Note all GUI user inputs (if any) as command line parameters (i.e. MSI public properties and accepted values), with examples.

Provide documentation for all properties that need to be set. If gathering any user input, expose the properties that need to be set, with examples.

Keep a list of requirements: prerequisites, minimum OS required, database connection (if required).

If the application requires any runtimes (e.g. certain C++ version, .Net Framework version, etc), it is convenient for the runtimes to be specified in the proper documentation.

The same applies to any database need. Documenting this type of information is mandatory in an enterprise deployment.

Write on the MSI log from your custom actions or, even better, to the machine's event log

When troubleshooting failed installations, the MSI log is the first one you should inspect. In the log file, the actions that fail will be highlighted making it easier to debug.

It is useful to have more details of what happened there when troubleshooting falling custom actions.

If you're using PowerShell for custom actions, you can write to the MSI installation log by simply using the "Write-Output" cmdlet into your PowerShell custom action code.

For DTF C# custom action, use the session.log to write in the MSI log: session.Log("Begin CustomAction1");

If using VBScript, use the below code to write the event in the log file:

Function WriteToLog
Const MsgType = &H04000000
Set rec = Installer.CreateRecord(1)
rec.StringData(1) = CStr(Session.Property("APPDIR"))
'rec.StringData(1) = CStr("Any type of message can be wrote here")
Session.Message MsgType, rec
WriteToLog = 0
End Function

Conclusion

Following the basic rules and best practices for your application packaging software processes will ensure the quality of your product and give you fewer headaches regarding the support or possible bugs.

We hope this article gave you a quick overview of what you need to start your software packaging journey for Enterprise use.

Ready to give it a try? Try Packaging Recommendations for Enterprise Use of your Software Product. It will make your job easier, guide you through all the best practice checks and help you build a better installation package.