The AppLife Update Blog

  • Execute Windows Installer (MSI) Databases during Application Updates

    Has your product prerequisites ever changed between versions and therefore required you to deploy a new Windows Installer package before your new product version can function? Have you ever needed to deploy a companion application along with your previously installed and AppLife Update maintained application? With AppLife Update, these challenges can be overcome by executing a Windows Installer package as part of your application update.

    Packaging and Executing an MSI in an AppLife Update

    It’s very easy to include a Windows Installer package with your application update and then execute that Msi on all of your remote systems. To accomplish this, all that needs to be done is to include the Msi file with your update by using an Add & Replace files action, and then run the Msi using the Execute Msi action.

    clip_image001

    The Update Package Directory is the temporary directory that the update engine creates and removes for the currently executing update and is easily accessed by other actions. If you want your Msi file to remain on the remote system after the update completes you would choose a different folder, such as a subdirectory of your application directory.

    After this update action executes, the Windows Installer package will be present on the remote system. To execute the Msi we’ll add an Execute Msi action. The Execute Msi action lets your define a <path> variable and then use that variable within an msiexec.exe command line. When defining the path variable, you can choose any of the available local paths, including the Update Package Directory path that we placed the Msi file in with the previous update action. To complete the path to the Msi file, any subdirectories as well as the Msi file name can be added to the subdirectory property. With the <path> variable defined, the msiexec command line can be constructed. To install the Msi, the /i command line option can be used. A command line of /i “<path>” is equivalent to the default Msi file behavior.

    clip_image002

    When this action executes, the Msi is executed on the deployed client.

    Conditionally Update Based on Local Information

    In the case of prerequisites, it might be necessary to first verify that the prerequisites are not already present before executing the installer package. There are a number of methods that can be employed for this purpose. With the Windows Installer product code, we can look up information about the product. For example, if I wanted to first verify that AppLife Update was installed before taking action on the client, I could look up the AppLife Update product code in the uninstall registry key. Using a Read Registry Key action, we can look up the uninstall string and even use it to uninstall. If the string is not present, we can use the information to infer that the product is not installed.

    HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Windows\CurrentVersion\Uninstall\{0c2b1285-5119-44f5-9b68-edc749f18967}

    Using a Read Registry Value action, we can set a Shared Property to the value of the uninstall string, and default the value if the string cannot be read.

    clip_image004

    If we wanted to make the execution of the Msi action conditional on AppLife Update being installed (or not installed) we can add a conditional statement to the update action.

    clip_image006

    Uninstalling First

    Windows Installers can be configured to first uninstall the application, but this is not usually the default behavior when using Windows Installer creation tools. If you would like your update to first uninstall, we can use the uninstall string we just read from the registry using a Command Line Action. Alternatively, we can also use the Msi Action directly.

    clip_image008

    Silent Updating when Using the Elevated Permissions Service

    When your application is using the AppLife Update Windows Service for permissions elevation, it’s important to recognize that the Windows Installer will be executing under the Local System account user, and won’t be able to interact directly with the logged on user. For some installers, this could impact the way they operate. Running under the service, the installer must be able to run silently (using /q). In the event that the installer must interact with a user, the elevation service cannot be used for that update. When publishing the update, select the option to override the controller elevation settings and use the UAC elevation option instead. This will require an administrator to apply the update, but will allow the Msi to interact with them as they do so.

    Disabling the Elevation Service

    clip_image009

    Troubleshooting Updates that Deploy an Msi

    The AppLife Update engine logs activity to an event log as the update executes. However, when an Execute Msi action is executed, the log will only include information indicating the exact command line used and the msiexec return value. In order to investigate what actions the Msi performs, it is necessary to use the msiexec command line option to log the Msi operation. This option can take an explicit path. To write a log file to the install directory, you can use a Set Shared Property action to define a Share Property with the application directory path.

    clip_image011

    And use it to define where to write the log file to.

    clip_image013

    Conclusion

    In the course of maintaining an application, it is sometimes necessary to install new prerequisites or companion installers. Using AppLife Update, automating these actions and ensuring an effortless transition for your end-users is very easy. The update actions available within AppLife Update lets you package and deploy new Windows Installer packages, conditionally execute update actions, uninstall existing packages if necessary, and troubleshoot the update process before widespread distribution.

    Posted at 17 July, 2012 | By :Brian Haas | Categories : AppLife Update | Software Updating | Windows Installer |