All applications fit neatly into one of two categories - those that repackage easily and those that are close to impossible. For the past 2 months I’ve been dealing with one of the latter, ArcGIS by Esri, a geographical information system. Basically, it’s a suite of apps for working with mapping data that’s split into many components.
The problems with packaging aren’t the fault of Esri at all. In fact, unlike a lot of companies, an MSI is provided on the disk which would normally make life easier. On an RM network however, the procedure is a little different from a vanilla deployment. Instead of using active directory to deploy the MSI directly, you have two options:
- Set up a “package build” workstation - essentially a computer with a minimal number of packages. You then use the RM Application Wizard to perform a “before scan” of the station, install your software and then run an “after scan”, capturing the changes and creating an MSI file. On the plus side, this lets you change program settings before deployment which is a nice touch. One of the problems I often run into is that occasionally changes are missed, which makes some software think the install is corrupt. The other common problem is that user settings are often pulled into the MSI and during deployment these are sometimes unable to be set and the install will fail.
- The Application Wizard is also able to accept MSIs directly, repackaging them on the fly and generating shortcuts and other required files in the RM package format.
Unfortunately, both of these methods failed for ArcGIS. I suspect the software is just too big and complex for a simple repackage job - a basic install is over 1.4GB, with files and registry keys all over. That’s 1.4GB of software - no maps, no data! The MSI deployment would always fail with an MSIInstaller error 11606, complaining that it was unable to find “WindowsVolume%\”.
I decided the best way forward would be to somehow install the original MSI unedited. The RM system does support this by way of its package.ini files. Using these, you can set EXEs to run and MSIs to install. What I couldn’t do was pass the /qb switch to the MSI in order to do a typical, silent install. It was time for some scripting…
The workaround was to tell the package manager to execute my custom batch file, which itself called MSIInstaller /I setup.msi /qb after verifying the sizes of certain installer files. Frustratingly, when the batch file finishes, it seems to return a code that the RM package manager interprets as a failed install! Luckily, though there’s a switch in the package.ini file to ignore return codes and this seemed to do the trick. Big thanks to whoever at RM implemented that feature!
I also had to write an uninstaller batch file, again calling MSIInstaller with the correct product code, since the RM system now has no record of the particular MSI that has been installed.
In an ideal world, that would be it but I also had to install a service pack that was supplied as an MSP file. I couldn’t use method 1 above to package it because I couldn’t do the original install that way and method 2 doesn’t support MSP files. Neither, it seems, do the RM package.ini files, as you can only specify an MSI to run, not an MSP. Batch file time again, this time executing the MSP in the same method as above. Finally, a working installer that brings together the two worlds of vanilla MSIs and the RM system.
It took a little longer than our usual 2 day turnaround on software packaging but I’m pleased with the result, from now on it’s quite simple to install generic MSI files with just a little batch editing. Don’t get me wrong, the RM system has its advantages but this method is sometimes much easier than trying to work around strange repackaging errors.
Give it a click to expand the image. What’s wrong with it? At first glance, not too much. There are only 3 major elements after all - a graphic, a web browser control and a button group. Something doesn’t seem right though and here’s my list of gripes:
