Create self-extracting installer from 3 pre-existing windows MSI files
Greetings and thank you for a moment of your time,
THE REQUEST:
I've got 3 pre-existing MSI files, which I did not create. I just want to chain them into a compressed self-extracting archive, which then kicks them off automatically in the correct order. Ideally, I just email them the link, and it's pretty automated from there, with the exception of the Wizards resultant from the MSI packaging.
FORMAT:
This is unimportant. The single file I send them a link to, might as well be an exe, zip, or whatever, as long as it will self-extract automatically on Windows XP Professional, with as few clicks as possible, and begin the installation automatically (of the 3 MSI files).
CAVEATS:
I'm not allowed to deploy these MSI's via GPO (my preferred method, and much easier too!), so in the meantime, I'm trying to find a simple method to avoid confusing my customers, or frustrating them. Fewer mouse clicks is the goal here. Having them download them individually, then find the location, and kick them off one at a time, is like pulling teeth.
TOOLS:
I've got Winrar, but I'm not opposed to Alzip, 7-zip, Inno, etc., whatever is easiest and works.
THANK YOU :-)
THE REQUEST:
I've got 3 pre-existing MSI files, which I did not create. I just want to chain them into a compressed self-extracting archive, which then kicks them off automatically in the correct order. Ideally, I just email them the link, and it's pretty automated from there, with the exception of the Wizards resultant from the MSI packaging.
FORMAT:
This is unimportant. The single file I send them a link to, might as well be an exe, zip, or whatever, as long as it will self-extract automatically on Windows XP Professional, with as few clicks as possible, and begin the installation automatically (of the 3 MSI files).
CAVEATS:
I'm not allowed to deploy these MSI's via GPO (my preferred method, and much easier too!), so in the meantime, I'm trying to find a simple method to avoid confusing my customers, or frustrating them. Fewer mouse clicks is the goal here. Having them download them individually, then find the location, and kick them off one at a time, is like pulling teeth.
TOOLS:
I've got Winrar, but I'm not opposed to Alzip, 7-zip, Inno, etc., whatever is easiest and works.
THANK YOU :-)
Vadim Rapp
I would create SFX file in Winrar, with the 3 MSI's inside, plus vbscript or .cmd that would run the msi's in the correct order, and since you don't want the dialogs, with switch /qb . You then specify that script in SFX options under "run after extraction".
You can try the windows built in tool here:
http://lifehacker.com/384658/use-a-built+in-windows-utility-to-create-self+extracting-archives
http://lifehacker.com/384658/use-a-built+in-windows-utility-to-create-self+extracting-archives
ASKER
Deisrobinson,
Thank you for the suggestion, I will keep that on the burner for now.
Vadimrapp1,
I've never included a vbscript like that before, because I've never put multiple files in like this, which need to be kicked off in order (I'm assuming you've used vbscript in similar cases). Can you give me a link or some of the basic lines of vbscript I'd use in that scenario? Would the script need to kick off one of the msi files, then wait somehow, for some amount of time, or maybe a prompt, before moving to the 2nd, and then 3rd?
thanks so much!,
~k
Thank you for the suggestion, I will keep that on the burner for now.
Vadimrapp1,
I've never included a vbscript like that before, because I've never put multiple files in like this, which need to be kicked off in order (I'm assuming you've used vbscript in similar cases). Can you give me a link or some of the basic lines of vbscript I'd use in that scenario? Would the script need to kick off one of the msi files, then wait somehow, for some amount of time, or maybe a prompt, before moving to the 2nd, and then 3rd?
thanks so much!,
~k
See article "Run Method (Windows Script Host)" ( http://msdn.microsoft.com/en-us/library/d5fk67ky%28VS.85%29.aspx ) for details; it has an example. As you can see, there's parameter bWaitOnReturn, so each line will wait for completion before moving to the next one.
Each command to run would be msiexec.exe /qb /i package1.msi .
The command to run vbscript itself would be wscript.exe myscript.vbs (run wscript /? to see all parameters).
With Installer 4.5, there's also an interesting possibility to run all 3 installations as one transaction, so if one fails, others rollback as well. But creating the script providing that is more involved.
Each command to run would be msiexec.exe /qb /i package1.msi .
The command to run vbscript itself would be wscript.exe myscript.vbs (run wscript /? to see all parameters).
With Installer 4.5, there's also an interesting possibility to run all 3 installations as one transaction, so if one fails, others rollback as well. But creating the script providing that is more involved.
ASKER
Ok! I've got another ticket to help me if I run into problems with the VBscript now (I'm so lucky you two showed up to help me!)
Baring some problem with the script or my tests, I'll try to get this working (tested on VM's), and then report back soon (2 days max).
Thanks Vadimrapp1 & Deisrobinson so much!
Baring some problem with the script or my tests, I'll try to get this working (tested on VM's), and then report back soon (2 days max).
Thanks Vadimrapp1 & Deisrobinson so much!
ASKER
It doesn't seem to work with any variant of %dir% no matter how many quotes (including none at all). Note, that I also attempted other paths, such as: %HOMEPATH%\My Documents
ASKER
I also just attempted to run the vbscript directly -- aka, from a prompt:
\My Documents>wscript.exe installer.vbs
\My Documents>wscript.exe installer.vbs
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
triple quotes. that was it!
s.run "msiexec.exe /qb /i ""%temp%\test.msi"",1,True
I was modifying the quotes in all possible ways, other than the correct way:
s.run "msiexec /qb /i ""%temp%\test.msi""",1,tru
I'll retry the exe in the morning.
thanks :-)
s.run "msiexec.exe /qb /i ""%temp%\test.msi"",1,True
I was modifying the quotes in all possible ways, other than the correct way:
s.run "msiexec /qb /i ""%temp%\test.msi""",1,tru
I'll retry the exe in the morning.
thanks :-)
ASKER
I've got one last question.
When I'm at a cmd prompt, it doesn't seem to make any difference if I type:
>wscript.exe installer.vbs
or if I type
>installer.vbs
why type the wscript.exe?
When I'm at a cmd prompt, it doesn't seem to make any difference if I type:
>wscript.exe installer.vbs
or if I type
>installer.vbs
why type the wscript.exe?
To account for (very unlikely but not entirely impossible) case when filetype .vbs is associated not with wscript.exe but something else. In programming, the recommended practice is to always specify explicitly whatever can be specified.
Actually, I'd say, it's recommended not only in programming. The less assumptions, the better.
Actually, I'd say, it's recommended not only in programming. The less assumptions, the better.
ASKER
Just an FYI:
My reason for asking about the invocation of the vbscript by the use of (tell me if I say this the wrong way) by handing off the vbscript to the wscript object intentionally, is this:
In a sleep-deprived stupor last night (about 2 am), I found that I could compile the vbscript into an .exe and then create a nice little wizard that actually looks like a traditional installer using either:
http://www.bersoft.com/easysetup/
or
http://www.ssesetup.com
So I tested this, and sure enough, it works! These two programs above work for me (non-profit), and and far more simple than NSIS or INNO.
I'm was wondering if I should go back and try to change the file association in my test VM, for the vbs filetype, and then rerun. I probably will. But I already think (now) that this file name extension won't affect the vbscript being executed as part of my install exe, because when the vbs is compiled into an exe, the wsh object model is simulated somehow, as if all the classes and types are linked or pulled in somehow, and a sort of wsh is actually being used to run the vbs, in the same way that it would if I called wscript.exe from the command prompt as you have suggested I do.
I haven't learned this much in a single Q&A thread, in my entire life.
Thanks so much!
My reason for asking about the invocation of the vbscript by the use of (tell me if I say this the wrong way) by handing off the vbscript to the wscript object intentionally, is this:
In a sleep-deprived stupor last night (about 2 am), I found that I could compile the vbscript into an .exe and then create a nice little wizard that actually looks like a traditional installer using either:
http://www.bersoft.com/easysetup/
or
http://www.ssesetup.com
So I tested this, and sure enough, it works! These two programs above work for me (non-profit), and and far more simple than NSIS or INNO.
I'm was wondering if I should go back and try to change the file association in my test VM, for the vbs filetype, and then rerun. I probably will. But I already think (now) that this file name extension won't affect the vbscript being executed as part of my install exe, because when the vbs is compiled into an exe, the wsh object model is simulated somehow, as if all the classes and types are linked or pulled in somehow, and a sort of wsh is actually being used to run the vbs, in the same way that it would if I called wscript.exe from the command prompt as you have suggested I do.
I haven't learned this much in a single Q&A thread, in my entire life.
Thanks so much!
ASKER
I should clarify: I'm still using your vbscript (thank you). But now I'm using a nice install wizard with a "branded" splash screen I made, my own organizational icon, license agreement, readme, etc., all in a single .exe.
I'm going to do one more test tomorrow.
I'm going to do one more test tomorrow.
Actually, sfx in winrar that you mentioned in the very beginning also supports branded icon and license. Readme probably might be launched in the end either by the installation, or by yet another lince in the script.
ASKER
worked great, thanks so much!