Customizing MSI packages with ORCA

Hey there,

since this question comes up from time to time, I found it’d be good to have it blogged. I’ve found myself in the same situation for a couple of times: you want to deploy an MSI package (via GP Software Installation) and want to modify the package so that it reflects a couple of settings right after installation.

Let’s say we wanted to deploy Acrobat Reader. It has an MSI file (after extracting the EXE installer) you can deliver. A downside here is that, although installed on the target clients, people are forced to accept the EULA to proceed using it the first time. Hmm… okay, you bing for a solution and find that there’s a command line switch for the MSI package, like EULA_ACCEPT=YES. Good – you can use that in script based installations, invoking msiexec. How would you specify that switch with GP Software Installation? The short answer is: you can’t.

For Group Policy Software Installation, all administrators can provide is an MSI file (the installation package itself) and a so-called transform file MST. A transform file can contain changes to the MSI package to customize installations or provide different flavors of an installation/enable features during installation and such. You basically could have one distribution point with your MSI file and create five Group Policies, all using the same MSI file but with different MSTs configured. If you can choose options during the installer, you can configure those options in an MST.

Okay, enough with the talking, we found that we have an MSI file we need to customize, since this EULA thing annoyes us (would we roll the software out, if we didn’t agree to the EULA?) and an MST file looks pretty good for our uses – how should we proceed?

The answer lies in a pretty little tool called ORCA that is part of the Windows Installer SDK. Orca is capable of opening MSI files and performing changes to it. Apart from changes to the MSI file directly, you can have ORCA write changes you perform into an MST file – that can be deployed via GP.

Downloading Orca is free – but getting it is a little difficult. There are a couple of source out there that provide a copy of ORCA, however I suggest you download it directly from Microsoft. That way you’re sure the bits are correct and Dr. Evil won’t compromise your machine. You don’t need to download the Windows Installer SDK as a whole. What you need is the Tools CAB file, at http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/msisdk-common.3.0.cab. It’s about 4 MBytes of size. Download it and extract it. Within the CAB file, there’s a file called “Orca_Msi.{some GUID}”. Just extract that file. There’s your ORCA MSI file you just have to rename to ORCA.MSI and install.

Now, it is time to start ORCA and open our MSI file. For the sake of this example, I have an Acrobat Reader 9 MSI file. Looking at the GUI, it has two panes: the left pane is called “Tables” and the right pane contains Properties and values. MSI packages are like small databases that hold keys with values that make up an installation packages with the needed files and settings. So — where’s this “EULA_ACCEPT” setting we wanted to roll out along with our MSI? It’s in the “Properties” table. I recommend that, if you open a table, you click the “Property” tab to sort for property name (how did I found out about that? Read below, “Notes”).

Before we do any changes to the MSI file, let’s create a Transform. Choose “New Transform” from the “Transform” menu. Seriously, you could have figured that yourself, right? The title bar of ORCA now says “Acrobat.msi (transformed by Untitled)”. We’ll give it a descriptive name later.Â

Now, double click on the value of “EULA_ACCEPT”, which is currently set to “NO” and edit the value as you wish. I choose “YES” here. That’s it. If you have other customizations to do, then perform those. Once you’ve finished the package, make sure you “Transform”-> “Generate Transform”. Orca create a custom MST file you can now go deploy with your MSI installer file.

Make sure you upload that MST file to the distribution point too so users and computers can access it. Even if you’re a script installation guy, creating an MST file and providing its path during installation might be easier than appending all the customizations and switches as a command.

I hope you’ll love ORCA just as I do.

Further Notes:

  • Switches you can use for command line installations (using msiexec) always go into the “Property” table. If you can find the command line (EULA_ACCEPT) switch to a functionality you need, it’s in the Property table.
  • Check other tables in the MSI file, too. “Directory” holds a list of directories that are created/used during installation. Some (bad) packages have a hard wired installation path in there. You can find it there and change it accordingly. “Custom Action” contains actions performed during installation. If the installer starts an action during installation, it probably is there.
  • Some actions in the CustomAction are filters and checks performed before installation. Those checks can be manifested in the “InstallExecuteSequence” table. I’ve used that for example with GPMC which would only install with .NET Framework 1.1 installed. In fact, the installer checked for .NET 1.1 but wouldn’t accept 2.0 or later (although it works!). “Customizing” the condition would relax the installer.
  • Note that messing with MSI packages might be out of scope of your software vendor. I suggest that, if you use ORCA to customize your packages, don’t make those changes to the MSI itself – create an MST file. Be prepared that, if your installation fails and you seek support from the vendor, you may be asked to perform the installation with a non-customized/non-transformed MSI package.
  • An excellent resource on MSI and installer customization is “Appdeploy”, http://www.appdeploy.com. I’ve used this site many many times. You’ll be surprised about how many packages and products it covers. It’s a free site and lives from community contributions. Look for “Package KB” and search for your product. I’ve used http://www.appdeploy.com/packages/detail.asp?id=1328. Don’t miss the “Notes” tab (people seem to only look at the “Command Line” tab), it includes all the goodies you might want to enable/disable.

5 Comments so far

  1. Cam on February 1st, 2010

    Hi
    I need to pass some custom parameters to my msi so that this can be changed by the admin before deploying on users PCs.
    How can I do this using mst files?

    My example is a button added to MS Office and I need to change the name on the button without rebuilding the solution; just changing mst and redeploying!

    Thanks

  2. florian on February 2nd, 2010

    Cam,

    I don’t think you can do that with an MST. If that customization is within Office, you’ll need to do that post installation.

    Customizing the MSI/MST only targets the installation itself and the installation routine but not the product once it’s installed.

    Cheers,
    Florian

  3. Cam on February 2nd, 2010

    Thanks Florian… This was helpful… at least I would look for another way for doing it :)

  4. sitaram on February 6th, 2010

    I can not resist from posting this useful information in my blog. This information is really useful specially for peopel who are not familiar with customizing msi installation.

    http://techibee.com/tips/customise-msi-installation-through-gpo/278

  5. Konrad Bauckmeier on March 3rd, 2010

    Because getting Orca from Microsoft is such a pain, I installed SuperOrca instead http://www.pantaray.com/superorca