An MSI Compatibility Transform (MST) is a modification file used during enterprise software deployment to alter the behavior of a vendor’s original Windows Installer (MSI) package. In the context of Application Virtualization (such as Microsoft App-V or MSIX), a compatibility transform strips away elements that cause virtualization to fail—such as hardcoded local paths, incompatible device drivers, or locked local system services—and introduces configurations that optimize the app for a virtual bubble.
Creating a compatibility transform ensures you do not alter the vendor’s original, supported MSI package while making it flawlessly compatible with your virtual delivery system. Key Scenarios for a Compatibility Transform
A transform file modifies specific database tables inside the MSI to bypass traditional local machine limitations:
Disabling Local Services: Virtual environments cannot easily run local Windows NT Services; a transform changes the ServiceInstall table to prevent them from installing natively.
Removing Device Drivers: Drivers cannot be virtualized in standard application layers. The transform bypasses driver installation routines.
Redirecting File Paths: Tweaking the Directory table to shift hardcoded C: paths to virtualized app paths or user-profile locations.
Bypassing Launch Conditions: Stripping OS version blocks or hardware prerequisites from the LaunchCondition table that might fail inside a virtual state. Step-by-Step: Creating the Transform File
To create a transform file, you must use a dedicated MSI packaging tool such as Advanced Installer, Orca (from the Windows SDK), or Flexera AdminStudio. 1. Initialize the Transform Project
Open your packaging tool of choice (e.g., Advanced Installer or Orca). Select New Transform (MST) or choose Open MSI as Transform.
Browse and target the vendor’s original application MSI file. 2. Apply Virtualization Compatibility Fixes
Navigate through the MSI tables to apply changes relevant to your virtualization guidelines:
Property Table: Set properties like REBOOT=ReallySuppress and ISCHECKFORPRODUCTUPDATES=No to avoid triggering local machine updates or unexpected reboots inside the virtual layer.
Component Table: Mark components as 32-bit or 64-bit explicitly, or disable components that rely on deep local OS integration.
Custom Action Table: Drop or condition out any Custom Actions (CA) that attempt to register hardware, execute native local binaries, or require elevated local administrative rights that the virtual bubble blocks. 3. Save and Generate the MST
Application Compatibility – Packaging and Remediation – Part 4
Leave a Reply