United Kingdom Endpoint Management User Group

 View Only

What is an Install Wrapper? 

May 20, 2014 08:25 AM

If you automate your application installs then you will probably have used an Install Wrapper.

When installing something in an unattended (i.e. automated) way, often there is a simple, single command line that you can use. For example the following single command line will install 7-Zip with a basic msiexec User Interface (UI) whilst ensuring the install doesn’t trigger a reboot,

msiexec /i "C:\Path\To\7z920-x64.msi" ALLUSERS=1 /norestart /qb-

This command line is generally inserted into you your deployment tool of choice to deliver the software to your Windows endpoint (we use Altiris DS6.9 and Altiris CMS7).  

But what if your unattended installation has a pre-requisite? Or what if after the installation you need to perform a task or install a post-requisite?

This is the point when most software packagers start writing a batch file. To illustrate, below is an example of a batch file which will install iTunes with its pre-requisites:

REM a batch file
msiexec.exe /i "C:\Path\To\AppleApplicationSupport.msi" ALLUSERS=1 /norestart /qb-
msiexec.exe /i "C:\Path\To\AppleMobileDeviceSupport64.msi" ALLUSERS=1 /norestart /qb-
msiexec.exe /i "C:\Path\To\iTunes64.msi" TRANSFORMS="C:\Path\To\iTunes64_ITS.mst" ALLUSERS=1 /norestart /qb-
REM end of batch file

Now imagine this batch file is called 'Install_iTunes.cmd' and that this is the command line that you used in your favourite deployment tool:

"C:\Path\To\Install_iTunes.cmd"

The batch file you have now created is an Install Wrapper.  

An Install Wrapper can be created using any scripting or programming language and the objective generally is to ensure the application can be fully (and robustly) installed in an unattended manner on the target machine. (Please note that I do not use the word 'silent' in this regard; many software packagers use the words silent and unattended interchangeably in reference to application installations. This can be confusing as some vendor silent switch implementations only make the installation fully automated, i.e. unattended, and do not also actually make the install silent/invisible)

Install wrappers are usually required for one of the following reasons (although there are as many reasons as imagined scenarios):

Pre / Post-requisites
Pre / Post scripting, e.g: delete a file / shortcut, create a registry key
Pre-install condition checking, e.g: correct OS, correct computer name (or part of name)
Check the version of an installed pre-requisite, e.g: version of MS Office
Check if a user is logged on
Check if a program is in use by the user, e.g: in the event of an upgrade

Software install wrappers are often written to perform unattended software installs which require more logic or requisites than a simple silent switch.  

If you use a endpoint management product it will often natively provide various UI features to help you 'wrap' your software installs without requiring scripting expertise.  For example with Altiris 7.5 we have conditions based on filters and compliance decided by detection rules. Endpoint management products however, can't always handle the logic you need incorporated into your installation. In such scenarios you have your deployment tool of choice execute a wrapper script to manage the install instead.

The down side to Install Wrappers is that the more complex the application requirements and install phases become, the more skilled the programmer / scripter needs to be. And this can become a problem; we found that when we needed to hire packaging contractors we could only hire those with accomplished scripting skills. Consequently the hiring process became much more difficult.

To mitigate this, I decided to create a simple-to-use VBScript based wrapper which would be driven entirely by an ini file. The aim was to remove the scripting aspect from the packaging team’s duties so that they would only need to edit the ini file (according to a reference I've written) to manage any software installation.  I called the resulting VBScript the 'General Installer', or 'GInstaller' (jee-installer) for short.  I will at some point document and release this to the community so that maybe more packagers can benefit from this as we have.

So to summarise, an Install Wrapper is the program or script that you use to execute your installation including any additional programmed logic, pre or post-requisites, and including any additional scripting tasks such as file or registry operations.

I hope that you found this useful!

 

Darren Collins
Applications Packaging and Deployment for IT Services,
Oxford University, UK.

Statistics
0 Favorited
5 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

May 20, 2014 09:48 AM

I completely agree that a poorly written install wrapper can cause you much troubleshooting grief.  If using Altiris and you feel a wrapper is necessary for some reason, then careful flow of the script is essential.

This is why our wrappers ended up getting more complex as time went on - we ended up with more reliable wrappers, but the skill level to adapt and amend them also rose in line.

I will at some point get around to publishing our GInstaller solution to this which is by no means a panacea, but has served us well as the compromise between shoehorning some logic into Altiris and some into scripts.

When I first worked on GInstaller we were using NS 6 and we needed something that would provide complex logic but without the scripting knowledge.  Here's a couple of blog posts I wrote over two years ago describing how I was going about it (the blog is now neglected).  GInstaller has evolved quite a bit since then and obviously CMS 7.x can now cope with much of the requirements that I wrote GInstaller to handle.

http://blogs.it.ox.ac.uk/darrencollins/2010/12/21/87/

http://blogs.it.ox.ac.uk/darrencollins/2011/01/13/the-general-installer-progress/

 

May 20, 2014 08:58 AM

I would caution that, unless the install wrapper is well written, it can hide exit codes representing failure. ITMS 7 now has a facility to configure pre requisites, and post requisites can also be configured in Managed Software Delivery polices.

I've seen instances where a batch file runs an install then writes a custom reg file to say the software's installed. The install fails but the reg key write is successful so not only does the batch file report back success but whatever the custom reg file is for thinks it's installed as well!
 

Edit: So I used to add a section like this:

:error
IF "%ERRORLEVEL%"=="0" (goto success) else (set err=%ERRORLEVEL%)

IF "%err%"=="3010" (goto reboot) else (goto fail)

:reboot
Exit 3010

:fail
Exit %err%

But I much prefer people to not try and write their own Management Tool when the one Symantec provides can do the job.


 

Related Entries and Links

No Related Resource entered.