MSI 1639 and 1624: Invalid Command Line or Transform in Silent Deployments

Fix it now

1639 is ERROR_INVALID_COMMAND_LINE – msiexec could not parse what it was given – and 1624 is ERROR_INSTALL_TRANSFORM_FAILURE, an error applying transforms, with Microsoft asking you to verify the transform paths are valid. Both are deployment faults rather than package faults: the same MSI that fails from a script installs perfectly when you double-click it.

msiexec /i "C:\pkg\app.msi" /qn /norestart TRANSFORMS="C:\pkg\site.mst;C:\pkg\lang.mst" INSTALLDIR="C:\Program Files\App" ALLUSERS=1 /l*v "C:\pkg\install.log"

1. Print the exact command your script builds immediately before it runs, and read it. Most 1639 faults are visible the moment you see the expanded string.
2. Quote the value, not the assignment. INSTALLDIR="C:\Program Files\App" parses; "INSTALLDIR=C:\Program Files\App" does not.
3. Write public property names in capitals. Microsoft’s rule is that public property names cannot contain lowercase letters, and anything else is private and never reaches the part of the install that changes the machine.
4. For 1624, confirm each transform exists at that exact path, is readable by the account running the install, and was generated against this package.
5. In PowerShell, build the arguments as an array and use Start-Process msiexec -ArgumentList $args -Wait, or put --% ahead of the arguments so PowerShell stops interpreting them.

Do not mix bare file names and full paths in one TRANSFORMS list. Microsoft states plainly that you cannot use file names and paths together in the same TRANSFORMS list, and a mixed list is a common source of 1624.

If a log file appears at the path you named, the command line parsed and you are past 1639. If the transforms still fail, the next section explains what a transform validates against.

Why it happens

Windows Installer parses its own command line rather than relying on the shell, and the grammar is stricter than most command-line tools. Switches come first, then the package, then any number of property assignments in the form NAME=value. Anything the parser cannot fit into that shape produces 1639 without attempting the install – which is why the error arrives instantly and no log is written unless the logging switch itself parsed correctly.

Spaces are where this usually breaks. A path containing spaces has to be quoted, and the quotation marks must enclose only the value. Quote the whole assignment and the parser sees one long token that is not a valid property name. The same applies to the log path after /l*v, which is a separate argument and needs its own quotes. And the case rule catches people who never see an error at all: Microsoft documents that public property names cannot contain lowercase letters, and that properties set during the user interface phase and passed to the execution phase must be public – so a lowercase property parses cleanly, does nothing, and the install succeeds while ignoring you.

Transforms are passed as a property rather than a switch, and they carry more rules than most people realise. TRANSFORMS takes a semicolon-separated list applied in the order given. A leading colon means the transform is embedded in a storage inside the package rather than being a file on disk, and Microsoft notes that embedded transforms are not cached and are always obtained from the package. A leading vertical bar marks a secure-full-path transform, where the source must be at the full path passed to TRANSFORMS. And you cannot mix bare file names with full paths in the same list at all.

Full reference

Command lines that work and command lines that do not

msiexec /i "C:\pkg\app.msi" ^
  TRANSFORMS="C:\pkg\site.mst;C:\pkg\lang.mst" ^
  INSTALLDIR="C:\Program Files\App" ALLUSERS=1 ^
  /qn /norestart /l*v "C:\pkg\install.log"

Transform prefixes, and what each means

The logging switch, and why it matters here

/l*v is worth adding to every unattended command line, not only when troubleshooting, because its presence or absence is itself a diagnostic. Microsoft documents that the path to the log file must already exist – the installer will not create the directory structure – so a missing log can mean either that the command line failed to parse or that the folder is not there. Create the staging folder as the first step of your deployment and that ambiguity disappears.

Internal errors you may see alongside 1624

Both are internal messages rather than exit codes, and both point at the transform rather than at your command line. 2226 is the general statement that applying the transform failed; 2247 is more specific, a read or write failure against the transform stream itself, which is what a truncated or corrupted .mst produces. Regenerate the transform rather than editing it.

Making unattended deployment repeatable

• Stage the package and every transform to a local folder as the first step, and reference them by absolute local path.
• Build the argument list as an array, not by string concatenation, and log the expanded command before you run it.
• Keep property names in capitals, and check the log to confirm the values you passed appear with the values you meant.
• Version the transform with the package it was built against, and regenerate rather than reuse when the vendor ships a new build.
• Treat 1639 as a script defect and 1624 as a file or policy defect. They look similar in a deployment report and they are not.

Every code this article covers

Confirm the fix worked

1. A log file appears at the path you specified, which proves the command line parsed.
2. The log records each transform being applied, in the order you listed them.
3. The properties you passed appear in the log with the values you intended, in capitals.
4. The same command runs through the deployment tool, not only from a Command Prompt.
5. A second machine of the same build produces the same result from the staged copies.

Questions people ask about this