0

I am trying to install an MSI via PowerShell using the following code:

msiexec /a [MSI File] /qn

According to the Event Log, the software was installed successfully, but does not appear in either Add/Remove Programs nor inside the registry key. I am on a laptop that does not have Admin control, which is why I'm using /a instead of /i. I have also tried the following code to same results as before:

msiexec /a [MSI File] ALLUSER=2 ARPSYSTEMCOMPONENT=0 /qn

Any clue as to why this is happening, and how I can fix this so the software can be properly installed?

Ansgar Wiechers
  • 193,178
  • 25
  • 254
  • 328
Lotzi11
  • 477
  • 1
  • 13
  • 26
  • How is this related to PowerShell? The MSI failure is not related to PowerShell. – Nasir Mar 01 '17 at 23:04
  • Have the installer [log what it's doing](http://stackoverflow.com/a/7130758/1630171) to actually see if anything goes wrong: `/l*v "install.log"` – Ansgar Wiechers Mar 01 '17 at 23:20

1 Answers1

4

The steps you are taking are not supposed to have the outcome you expect. As you briefly allude to, /a performs what is called an administrative install. This is not an installation of the software, but instead the creation of an uncompressed installation source. This is typically intended for a company to use in order to avoid having to physically share the installation disc (back when there were installation discs).

Your second command line has several errors:

  • /a still does not "install" the software
  • ALLUSER=2 is meaningless as the property ALLUSER is not defined. The correct property name would be ALLUSERS. You are probably looking for ALLUSERS=2 MSIINSTALLPERUSER=1 to invoke the Windows Installer 5 / Windows 7 or later per-user redirection. Note that MSIINSTALLPERUSER may not work correctly unless the package was authored with this so-called dual purpose in mind.
  • ARPSYSTEMCOMPONENT=0 might do the opposite of what you likely expect. Windows Installer works primarily on a defined/undefined (that is non-empty string vs. empty string) definition for truth rather than a 1/0 definition. While the documentation does say that setting it to 1 will prevent the application from being listed in ARP, the implementation likely checks for any non-empty string value. (Of course, per the first bullet it doesn't matter yet as you're not performing a normal installation.)

Your best bet is to acquire administrative privileges, in which case a simple msiexec /i package.msi will do the job. If you cannot acquire administrative privileges, and the package is authored appropriately, you may be able to install it with msiexec /i package.msi ALLUSERS=2 MSIINSTALLPERUSER=1. In either case you can also pass /qn or similar to suppress the UI, but I would suggest avoiding that until you have things working. As mentioned in a comment, adding /l*v verbose.log can help diagnose what's happening no matter the level of UI.

Michael Urman
  • 15,737
  • 2
  • 28
  • 44
  • The 2nd command worked to get me around putting in Admin credentials, but I was prompted with the following error: Error writing to file: C:\Windows\system32\Drivers\fortiapd.sys. Verify that you have access to that directory. Is there any way to get around this? – Lotzi11 Mar 02 '17 at 14:58
  • Unlikely. That appears to be (the first step of) installing a driver, which unequivocally requires administrative privileges. So this package is _not_ dual purpose. If the driver is not necessary, perhaps it can be removed with a transform, but only the vendor is likely to know the ramifications of such a change. – Michael Urman Mar 02 '17 at 15:05
  • So it looks like I need to get the Admin credentials. If I were to get the credentials, would I be able to plug them into my installation command? – Lotzi11 Mar 02 '17 at 15:26