Yet another installation wrapper? Well ... maybe, as there are already some installation wrappers around, most of the time they support similar features. However, this is another one that might have different features and that might be useful for some administrators.

What is a "wrapper" and what is it useful for?

A wrapper is usually a program used to execute one or more other installation programs. But why use a wrapper instead of using the original installation program directly?

I have been working for many years in several software packaging and deployment projects in many software deployment environments. Most times I have been missing some, from my point of view, basic features. Even if these tools did have these features, they most times have been implemented in a very rudimentary and unhandy way.

I'm particular talking about two mechanisms:

• to execute more than one setup in one deployment job
• dealing with non-zero return codes

Typically I wanted to first run a un-installation job for an already installed application before running the installation of the new program.

Another typical situation was an application that required several precondition applications before being able to be installed, or that required other additional applications to run properly.

So running more than setup in a single deployment job was one thing that I often missed.

There is another clumsiness I experienced with some deployment tools. Most of them interpret a return code that is not zero as installation failure. That might or might not be right.

For instance MSI installations - the executable is msiexec.exe. There are several non-zero return codes that are quite common, but they not necessarily indicate a failed installation:

• Returncode 1605

ERROR_UNKNOWN_PRODUCT
This action is only valid for products that are currently installed

This return code is thrown when you try to uninstall an application that was installed by MSI technology, but can't be found as an installed application. That happens when the MSI was already removed or was never installed at all.

But I mean ... so what.

Often you try to get rid of an application because you want install a newer version of that application or you want to remove the application for some other reasons. Either way - off is off, however. Important is that this application in question is not on the box.

So, is 1605 actually a return code that indicates a failure? A "failure" we want to accept that it prevents further installation of additional setups?

This question of course needs to be answered individually by the administrator who was setting up the software deployment job, depending on the actual situation.

• Return code 3010

ERROR_SUCCESS_REBOOT_REQUIRED
A restart is required to complete the install. This message is indicative of a success. This does not include installs where the ForceReboot action is run. This error code is not available on Windows Installer version 1.0.

This return code is thrown when the MSI installation requires a reboot, but the public property REBOOT=ReallySuppress was used to suppress any potential MSI reboot request.

This property usually is used in conjunction with the property REBOOTPROMPT=S .

"REBOOTPROMPT=S":

"If the REBOOTPROMPT property is set to Suppress (or just S) any reboot performed by the Windows Installer happens automatically without interaction from the user. Setting this property does not initiate a reboot if one is not needed, it only suppresses the display of any prompts for reboots to the user."

Best practice is to always suppress any potential reboot requirements of an installation. The software deployment tool can't differentiate whether a reboot is initiated deliberately by the installation routine at the end of a successful installation or if a BOD occurred.

So you normally suppress any potentially required reboots by the MSI and let the deployment tool reboot the machine. In this case you most time have the additional option to let the user postpone reboots to a later and maybe more convenient time.

For MSI setups you suppress reboots by using the properties mentioned above. But when the MSI setup actually requires a reboot because some files couldn't be copied or overwritten (e.g. because of open files) msiexec.exe throws a return code 3010.

So again, is 3010 actually a return code that indicates a failure?

Usually no, it only indicates that a reboot is required before the newly installed application runs properly.

Wouldn't it be nice to suppress the return code 3010 (or change it to something else like "0") so that no error is reported to the deployment solution and you can continue installing other applications?

The MSI technology is very tolerant in installing a bunch of applications with only a last reboot, if this is necessary at all.

So this is when the wrapper comes into the game.

The issues above - and some more - are covered by a "wrapper.exe" that I developed with Wise Script Editor.

Basic Description

The wrapper execution is customized by an .INI file that provides information how to handle one, or a bunch of installations.

Some of the benefits:

• You can run as many installations as you like (looping installations)
• You can set specific installation parameters for each installation
• You can define how to handle return codes per application (do ignore or do not ignore as a general option)
• You can define sections (as many as you like) for each return code that might occur.

  Within the section you can define specifically how to handle a specific return code (do ignore or do not ignore)

• Optional do a repair of an installation

  Normally if an MSI Application is already installed on a PC and you run "msiexec.exe /i setup.msi" a second time - nothing happens. No repair, no remove, just skipping the installation. What you can do with the wrapper is setting a parameter so that an application gets repaired when the wrapper is run a second time.

• You can define that the wrapper.exe reboots the PC after a specific return code (incl. a time delay for the reboot)

Command line options

Only very few:

Wrapper.exe wrapper.ini
Wrapper.exe C:\temp\wrapper.ini

Or

Wrapper.exe /s Wrapper.ini
Wrapper.exe /s C:\temp\wrapper.ini

With /s the wrapper runs completely silent.

This is a typical application-section for an .EXE installation

[App1]

AppName=.NET 2.0

Executable=1.0-DotNet\dotnetfx.exe

MSIexecute=

CommandLine=/q /c:"install.exe /vREBOOT=ReallySuppress/qb-"

IgnoreExitCode=0

RepairIfExist=0

RepairOptions=

ProductCode=

EstimatedRunTime=3

AppName=.NET 2.0
This string is only used to be displayed while the wrapper is running to give the user some basic information what's going on (if you like to display any screens at all. You can run the wrapper completely silent).

Executable=1.0-DotNet\dotnetfx.exe
If you need to run more than one application you should create a separate sub-folder for each application for the sake of clearness. The wrapper and the wrapper.ini are located in the root folder.

MSIexecute=
This option is only used for MSI installations. See the next example.

CommandLine=/q /c:"install.exe /vREBOOT=ReallySuppress/qb-"
Should be self explaining.

IgnoreExitCode=0
"0" means -do not ignore the return code in general. Check if you can find a section for the specific return code that was thrown and have a closer look there how to handle this particular return code.

RepairIfExists=1
For MSI setups only. It's used in conjunction with the next two options: RepairOptions and ProductCode. If an MSI setup is executed a second time by executing the wrapper a second time, you can define, that the default MSI installation parameter "/i" is changed to a "/f" - meaning repair! The wrapper uses the "ProductCode" value to check whether it can find that application as being an installed application, and if so, it repairs the application with the defined "RepairOptions".

EstimatedRunTime=3
This value is only used for display purposes for the installation dialog of the wrapper. The wrapper does not stop or cancel any running applications just because the time has elapsed!

RepairOptions=
Typical values: vomus #(see next example)

ProductCode=
(see next example)

BTW ... I always tend to run the original Microsoft executables of any hot fixes, patches or middle-ware components, even if you most times can extract some .MSI or .MSP files out of the KB123456.exe. I'm never 100% sure what else MS is doing with the .exe. For example they might have implemented mechanism to swap protected files! And that can't be accomplished with MSI only.

This is a typical application-section for an .MSI installation:

[App6]

AppName=Autocad LT 2008

Executable=msiexec.exe

MSIexecute=/i 6.0-ACAD\acadlt.msi

CommandLine=TRANSFORMS=Autodesk_Autocad-LT_2008_FR_1.0.mst REBOOT=ReallySuppress /qb-

IgnoreExitCode=0

RepairIfExist=1

RepairOptions=vomus

ProductCode={5783F2D7-6009-0407-0002-0060B0CE6BBA}

EstimatedRunTime=5

Executable=msiexec.exe
In case of an MSI setup you use the msiexec.exe as the executable.

MSIexecute=/i 6.0-ACAD\acadlt.msi
This value is used for the basic MSI installation command. If you do an install, it's "/i setupname.msi" If you do a remove, it's "/x {MSI-ProductCode}"

CommandLine=TRANSFORMS=Autodesk_Autocad-LT_2008_FR_1.0.mst REBOOT=ReallySuppress /qb-
In case of an MSI setup you can here provide additional MSI command lines parameter.

These are only some basic explanations, for more details have a look at the documentation provided with the wrapper.exe.

Within the ZIP file you'll find a more detailed documentation.

So have fun. If you find any problems let me know. If you have some more ideas what might be useful let me know. Any feedback is appreciated.

Best regards,
Hans