Java MSI silent installer

Question

Hello i'm having issues with this line of code I been working on, for some reason is not working anymore I'm trying to invoke the MSI installer silently and wait till it's done so I can execute next line of code I had it working but now is not, I tried executing start-process and using the -wait parameter but it's returning with an error message, and when I call "msiexec.exe" it doesn't have a -wait parameter

msiexec.exe /i "C:\MagtekCC\Files\Java\jre1.8.0_144.msi" /QN TRANSFORMS="jre1.8.0_144.mst" /L*V "C:\Temp\msilog.log"
Write-Host -NoNewLine "Done.`n" -ForegroundColor Cyan
Start-Sleep -s 2



  start-process msiexec.exe  "/i C:\MagtekCC\Files\Java\jre1.8.0_144.msi" -wait /QN TRANSFORMS="jre1.8.0_144.mst" /L*V "C:\Temp\msilog.log" 
     Write-Host -NoNewLine "Done.`n" -ForegroundColor Cyan
      Start-Sleep -s 2

> Start-Process : A positional parameter cannot be found that accepts argument '/QN'.
At line:1 char:1

    + start-process msiexec.exe  "/i C:\MagtekCC\Files\Java\jre1.8.0_144.ms ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidArgument: (:) [Start-Process], ParameterBindingException
        + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.StartProcessCommand

Answer 1

msiexec.exe is a GUI tool, and Windows CLI (Command Prompt or PowerShell) will not block by default. Conversely, console applications will block by default. In PowerShell, you can alter this default behavior (as well as gain additional control and information about the child process) by using Start-Process.

Note: This answer focuses on Start-Process but the equivalent way to force a program to wait before continuing in the Command Prompt or .bat script is

start "title" /WAIT [command/program] [parameters]

Note that the "title" can be a blank string "".

---

Since you've updated your question with your Start-Process attempt, it failed because you provided the -Wait parameter in the middle of the -ArgumentList arguments. -ArgumentList is defined specially, so all remaining positional arguments following it are considered part of it. The problem is when you stick another named parameter there, you've now broken the chain of arguments. The solution is shown below, but make sure you provide the -ArgumentList arguments without separating them with other parameters to Start-Process:

$msiExecArgs = @(
  '/i',
  'C:\MagtekCC\Files\Java\jre1.8.0_144.msi',
  '/QN',
  '/L*V', 'C:\Temp\msilog.log',
  'TRANSFORMS="jre1.8.0_144.mst'
) -join ' '

Start-Process msiexec -Wait -ArgumentList $msiExecArgs

This works in the following way:

• Create an array of msiexec arguments. This can be an array of each space-separated argument you would normally pass to msiexec.exe in the same order you would specify interactively. Alternatively, you can also provide it as a single string. Read the sub-point below to understand why I declare this as an array only to -join it to a string.
  • Due to this bug providing arguments as a string is recommended, and is why I took the array arguments and use -join to create a space-delimited string out of them. The array code is a bit easier to manage as now we don't have to use += (gross and not recommended) or StringBuilder (recommended over += but overkill for building an array of arguments) and we still get the string which avoids the bug.
• -Wait tells Start-Process to block further execution until the program exits.
• -ArgumentList is used to pass our array of $msiExecArgs arguments to msiexec.

---

Note: A prior revision of this answer incorrectly stated that Start-Process needs
-Wait:$false in order not to block on execution for CLI applications. While the default behavior for external programs is to block for CLI and not block for GUI, Start-Process actually ignores this and does not block by default regardless of the program type. Use the -Wait parameter to block, and omit or provide -Wait:$false not to block.

Conversely, if you wanted to run a CLI program in the background, do the same thing as above but omit the -Wait parameter instead (you will probably want to check the result as well which requires a little extra elbow-grease with -PassThru so we can check whether it's done and its exit code):

$p = Start-Process ping -PassThru -ArgumentList www.google.com

# Do other stuff, then check the result when ready
Write-Host "Checking that ping.exe has finished"
while( !$p.HasExited ) {

  # Wait 1 second before checking again
  Start-Sleep 1
}

if( $p.ExitCode -ne 0 ) {
  Write-Error "ping failed with exit code $($p.ExitCode)"
}

• Using ping.exe as an example, we run it through Start-Process. ping.exe is a console application, and would normally block until execution completes.
• -PassThru is used to tell Start-Process to return the Process object. Start-Process does not return anything by default, but in this case we later want to check that this is done running and whether it succeeded. This is optional but required to check the result later on.
• The while loop waits for $p.HasExited to return true. Process.HasExited is used to determine whether the process execution has finished, regardless of success or failure.
• The if statement checks that the exit code of the Process object returned 0. As a matter of standard, a program can normally be considered successful if it returns 0, though you can specify an array of acceptable exit codes should a program use other codes for different end states.

---

There are other things you can do with the process object as well, play around with it. However, while Start-Process can be a powerful tool it is often overused, unnecessarily complicating code which does not need it. While your use case for MSIEXEC is a perfect example of when to use it, oftentimes you can simplify the use of Start-Process by omitting it altogether and relying instead on the call operator & to execute programs.

Answer 2

msiexec.exe is unusual in that, while it has an extensive CLI (command-line interface) with many supported parameters, it is a GUI-subsystem executable that runs independently of any calling console.

PowerShell runs GUI-subsystem executables asynchronously when you invoke them directly; that is, unlike with console-subsystem executables, it doesn't wait for the executable to terminate before continuing.

While Start-Process -Wait is indeed the typical way to invoke a GUI-subsystem executable synchronously, there is also a convenient shortcut:

If you pipe to Write-Output:^[1]

• PowerShell will wait for the executable('s process) to terminate, even if it is a GUI-subsystem application.

  • Note: If you know that the GUI application produces no stdout output - and not doing so is typical - you can also pipe to Wait-Process for better conceptual clarity (again, see footnote [1]).

• Additionally, the automatic $LASTEXITCODE variable will properly reflect the process' exit code (which not many GUI-subsystem executables meaningfully set, but misexec.exe does), allowing you to infer success (exit code 0) vs. failure (any nonzero exit code), by convention.

Therefore, you can use the following:

# Note the `| Write-Output` at the end of the line, which ensures *synchronous* execution.
msiexec.exe /i "C:\MagtekCC\Files\Java\jre1.8.0_144.msi" /QN TRANSFORMS="jre1.8.0_144.mst" /L*V "C:\Temp\msilog.log" | Write-Output
$exitCode = $LASTEXITCODE

Write-Host -ForegroundColor Cyan "Installation finished with exit code $exitCode."

The above is the more convenient alternative to the following Start-Process -Wait solution, which also uses -PassThru to pass an object representing the launched process through, so that its .ExitCode property can be checked:

$exitCode = (Start-Process -Wait -NoNewWindow -PassThru msiexec.exe @'
/i "C:\MagtekCC\Files\Java\jre1.8.0_144.msi" /QN TRANSFORMS="jre1.8.0_144.mst" /L*V "C:\Temp\msilog.log"
'@).ExitCode

Write-Host -ForegroundColor Cyan "Installation finished with exit code $exitCode."

^{Note: -NoNewWindow typically makes no difference in this case, but would allow console output from those rare GUI applications that explicitly attach to the caller's console (see footnote [1]) to surface in the current console - albeit without the ability to capture it.}

Note how all arguments for misexex.exe are passed as a single string to Start-Process (using a here-string for readability here), which positionally binds to the -ArgumentList parameter.

While the -ArgumentList parameter technically accepts an array of arguments - i.e. allows you to pass arguments individually - a long-standing bugs makes that unadvisable - see this answer.

---

As for what you tried:

Your Start-Process -Wait call failed, because you ended up passing more than two positional arguments:

start-process msiexec.exe  "/i ..." -wait /QN ...

• msiexec.exe positionally binds to the -FilePath parameter.
• Only the "/i ..." argument positionally argument binds to the -ArgumentList parameter.
• Since no other Start-Process parameters support positional binding, Start-Process doesn't know what to do with /QN (and all subsequent positional (unnamed) arguments), which is what the error message in your question indicates.

Note: If you did want to pass parameters individually - which is best avoided, as stated above - you'd have to pass them as an array, separated by ,
(Start-Process -Wait msiexec.exe '/i', ...)

---

^{[1] Note that any command in a subsequent pipeline segment works to ensure synchronous execution, because PowerShell always has to wait for the preceding segment's command to terminate, so as to ensure that all input has been received; While it ultimately doesn't matter what command you choose, Write-Output, which in this case will typically be a no-op, has the advantage of passing stdout output through so that it becomes visible / can be captured, if the GUI application at hand produces such output, which is rare (append 2>&1 to the GUI-application call to also capture stderr output). As Bender the Greatest points out, some GUI applications do so in order to produce debugging output, by explicitly attaching to the caller's console.}