Editing MSI Installers with Orca

An MSI file is a small relational database describing an installation. Orca is Microsoft's editor for that database, and it is the standard tool for anyone who has to deploy software across managed Windows machines.

Where to get it

Orca is not distributed on its own. It ships inside the Windows SDK.

Install the Windows SDK, selecting only the component that includes the MSI tools. After installation, look in the SDK's bin directory for Orca-x86_en-us.msi and install that. Orca then appears as a normal application.

This two-step process is the main reason people struggle to find it. It is a genuine Microsoft tool, and the copies distributed on download sites should be avoided in favour of the SDK.

What an MSI actually contains

Opening a package shows a list of tables. The ones you will use most:

Property — configuration values, including installation directory defaults, feature switches and licence keys.

Feature and Component — what gets installed, in what groupings.

File and Directory — the payload and where it goes.

Registry — registry entries written during installation.

InstallExecuteSequence and InstallUISequence — the ordered steps of the installation, including custom actions.

CustomAction — anything the package runs beyond standard installation steps. This is the table to inspect if a package is doing something unexpected.

The common tasks

Finding the silent install properties. Look at the Property table for values that control behaviour — licence keys, server addresses, feature toggles. These can then be supplied on the command line without editing anything:

msiexec /i package.msi /qn PROPERTYNAME=value

This is the preferred approach. Passing properties at install time is cleaner than modifying the package.

Creating a transform. When you do need to change the package, do not edit the MSI directly. Create a transform file instead.

In Orca: open the MSI, choose Transform, then New Transform. Make your changes. Then Transform, Generate Transform, and save an .mst file.

Apply it at install time:

msiexec /i package.msi TRANSFORMS=changes.mst /qn

Why transforms are better than editing: the original package stays intact and its digital signature remains valid. Your changes are separate, documented and reversible. When the vendor ships a new version, you can frequently reapply the same transform rather than redoing the work.

Removing a launch condition. Packages sometimes refuse to install for reasons that do not apply — an operating system check written before your version existed. The LaunchCondition table holds these.

Do this only when you understand why the condition exists. Bypassing a genuine prerequisite check produces a broken installation rather than a working one.

Suppressing a reboot. The Property table can carry REBOOT=ReallySuppress, though passing it on the command line is usually sufficient.

Inspecting before deploying. Reading the CustomAction table tells you what a package does beyond copying files. For software from an unfamiliar vendor being pushed to hundreds of machines, this is a reasonable due diligence step.

Alternatives to Orca

Command-line properties first. Most deployment needs are met without touching the package at all. Check the vendor's documentation for supported properties before assuming you need to edit.

Repackaging tools capture an installation and produce a new MSI. Heavier, and appropriate when the original is not an MSI at all.

Application packaging formats used by modern management platforms wrap installers with their own detection and configuration, which is increasingly where this work happens.

PowerShell can query MSI properties programmatically, which is better than opening Orca when you want to check something across many packages.

Cautions

Signature invalidation. Editing an MSI in place breaks its signature. Transforms avoid this.

Vendor support. A modified package may be outside a vendor's support terms. Transforms are usually acceptable where direct edits are not; check if it matters.

Version drift. A transform built against one version may not apply cleanly to the next. Keep a note of what each transform changes and why, or the next person will be reverse-engineering it.

Test on a clean machine. A package that installs on your workstation because a dependency is already present will fail elsewhere.

When this is worth learning

If you deploy software to more than a handful of Windows machines, understanding MSI structure repays the afternoon it takes. If you install software on your own computer occasionally, you will never need it — and a package that seems to require editing to install is usually a package worth questioning.

Mistakes people make

Editing the MSI directly instead of creating a transform. Direct edits break the digital signature and are lost at the next vendor update. A transform is separate, documented and reusable.

Downloading Orca from a third-party site. It ships inside the Windows SDK. Copies elsewhere are unnecessary risk for a free Microsoft tool.

Editing when a command-line property would do. Most deployment needs are met by passing properties to msiexec, with no package modification at all.

Removing a launch condition without understanding it. Bypassing a genuine prerequisite check produces a broken installation rather than a working one.

Testing on a machine that already has the dependencies. It will install fine there and fail everywhere else.

The short answer

Check the vendor's supported command-line properties first. If you must change the package, create a transform rather than editing. Read the CustomAction table before deploying anything unfamiliar at scale, and test on a clean machine.