Execute Program From Destination
I routinely call batch files and customized exe files using the 'Execute Program From Destination' with no problems, however in this instance it won't seem to work. I have packaged all the installation files into an MSI and execute the pre-made 'Setup.EXE' in silent mode as a custom action. The problem is that the 'Setup.exe' always bombs out because you can not have two instances of the Windows Installer Service running simultaneously, the MSI file and the 'Setup.exe' file. As a work around I've added a RunOnce key that calls the 'Setup.exe' file, so that on reboot it installs silently just fine. But I'd like to avoid having to log out and log in if possible. Does anyone know how to call an installation EXE from within an MSI? Do I need to move the action to 'Execute Deferred'? I have called an MSI from within an MSI before, but never an installation EXE.
Thanks for your help.
Thanks for your help.
0 Comments
[ + ] Show comments
Answers (1)
Please log in to answer
Posted by:
jbonbright
19 years ago
I'm guessing the Setup.EXE is itself a "wrapper" script for an MSI. If you extract files from Setup.EXE (i.e. by starting the install but not finishing it and searching for any new MSIs copied down to your box), I'm betting an MSI is called by the Setup.EXE "script."
Anyway, I've never been able to create a "wrapper" MSI that executes an EXE that wraps an OEM MSI. Somebody correct me if I'm wrong, but I think it's a limitation or design feature of Windows Installer. What I've done in your situation is either 1) create a repackage of the OEM MSI *where possible* (which many folks here strongly feel is a bad idea) or 2) do what you describe, which is create an AutoAdminLogon (AAL) process with the Setup.EXE in RunOnce.
For the latter situation, I might suggest something that will eliminate your having to reboot. I use a great little free utility called "cpau.exe," a RUNAS replacement. Get it here: http://www.joeware.net/win/free/tools/cpau.htm. Like runas, it allows you to run a process under another account's context, but unlike runas it allows you to pipe in a password on a command line. I actually posted a snippet regarding this utility in this forum the other day, but here's the gist of it:
======================
Here's how you would use cpau.exe to run regedit as local administrator on a local machine named \\computer with the password "password":
cpau –u computer\administrator –p password –ex regedit.exe –profile
======================
In this situation, you'd simply execute the Setup.EXE instead of regedit.exe using cpau. It works great and I use it situations like this. Keep in mind that this utility only works on systems that support RUNAS - i.e. Win2K, XP, and Win2003.
It will NOT work on NT, though there's a utility for NT that you can use to log off instead of rebooting, thereby saving a lot of time, particularly if your AAL scripts, like mine, require two reboots (actually log-offs now) - one to log off and then back on into the Auto Admin account, then a second one to log off of that AAL account after the install is finished. That utility is called ExitWindows.exe and is also freeware/donateware and is available at http://www.optimumx.com/download/. Basically, instead of using shutdown.exe to reboot the system, you'd use ExitWindows to log off. Of course, if you've set up the auto admin logon stuff correctly, as soon as you log off, the system will then log back in using the AAL account. You'd run your Setup.EXE, kill the AAL registry keys, then use ExitWindows to log off the second (and final) time.
Finally, a Wise contractor told me the best place to execute scripts or other executables is from Execute Deferred, not Execute Immediate. I put my "Execute Program (or Wise Script) from installation" command right above the last remark on that script tab and have never had any issues.
Anyway, I've never been able to create a "wrapper" MSI that executes an EXE that wraps an OEM MSI. Somebody correct me if I'm wrong, but I think it's a limitation or design feature of Windows Installer. What I've done in your situation is either 1) create a repackage of the OEM MSI *where possible* (which many folks here strongly feel is a bad idea) or 2) do what you describe, which is create an AutoAdminLogon (AAL) process with the Setup.EXE in RunOnce.
For the latter situation, I might suggest something that will eliminate your having to reboot. I use a great little free utility called "cpau.exe," a RUNAS replacement. Get it here: http://www.joeware.net/win/free/tools/cpau.htm. Like runas, it allows you to run a process under another account's context, but unlike runas it allows you to pipe in a password on a command line. I actually posted a snippet regarding this utility in this forum the other day, but here's the gist of it:
======================
Here's how you would use cpau.exe to run regedit as local administrator on a local machine named \\computer with the password "password":
cpau –u computer\administrator –p password –ex regedit.exe –profile
======================
In this situation, you'd simply execute the Setup.EXE instead of regedit.exe using cpau. It works great and I use it situations like this. Keep in mind that this utility only works on systems that support RUNAS - i.e. Win2K, XP, and Win2003.
It will NOT work on NT, though there's a utility for NT that you can use to log off instead of rebooting, thereby saving a lot of time, particularly if your AAL scripts, like mine, require two reboots (actually log-offs now) - one to log off and then back on into the Auto Admin account, then a second one to log off of that AAL account after the install is finished. That utility is called ExitWindows.exe and is also freeware/donateware and is available at http://www.optimumx.com/download/. Basically, instead of using shutdown.exe to reboot the system, you'd use ExitWindows to log off. Of course, if you've set up the auto admin logon stuff correctly, as soon as you log off, the system will then log back in using the AAL account. You'd run your Setup.EXE, kill the AAL registry keys, then use ExitWindows to log off the second (and final) time.
Finally, a Wise contractor told me the best place to execute scripts or other executables is from Execute Deferred, not Execute Immediate. I put my "Execute Program (or Wise Script) from installation" command right above the last remark on that script tab and have never had any issues.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.