Sigivald
12th May 2009 23:12 UTC

Exec, elevation on Vista, and .msu files
So we have this installer. It wants to run on Vista and download and install Windows Installer 4.5 as a shiny .msu file.

It does what's expected on XP (so I know the download works and the installer is basically correct).

In Vista, the ExecWait on the .msu downloaded fails silently. Some flailing around eventually got it to admit it was failing because it wasn't running as Administrator.

This is odd, since the installer itself elevates (prompt and everything) and can write to the Program Files directory.

All the documentation I can *find* suggests that it should exec programs as Administrator... but evidently it isn't?

I just spent a few hours trying to get the UAC addin to help; it did not. Running from the elevated UAC version of the installer produced the same result, as did explicitly setting UAC::RunElevated and/or using UAC::ShellExecWait.

I've also tried explicitly Exec'ing and ShellExec'ing wusa.exe, with no difference.

Has anyone else found and solved this? Is it some weird problem with .msu files?

Anders
13th May 2009 00:28 UTC

forget about the uac plugin, it does the opposite of what you want.

ExecWait should work, are you using /quiet ?

Sigivald
13th May 2009 03:07 UTC

Yeah, the bit about UAC was just to show that we've tried everything we can think of, even forcing/confirming elevation and the like.

We are using /quiet (and /noreboot), yes.

Sigivald
13th May 2009 20:22 UTC

Turns out using nsExec::ExecToLog and explicitly using cmd.exe fixed it.

Why that should be so, while normal Exec doesn't work (but does for the other things we exec) is unclear. I blame some weird thing about the MSU or wusa.exe.

dipak_darji17
19th December 2009 09:19 UTC

Hi Friends...
Myself Dipak Darji.. From India (Vadodara)..
This is my first post on this site..

Let's talk about the issue..
yes.. .MSU files are not allowed to run in anyways from NSIS.. except calling complicated api functions..
I've another way to run .MSU file..

Just create batch file (*.bat) in temp folder through nsis ..

start "" wusa "<MSU files full path with file name>"

.. Later on run this batch file when required as below,

Execwait "$temp\<batch file name>"
..


See below full code to write batch file and run the same..


Push "$temp\RunMSU.Bat"
Strcpy $strInstallPath "<full path to msu file with file name>"
Strcpy $0 "$temp\RunMSU.Bat"
FileOpen $0 $0 w #open file
FileSeek $0 0 END #go to end
FileWrite $0 "echo off"
FileWriteByte $0 "13"
FileWriteByte $0 "10"
FileWrite $0 "start $\"$\" wusa $\"$strInstallPath$\""
FileClose $0
Execwait "$temp\RunMSU.bat"


..
All the best.. :up:
Hope this will resolve your problem..
;)

Squirre1
1st March 2011 20:45 UTC

I just had to post on this... I was scowering all over the web for a solution... This is what I have identified above and beyond what everyone else has commented on regarding the use of wusa.exe (WUSA - Windows Update Standalone Installer).

The errors and failures that everyone is receiving is in relation to the MUI or language pack not being available... The wusa.exe.mui is a dependency to wusa.exe and has to be located in the appropriate language folder off the root of the folder the EXE is located in, for example.

Some_Root_Folder\wusa.exe
Some_Root_Folder\en-US\wusa.exe.mui

If you include the above in your package, there should not be any issues.. With just about any newly compiled Windows 7 / Vista command line exe, you can just about guarantee it will have a corresponding MUI that has a great chance of being a dependency. For example, netdom.exe requires the appropriate netdom.exe.mui as well.

Please let me know if you try this method and continue to have issues.

Thanks,

Squirre1

*Note* when included them in my package, it was:
INSTALL_SOURCE\wusa.exe
INSTALL_SOURCE\en-US\wusa.exe.mui