MST File Documentation

---

Technical details

Feature	Value
Full name	Windows Installer Transform
File extension	.mst
MIME type	application/octet-stream
Format type	Windows Installer database delta (OLE Compound File / CFBF)
Developer	Microsoft
Introduced	~1999 (Windows Installer, Office 2000 / Windows 2000 era)
Container / base format	COM Structured Storage (OLE2 / Compound File Binary)
Byte order	Little-endian (CFBF header)
Magic number (hex)	D0 CF 11 E0 A1 B1 1A E1
Open standard	No — proprietary; CFBF layout is documented, MSI schema is Microsoft’s
Applied to	A base .msi at install time (a delta, not a standalone installer)
Apply command	msiexec /i pkg.msi TRANSFORMS=custom.mst /qn
Editor	Orca (Windows SDK); InstEd; Advanced Installer
Typical use	Enterprise silent deployment via Group Policy, SCCM, Intune
Related extensions	.msi, .msp, .idt
Specification	learn.microsoft.com/windows/win32/msi/transforms

What is an MST file?

An .mst file is a Windows Installer Transform, a component of Microsoft’s Windows Installer technology that first shipped around 1999 with Windows 2000 and Office 2000. Windows Installer stores a software installation as an MSI database: a relational set of tables held inside an OLE Structured Storage file. A transform is a separate database of differences — rows to add, modify, or delete — that is merged onto the MSI at install time. It is a configuration overlay that changes an installer’s behaviour without altering the vendor’s original MSI.

MST is overwhelmingly an enterprise and IT-deployment artifact. Administrators use a transform to change which features install, the install directory, properties such as license keys or server names, removed shortcuts, and suppressed UI, then push that consistently configured application to many machines through Group Policy, SCCM, Intune, or scripted msiexec. Because an MST is only a delta, it is meaningless on its own; opening it without its base MSI shows almost nothing useful. There are older, unrelated uses of the .mst extension (some legacy game and audio formats), but the Windows Installer Transform is the dominant modern meaning.

The OLE Compound File container

An MST is physically a COM Structured Storage file, also called a Compound File Binary Format (CFBF) or OLE2 docfile. That is the same container Microsoft used for legacy .doc and .xls, for .msg messages, and for the MSI itself. Every such file begins with the 8-byte signature D0 CF 11 E0 A1 B1 1A E1 at offset 0. Internally the container behaves like a small file system: it holds named storages (directories) and streams (files), organised through a FAT-like sector allocation table, all little-endian.

Windows Installer maps its relational tables onto those streams. In an MSI, each stream is a table (Feature, Component, Property, and so on). In an MST, the streams encode the change set against a base MSI rather than a complete schema. Because the outer container is identical to an MSI’s, a file-type check on the header alone cannot tell an MST from an MSI or a Word document; the distinction lives in the transform-specific table content inside.

What a transform records: added, modified, and deleted rows

A transform is expressed as operations on the base database’s tables. Conceptually it captures three kinds of change: row additions (a new shortcut, a new property), row modifications (a changed INSTALLDIR, an injected license key, an accepted EULA property), and row deletions (a removed feature or shortcut). It can also add or drop entire columns and tables. When the transform is applied, Windows Installer walks these operations and produces an in-memory database that is the base MSI plus the changes, and installs from that.

A transform also carries validation flags and conditions that govern how strictly it may be merged: for example, whether it is an error if a row the transform expects to modify is missing, or if a row it tries to add already exists. These flags let an administrator control whether a transform built against one version of an MSI is allowed to apply to a slightly different one, guarding against silently corrupting an install.

Applying a transform with msiexec TRANSFORMS

A transform is never run by double-clicking it; it is supplied to an MSI install through the TRANSFORMS property. The base command is:

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

Here /i installs the package, TRANSFORMS names the transform to layer on, and /qn runs the install silently with no UI, which is the norm for mass deployment. Several transforms can be chained with semicolons, applied in order:

msiexec /i package.msi TRANSFORMS="a.mst;b.mst" /qn

Transforms embedded inside the package are referenced by a leading colon (TRANSFORMS=:embedded.mst). In Group Policy software installation the transform is attached to the package’s Modifications tab; SCCM and Intune wrap the same msiexec invocation. To see exactly what a transform does at install time, enable verbose logging and read the result:

msiexec /i app.msi TRANSFORMS=x.mst /L*V log.txt /qn

Creating and editing an MST in Orca

The standard authoring tool is Microsoft’s Orca, a free MSI/MST editor shipped in the Windows SDK’s MSI tools. Because a transform is a delta, you never edit the .mst in isolation: you open the base MSI, tell Orca you are working in transform mode, make your edits, and then have Orca compute the difference. The workflow is: open the MSI, choose Transform → New Transform, edit properties, features, and table rows, then Transform → Generate Transform to write the .mst. To inspect what an existing transform changes, open the MSI and choose Transform → Apply Transform, then look at which rows are highlighted. InstEd and Advanced Installer provide friendlier interfaces for the same operations, and the WiX toolset can author transforms programmatically.

Note that an MST is not “converted” to an MSI. In Orca you can open an MSI, apply a transform, and Save As a new MSI that bakes in the changes, but that is merging the delta into a full database, not converting the standalone .mst.

Is an MST file safe? A supply-chain concern

An MST is data, not directly executable, so it does not run on its own. The risk is indirect but real: a transform changes how an installer runs, and installs frequently execute with elevated administrator rights. A malicious or tampered transform could redirect install paths, disable security prompts, add an unwanted component, or alter which files are deployed, and because a transform is pushed to many machines at once, a bad one is a genuine supply-chain problem. The safe practice is to apply transforms only from trusted sources (your own IT department or the software vendor) alongside their intended MSI, and to inspect an unfamiliar .mst in Orca before deploying it. Verify provenance the same way you would for the MSI itself.

References

• Microsoft Learn — Windows Installer transforms overview
• Microsoft Learn — Orca.exe (MSI/MST database editor)
• Microsoft Learn — the TRANSFORMS property (command line)

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.