Issue with ShellExecuteEx when run from a Service

As far as I know, the runas command is unable to accept a user account password as part of it's command line and will  always prompt for the password (in a gui window) which in turn is suppressed by the services not being able to open interactive windows with users.

If I try executing an exe having UI, the service is able to execute it. I verified this from task manager. This exe requires some user input so it can't proceed ahead.
If the service is able to execute the exe (which has UI) what is the issue with msi?

It's not the .MSI itself, it is how you are executing it.

When you say you run an .exe from the service and it works, are you trying to do it the same way, that is by passing it through "runas".
: service.run runas /user:joe  "c:\stuff\program.exe"

The runas command opens a command window and asks for input, this is different than the compiled .EXE (with a UI inside of it) displaying for the user.

When you run the .MSI from your service with the runas command, what happens? My first guess is that nothing happens and you get no command prompts, but it shows in the task-manager.

I am using ShellExecuteEx(...) for executing the exe/msi. And as mentioned in help for ShellExecuteEx I specify "runas" in the lpverb member of SHELLEXECUTEINFO structure which is passed to ShellExecuteEx(LPSHELLEXECUTEINFO lpExecInfo).
For msi I specify following values for lpFile and lpParameter members of SHELLEXECUTEINFO structure
lpFile ->       c:\windows\system32\msiexec.exe
lpParameters ->  /i D:\Pkgs\Flash.msi -q

For exe the parameters I provide are as below:
lpFile ->       c:\Test\Test.exe
lpParameters -> <empty>

For msi the error that occurs is 1603 (Fatal error during installation.)
Where as, exe runs fine (looking in the task manager).

Yes, but when you specify the "runas" for the lpverb member, you cant pass it the user password, it requires manual input.

You can only specify the user name in the command line for runas and not the password. When the runas command starts it wants the password for the user credentials you supply and this fires up a pop-up box which then breaks the installation, Example :
runas /noprofile /user:administrator ""C:\Program Files\Microsoft Office\OFFICE11\WINWORD.EXE""

Runas cannot accept the user-password for the credentials on the commandline, so when your service executes the above it does the following : "runas c:\windows\system32\msiexec.exe  /i D:\Pkgs\Flash.msi -q"
Try entering the above on a command line and watching what happens to verify this.

Even if you modify the above line to look like : "runas /user:myuser c:\windows\system32\msiexec.exe  /i D:\Pkgs\Flash.msi -q"

It will still fail to work because there is no password for "myuser", and it can't be entered on the command line.

A similar example of what you are seeing is here :
http://www.dotnet247.com/247reference/msgs/35/178421.aspx
From the above forum :
----------snip-------------------
I am using ShellExecuteEx with "Runas" verb with declarations
appended. ShellExecuteEx succeeds, but when used with
lpVerb = "runas", the Run as dialog appears, but application (notepad.exe)
does not display, but shows in the TaskManager (W2k).
 ----------------snip----------------------

Your test.exe "looks" like it is running but it isnt. What is happening is that the shellexecute process has created a stub and called it test.exe under IT'S process (runas). It isnt really running yet, it is waiting for the user password to be entered.

Ok. You are right that if we use "runas" verb we will be prompted for the username/password. But what if we don't specify "runas". An exe which can run in quiet mode is executed properly. This exe copies a file to "program files\test" folder and makes a registry entry.
But for the msi, ShellExecute simply fails with error 1603.
What could be the reason for this behaviour? I expect the msi to run properly as it is run by the service which has Full Rights.

Ok, I guess I have a solution for this. In addition with the servce I also have a UI component running so the task of execution will be done by the UI rather than the service.
This should solve my problem.
I must mention that the information provided by Shakti109 has been useful for me.

Thanks,
Sachin