Executive Summary

The implementation toolbox provides a set of tools to make implementing iMIS faster and more reliable. It consists of a series of processes to support the following:
• Initial installation of iMIS and upgrades of iMIS through a centralised process controlled through Active Directory.
• Support for additional files, add-ons, Xtenders, utilities and components to be added to the iMIS folder and installed on the client together with iMIS without separate client installs. For example the easy install of UK Crystal Reports onto each client.
• Quick and easy setting up of configuration options in the iMIS database, simply by selecting the appropriate options and applying them to the database; it is also possible to export options from the database in order to copy them to a similar install or into a test or development environment.
• Import of client data into iMIS either for the initial upload or as a repeatable process.

Background

The can be a lot of effort involved in iMIS installation, the deployment of additional modules/Xtenders, the configuration of iMIS and in maintenance and upgrades.

The purpose of the Implementation Toolbox is not to provide a silver bullet to all these problems, but to provide a set of tools to automate various common tasks, making these processes faster, more reliable – because of automation – and easy to repeat.

Here are some typical problems.

Because iMIS comes with its own stand-alone install, it is not possible to include any other modules and files as part of the original iMIS install – these must be deployed after the iMIS install. This can lead to problems with missing files, files getting out of date, and administration of who has what files deployed.

Configuring iMIS involves going into various screens, entering specific data and setting various flags and options. When setting up a system it is necessary to have a certain level of knowledge for example awareness of lookup table names and values. It may be some settings are common to all installations – certain customizer screens for example – but have to be manually set up each time.

Functionality

Deploying Additional Files

Additional files deployed to clients may be any of the following:
• modifications to the HTML Framework files
• modified reports – for example a set of UK Crystal Reports
• Microsoft Office files – Microsoft Word documents or Excel documents
• Xtender files
• Omnis libraries
• Components
• .NET applications

Currently there is no simple solution to take these files and easily deploy them onto client PCs. Some Xtenders or third party applications may have their own installers, in which case installing an iMIS on a PC may require a whole series of installs, depending on the number of Xtenders and third party applications being deployed.

The solution to this is two-fold.

1. Firstly ASI must create a common installer policy with guidelines on creating installers. This must include that all installers use MSI packages and default install folders.
2. Secondly regional specific files should be created into MSI packages, confirming to the same guidelines.

The creation of MSI packages allows Windows Active Directory to centrally deploy installation packages to selected users. This will avoid the current problems of client installs, thus even if a user requires five or six separate installations, this need not be done by visiting the client’s PC but through a centrally managed process (installs can be configured to run automatically at logon, logoff, startup or shut down). Software can be deployed to selected users or PCs.

The existing “push” option for iMIS deployment is an ingenious way to manage installs from a central server, but suffers from a number of drawbacks (see appendix A) and is not a suitable basis for designing a central deployment solution.

Creating a regional specific MSI package (e.g. files for the UK) will need to ensure there are a number of install options within the package, for example:
• split Crystal Reports into related packages to install
• each Xtender to have a separate install option
• Different Framework files to have their own install options

In essence this simply means when running the install the user is able to choose which reports, Xtenders and framework file groups to install. The advantage of this is that these options can be saved in MST transform files (see appendix C). This allows an MSI package to be automatically installed with specific options selected.

Configuring Database Settings

iMIS Configuration Library

A standard part of any iMIS implementation is configuring the application. This typically involves updating a number of “system settings” tables such as Gen_Tables and System_Params.

In order to improve reusability of iMIS settings it would be useful to be able to easily export settings to a local data store and import them into another database.

A new iMIS Configuration Library application will therefore be developed to easily extract database settings from one database and apply them to another.

A modified local MSDE iMIS database will be used to hold database settings which can then be imported into the current database. The screen below lists various groups of lookups for the Gen_Tables table. By selecting the required lookup groups and clicking “Import” the user can easily upload the required lookups groups into the current database.

Clicking on the “Clear” button will allow any existing values in the main iMIS database that match those found in the selected categories to be cleared out.

Similar screens will be available to allow groups of values for the System_Params (these are Name/Value settings), Customizer screens and business objects.

The Customizer tab allows groups of associated Customizer screens to be automatically added to the database:

The Business Objects tab allows groups of business objects to be imported into a new database.

iMIS Configuration Library Export

A Configuration Library Export application will allow the data to be exported out of an existing iMIS database and stored in the local MSDE database.

In the above window the top list displays the data held in the main iMIS database, the lower list is data held in the local iMIS database

When the configuration library is installed the local settings database will also be installed as a SQL Server instance. The settings can then be imported as required.

iMIS Data Upload Application

The third element in the Implementation Toolbox is the upload of data into the iMIS database. This application makes it simple to upload data from an external datasource into iMIS.

The Import Database tab allows the connection to the external data source to be specified.
Multiple import datasources can be specified and held in the list, these are used later in the Field Mapping section.

Selecting a line in the data source list displays the full connection details. Setting connection details, specifying a Name and clicking “Add” will add a new datasource to the list.

Clicking the “Delete” button will remove a datasource.

Selecting a line and clicking “Update” will update the current datasource.

The iMIS Database tab allows the connection to the iMIS database to be specified.

The field Mapping tab allows imported data to be mapped to iMIS data. The tab display itself allows multiple mappings to be defined. The data source for each mapping can be specified and a description also listed.

The list shows the different imports defined.

The text box at the top left holds the name of an import.

The drop down list holds the datasource for the current import.

Checking the import marks it as being ready to run.

Add, Delete and Update buttons control the import list – add a line, delete a line and update a line.

Clicking the “Run All Imports” will run all checked imports. Clicking “Run Single Import” will run the current import whether it is checked or not.

The details of the mapping are displayed by clicking on the “Details” button. This opens the Field Mapping Details screen.

The drop down list on the left shows the tables and views from the selected import datasource. Selecting the drop down list then displays columns from the selected item.

These columns can be selected for importing by clicking the “Add” button which will populate the list below.

The left hand lower list displays selected import columns.

The drop down list at the top right shows stored procedures in the iMIS database. Selecting a stored procedure displays the parameters for the stored procedure which can then be mapped against the import columns.

If a stored procedure is already selected, adding import columns to the left hand lower list will automatically also map the columns to the parameters in the stored procedure.

When a stored procedure is first selected and if no columns have been selected for import, then no mapping appears.

Supplied import stored procedures can be used to import data into iMIS, or new stored procedures can be written if additional import logic is required.

The Event Logging tab controls where logging of the import is recorded and what level of messages are set in the log.

The checkbox for Windows Event Log will write log messages to the Windows Application log for the import. The Text log file option will write a log file for each import run into the folder specified.

If an email address is specified the log file details will be emailed to the specified address.

The message options checkboxes control if error messages, warning messages, information messages or debug messages are written to the log.

The import itself can be run with a command line option of /RUNNOW which will run all selected imports. This allows an import to be run as a repeatable scheduled process.

The settings for a DataPump are saved in an XML file with the DataPump install. The connection strings are held encrypted in the settings file.

Appendix A – Issues with iMIS Push Install

Essentially how the push install works is through a little utility program called xCmd.exe

http://www.codeguru.com/Cpp /network/remoteinvocation/article.php/c5433/

This allows a series of commands to be run on a remote machine as an administrator.

It is through this program that the iMIS install is run remotely on another PC.

The rest of the setup is giving permissions to the various SQL Server processes to allow this program to run. Why SQL Server? Well, because SQL Server contains an extended stored procedure called xp_cmdshell, which allows SQL Server to run a program - this this case the xCmd.exe program.

Most of the logic is contained in the iMIS stored procedure: sp_asi_ClientUpgrade.

Possible problems include:
It is necessary to enter the administrator username and password into the source code of the sp_asi_ClientUpgrade.stored procedure while you are running the upgrade
If the client machine has a firewall it might not allow xCmd to run
The network anti-virus software might pick up xCMD as a Trojan - so it might be necessary to add permissions for firewalls and anti-virus software to let the install run

Also given the existing iMIS install process, it is only possible to run a push install for an upgrade, not for a new install. The main problem with the current would be the Omnis serial number - you typically just have to type this in through a special Omnis dialog, however investigations performed by ASI Europe have identified that it is possible to directly write the Serial Number to the Omnis Executable without the user of the serialisation tool.

Appendix B – Creating MSI Packages

The key issue for central deployment is the creation of MSI packages. These have to be created with special tools, typically installation software such as InstallShield. However there are other utilities and tools available on the internet and Microsoft CDs:

Windows 2000 Server actually comes with a free one on the W2K Server CD (VERITAS). It is available on :\VALUEADD\3RDPARTY\MGMT\WINSTLE. An article on how to use this software can be found at http://www.mcsemag.info/solution/w2k04.htm

The Windows Installer XML (WiX) is a toolset that builds Windows installation packages from XML source code. The toolset supports a command line environment that developers may integrate into their build processes to build MSI and MSM setup packages. http://sourceforge.net/projects/wix

Some software also claims to be able to convert a standard installer into an MSI package, for example: http://sourceforge.net/projects/wix

A useful website for install developers is
http://www.installsite.org/

Appendix C – Transform Files

A transform (.mst file) is a simplified Windows Installer database that contains the differences between two MSI databases. Transforms allow an administrator to apply modified settings to a database when deploying an installation package.

To create mst files, use Wise InstallTailor - it is free.

Once you have created the file, just run msiexec to install based on the MST.

e.g.
C:\WINDOWS\SYSTEM32\MSIEXEC.EXE TRANSFORMS="my.mst" /i "my.msi"
Setup files from InstallShield support a number of command lines, see
http://documentation.installshield.com/robo/projects/HelpLibDevStudio9/I...

Wise InstallTailor is available from http://www.wise.com/installtailor.asp?bhcp=1 and it works as follows:

As more applications are delivered to system administrators already in .MSI format, you need a way to easily customize them for deployment in your organization. How can you quickly and easily create transforms (.MST file) to prepare packages for distribution? With InstallTailor, now offered as a free, fully-functional, stand-alone tool.

InstallTailor is the only free utility for automated transform creation. Why resort to substandard, ineffective tools when you can get a free, reliable tool from the packaging experts at Wise?

InstallTailor lets you customize Windows Installer installations by simulating running the package as you make the desired changes. Your changes to the package are recorded and the .MST file is created. The .MST file is then applied to the base .MSI file at runtime to execute your customizations. With InstallTailor, you can easily use the preferred method of Windows Installer customization, .MST files, to establish uniform installation settings across your enterprise.

This is what Microsoft say about transforms:
A transform is a collection of changes applied to an installation. By applying a transform to a base installation package, the installer can add or replace data in the installation database.
The installer can only apply transforms during an installation.
The installer registers a list of transforms required by the product during the installation. The installer must apply these transforms to the product's installation package when configuring or installing the product. If a listed transform is unavailable, and if the transform source resiliency cannot restore it, the installation fails.

A transform can modify information that is in any persistent table in the installer database. A transform can also add or remove persistent tables in the installer database. Transforms cannot modify any part of an installation package that is not in a database table, such as information in the summary information stream, information in substorages, information in nested installations, or files in embedded cabinets.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/about_transforms.asp
Other useful links are:
http://support.microsoft.com/default.aspx?scid=kb;en-us;308294&sd=te...
http://www.dawnstar.com.au/wpshelp/procedures/create_trans.html

The MSI SDK describes the transform process here:

http://msdn.microsoft.com/library/en-us/msi/setup/generating_a_transform...

Concept Document for iMIS Implementation Toolbox