Easy Setup

How a little research can save you a lot of time!

I guess that many of us have experienced the situation when your manager asks you be responsible for the Installation Package development effort just a couple of days before the products release…  I hope that this trend begins to disappear as companies realize that they should treat the Installation Package with as much seriousness as any other feature in the release. In this article, I would like to share with you some of my experiences and the steps I take as the developer responsible for the installation effort.

Each company has a R&D and QA structure suited to its needs. There are companies who have dedicated QA engineers for each feature set and others who have one QA department that handles the entire testing effort.

Unlike many other features of a new release, the Installation Package is one of the features (if not the only) which has full interaction with almost each and every person within the organization: Project Managers, development and QA teams and even the CEO. So, instead of worrying why you’re getting so many installation related demands and change requests, it is highly recommended to identify the various stake-holders relevant to the release and to let them have full participation in the information gathering process. Any action such as a meeting or mail which asks for input regarding the package, whether regarding required components or approving a check list is desirable as long as you end up with a detailed and clear document which describes the nature of the feature and its completion schedule.
 
In addition it is highly recommended to have the support of departmental managers who can sort through various installation package requests which may interfere with the completion schedule, even though these requests are important to the person asking them but are not vital to the current release.

Information Gathering:

1. Should the installation support more than one Operation Systems?
   i.e. Win9X, WinNT, Win2K, WinXP, Vista, Windows ServerX.
    
2. Should the installation support both 32 and 64 bit OS?
   Although it’s highly recommended not to have such installation, many companies are tempted because of management intervention to have one installation which supports both OS’s.
    
3. Should the installation support more than one language?
   If so, then you must take into account the need to support varied language properties when writing files or adding to the registry.
    
4. Should the application support multiple language interfaces?
   In other words, what will be the impact if the user has installed the application using language A and his computer default language is B? Should the application automatically support such cases or should it require user intervention? An additional factor to consider is the interaction with and dependence upon external translation teams who are not necessarily obligated to your completion date.
    
5. Should the installation include additional dialogs other than the default one?
   Many Msi editors are supplying dialog editor capabilities and even ones with Multilanguage support. However, many considerations such as: the information the dialog is designed to gather, where to place the dialog in the installation sequence and various design questions should being raised when adding new dialog into the installation procedure.
    
6. Should the installation support DB management?
   Whilst it is true that few Msi editors are trying to add DB creation and/or maintenance capabilities, questions such as how to backup the DB status prior to the DB execution scripts, when during the sequence should the scripts run, troubleshooting during scripts failure etc., should have in-depth consideration.
    
7. Should your installation include any third party installations?
   Many installations include various third party installation scripts as prerequisites or because they are developed from various installation packages from numerous sources. As mentioned in a previous article regarding Msi packages, it is highly recommended not using the Msi nested installation CA. Note that Msi 4.5 which supports XP as well, is released with a new chaining mechanism to support such cases. For executable packages, it is recommended that you consider using a “smart” self-extractor which will execute the packages one by one. The impact of Vista OS support should also be given in-depth consideration regarding silent installations and the execution of the application at the end of the procedure. (The only way to execute a silent installation in Vista is by using elevated privileges; hence the applications which will be executed at the end of the process will be marked as having elevated privileges as well even though they were executed from the non-elevated Msi sequence).
    
8. Many installations include various third party installations as prerequisites or because they are developed from various installation packages from various sources. As mentioned in a previous article, do not attempt to use any the Msi nested installation. It is recommended that you consider using a smart self-extractor which will execute the packages one by one. The impact of Vista OS support should have in-depth consideration regarding silent installations and the execution of the application at the end of the installation. (Installation programs run under these conditions will be given an “elevated” flag by the Vista OS and will demand Elevated Administrator privileges in order to successfully complete the installation process).
    
9. Which sequences should the installation support?
   Many companies do not support the various Msi maintenance sequences (repair, change, upgrade, patch) by definition. But, if you’re planning to have this ability at the future, it is highly recommended to include the infrastructure for them even though you’re not using it currently!

It is vital to take into consideration that for any item from the list above that is true of your installation package, in addition to the time taken in the development stages, adequate testing procedures must be set up and sufficient time allowed for full testing before the final release.
 
Do not assume that once the installation is successful in one scenario (platform, OS, Language) it will be successful in others as well. It is highly recommended in such cases that instead of managing one installation per scenario (platform, OS, Language) or having one installation package that will manage all the processes, to use the Msi transformation mechanism.

Criteria for evaluating and choosing the correct development tool for your project.
 
A question often asked by developers is which Msi program, supplier or system is best suited to the company’s needs? As always, the answer is not a simple one and involves many factors, such as cost, ROI, customer support etc. The final decision can often be a critical one that will impact on the company in the future, and so, should not be taken lightly. In this post, I would like to share with you some of the conclusions I have arrived at after having to make such a decision a number of times.

Generally speaking, the idea is to gather answers to specific questions regarding the programs’ features (you can add or remove questions as you choose to suit your particular situation) and place them into a matrix for comparison. You should then rank each program feature on a scale of one (lowest) to ten (highest). It is a given that you are the one who decides which features are more important than others and score them accordingly. At the end of the process, the highest scoring program should be the one you select. Using this system enables you to make a decision that is uninfluenced by you or your colleagues’ personal ideas and opinions.

Information Gathering:

1. How many programs are there available in the market? By executing a simple internet search you can find many solutions and products upon which to base your research.
    
2. What the cost of the program and/or license per computer? Many companies have various licensing schemes. Many of them publish prices and licensing information on their website. If not, then you can always mail or phone for a quote.
    
3. How complex do you need the editor to be? Choose a product that has all of the features you need but not too many that you have no use for. Check out freeware or “Light” editions of commercial products, many of them are excellent and provide a wide range of tools that may be more than enough for your needs.
    
4. Does the selected application have a good, helpful customer support team? Customer and technical support can be provided in many different ways. Sometimes none is provided at all. In any event, is the support scheme available for the product, one that suits your needs and demands?
    
5. What is the application’s learning curve? You don’t want the learning process for the application to be a bottleneck for each new addition to your development team.
    
6. Does the application have understandable and logical Help documentation – written, on-line or built-in? Can it be mastered easily by the user or will it be necessary to employ a support person to integrate the application in your company?
    
7. Does the application support the creation of multiple language package creation in the event that additional languages are needed?
    
8. Does the application allow for easy update, upgrade or Patch creation if necessary?
    
9. How easy is it to use the application to build an automated procedure – if at all?
    
10. Does the application support a simple Find and Change procedure?
     
11. How would you rate the program and final application implementation and performance?
      

Part of the development cycle for any installation package is the initial planning stage. We spend a lot of time and effort on this first process as this will determine the character of the final package.

However, even when the planning stage is completed and work is progressing on the development of the Installation Package, we often have the feeling that maybe there is something we missed, something we could have done differently. That’s the purpose of this post, to help developers focus on some of the more important aspects of the planning process and to be able to distinguish between a good installation package and an excellent one.

Perhaps the best way to begin the development of an installer package is, at the very beginning, to imagine yourself as the end user, the person installing a program using your installer package. It is important to remember that, even though the time spent interacting with the installer package is relatively short, it is also the time when the user is most concerned and uncertain as to the final outcome.

I think that almost every user (myself included) has often felt at some stage during the installation process that his PC has frozen or is about to burst into fire and wonders if he should press the “reboot” button.

In order to make the process less painful and anxious for the end user, I recommend taking the following actions:

1. Remove un-needed dialog: sometimes we leave a redundant dialog box in the setup process. Make sure to avoid this – the end user might think that his installer package is missing an element or is corrupted. In any event, it is confusing and leaves a bad impression.
     
2. Ensure that your dialogs display the default values: when asking for a user response during the installation process, make sure that the default values are show automatically when the dialog GUI is displayed. This is the industry standard!  Your installation should succeed (i.e. successful application execution with general features) even if the user just kept pressing the Next button!
    
3. Ensure that the installation package supports a repair option: When an application has been corrupted and is no longer usable, having to uninstall and then reinstall can be an annoying and tedious process. If your installer package has a “Repair” option, this can be very helpful and less frustrating to the end user.
     
4. Make sure to save user settings: many programs have comprehensive and regular upgrade packages. However, often the implementation of these upgrades can be marred because the upgrade process erases previous user settings. Therefore, when developing an MSI based upgrade package, it is very important to allow the user to retain previous settings.
    
5. Spare the user from un-wanted applications embedded within the MSI package: many installation packages are actually a collection of installation scripts built by teams located in other locations. In cases where not all segments of the installation package are vital, it is essential to allow the user the option to choose which parts to install and which not.  In addition, make sure that the installation will succeed whatever segments the user chooses to install or not install.
    
6. Spare the user from un-needed upgrades: whilst it is true that a major upgrade replacing the installed software in its entirety is the easiest maintenance scenario for the installation developer, I recommend using a Patch to modify installed software. This is a much simpler procedure for the end user and less intimidating especially when working with Vista (which will save the user from additional UAC dialog due to the sticky elevation mechanism).
    
7. Try to avoid confusing warning or error dialogues: unfortunately many installation developers are not doing enough to make sure the user will not have to deal with un-clear warnings or error messages. This includes the “File in Use”\”Restart Manager” pops-up that can appear when the Msi package attempts to update or uninstall files being used by the application.
    
8. Eliminate unnecessary reboots: make efforts to eliminate unnecessary computer reboots during the installation. Apart from the time element, many users have open and unsaved files or open web pages with information that will be lost if the computer reboots.
    

Pantaray Research have released SuperOrca MSI Editor - A Developers tool that enables easy editing of MSI Installer Packages. 

Limitations in existing Windows Installer tools mean that the developer must edit Windows Installer package (.msi) files directly. SuperOrca is an MSI Developer System that is an alternative to Microsofts’ Orca MSI. Using SuperOrca developers can examine and modify with ease an MSI database. 

SuperOrca from Pantaray is more powerful, smaller, easier to use and install than Microsofts’ Orca MSI and can be downloaded totally free of charge from Pantarays’ site with just a few clicks of your mouse.

SuperOrca MSI Editor has received an excellent review from a professional in the MSI development field.

The new SuperOrca from Pantaray Research can serve the developer installation community as well as IT managers by facilitating viewing and changing any MSI installation. Read More

After introducing the Msi platform in Article 1, I would like now to take a deeper look at its “roll-back” feature.

The idea of having an Msi platform is to register all the actions during the installation process and enable their retrieval (”roll-back”). Each and every action is logged in two separate locations:

1. c:\WINDOWS\Installer - stores a transformed copy of the original Msi, according to the actions performed during the installation process. This copy is later used, for example, to enable “Remove/Repair” and other maintenance sequences.

In addition, this file stores the PackageCode. Most Installation Editor Programs define this code as default behavior and use it to determine when to run      ”Update/Maintenance” Mode. (The code can be queried by either opening the Msi through the editor, or by right clicking it and then selecting the “Properties Summary” tab or the “Revision Number” field.

2. Registry Key - stores the GUIDs, as well as information about the features and components installed by each product and the relationship between them, as follows:

• Upgrade Code: A unique GUID defining the “family” of the product. This code is registered, after the installation is successfully completed, under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UpgradeCodes.
• Product Code: A unique GUID defining the installed product. This code is registered under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\[user identifier]\Products and as a sub-key under the UpgradeCode. The [user identifier] marks the unique GUID which is given to each user of the machine. The extra sub-key helps to distinguish between per-machine and per-user installed products.
• Features: The name of each installed feature and its encrypted data are listed under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\[user identifier]\Products\[Transformed Product Code]\Features.

They supply the relationship information between the installed components of each product.

• Components: The identifier GUIDs for all the components of each installed product are listed as a sub-key under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\[user identifier]\Components\[Transformed Product Code].

They supply the relationship information between the installed components of each product. Note that the GUID registered here is the transformed one.

• Patches: The list of patches installed for each product, and their properties, are listed under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\[user identifier]\Products\[Transformed Product Code]\Patches\[Transformed Patch Code]

Some of the terms mentioned in this article, such as “Feature”, “Components” and “patches”, will be clarified throughout the next articles of this series.

Software installers are extremely valuable to the software industry, as the first impression users receive when dealing with new software is its installation process.

Two major technologies are used for software packaging: The first is the traditional EXE and the second is Microsoft’s MSI.

Both technologies are marketed side by side, as each one has its distinctive advantages and disadvantages. One of the industry’s main challenges is to manage and combine the two technologies into one product.

• EXE - The traditional EXE is perfect for consumer applications that are distributed online or on CDs, as well as for internal company packages.

Most of the popular applications that can be downloaded from the net are EXE based. EXE provides enormous flexibility and a fully customized installation platform for popular applications such as Google, Skype and others.

There are many companies that provide EXE installers, such as “InstallShield”, “Wise” and “Pantaray Research”, while many other companies choose to develop their own internal installers.

The main drawback of the EXE installers is that if they are not developed professionally, the installation might cause conflicts in the Windows Operation System.

MSI – This platform is more applicable to IT Managers in enterprises, who wish to control the software installations throughout the entire organization. The MSI provides software packaging, patch testing, license management etc., enabling IT Teams to increase application reliability, improve productivity and reduce licensing costs.

The Windows Installer (MSI) is an engine used for installation, maintenance and removal of software on newly Microsoft Windows Systems. The installation’s information, and often the files themselves, are packed in installation packages, commonly known as “MSI Files”.

Microsoft encourages third parties to use Windows Installer as their basis for installation processes, thus ensuring correct synchronization with other installers and keeping a consistent internal database for installed products. The reliable operation of important features such as “rollback” and “versioning” (which prevents “DLL Hell”…) depends on a consistent internal database.

The MSI, which is supplied by companies such as “InstallShield”, “Wise”, and “Pantaray Research”, provides more protection from unauthorized actions and from conflicts in the Operating System, but at the same time considerably reduces the flexibility and richness of the installation. MSI installation files also tend to be larger in size than equivalent .zip or .rar files (or self-extracting .exe), due to the fact that the file’s internal database is not compressed.

As each technology carries its distinct values in different areas of software installation, one of the industry’s main challenges is to develop one overall tool that may provide the “best of both worlds”, for enterprise and consumer applications.

Although the installation processes of each technology are different and cannot be unified, the user interfaces for installations can be united, thus making life much simpler for the developer, who can perform all the needed actions and directions of the packaging process, and then choose whether to compile in MSI or in EXE. All the directions regarding the files and their destinations will be shared in the same GUI.

Pantaray Research took upon itself the challenge of providing the same installation sequence for both technologies, and succeeded to develop the perfect GUI enabling either EXE or MSI. All the programmer needs to do is to follow all the necessary installation instructions and then to decide whether to compile the setup in EXE or MSI.

In my many years of work with Msi, I have witnessed developers (even
experienced ones) stumbling again and again over infrastructure issues and especially over the subject of Msi. In this article I wish to introduce the Msi as
a friendly platform, which - if used smartly - can be of tremendous assistance to any developer.

Let’s start with some general background

The Msi platform was developed by the Office Product Group, after the guys over there had realized that most of the customer support issues that they had been handling were due to faulty installation.  The development process of the Msi was a pioneering effort, with limited resources. It took some time for Microsoft to acknowledge the importance of it and designate the required resources for its execution.

In fact, at the beginning of the platform’s distribution, Win9X and Win2k systems did not have the Msi engine, and as a result - the installation media had to include two additional exe files (instmsia.exe and instmsiw.exe) which were used to actually install this engine.

If I was asked to define what Msi is in one sentence, I would describe it as a singleton event-driven database, which includes many tables containing information and objects.

The tables are inter-connected by 1:1 and 1:Many relationships. The Msi registers all the actions of the installation process in order to allow their “roll-back” / retrieval. If you go over an Msi-based log file, you will see that the Msi Engine performs many SQL queries in order to “decide” which actions to perform. None of these actions is being registered in the Operating System until the process is successfully completed (to enable the “roll-back” as well as a clean exit). The Msi will start working only after being executed by the user and it cannot run with more than one installation simultaneously.

Why is it important to use an Msi platform?

Today’s applications are built out of many versioned and un-versioned files. As a result, many dynamic changes need to be made in the end-user machines (wherever a simple XCopy action cannot do the job) and the configuration/installation process becomes more vulnerable to bugs and errors. A research published by IBM reveals that 28% of software projects all around the world fail due to configuration/installation problems. I’ve personally witnesses such projects go down the drain, and that’s one of the reasons that had motivated me to enter the CM/Install world.

Bob Baker states in his excellent book “The Official InstallShield for Windows Installer Developer’s Guide” that “Installation of an application is the end user’s first experience of the product. A bad installation can create a negative impression in the customer’s mind, before he even gets to run the application“. I can safely say that the customer doesn’t really care about the efforts that were put into the application’s development or about how many developers had participated in this project. He wants to see that the application’s installation is completed successfully without any errors or warning messages.
If it doesn’t happen - he becomes suspicious and worried. You should never underestimate the importance of a good first impression!

The next articles in this series will shed more light on the key concepts of the Msi, its development and its best practices for Windows.