I have two installers. One is a Client, and one is Management console.
The packaging strategy is make available to the customer the Management Console, and package the .msi for the client into it. After the Management piece is installed, the customer will then push the client .msi out onto systems in their enterprise via Group Policy.
Problem:
When the customer installs the Management console application they must be given the option to install the client onto the local machine as well (the client .msi is always put onto the machine with the Management Console, but it is not always run there... that's the optional piece).
Rather than being redundant and including all of the client files and install logic (as was done in the past by the last person who worked on the install), I would like to simply call out to the client .msi (silently) if the user chooses to put the install the client on the local system. This is really a convenience, and the end result should be two separate entries in Add/Remove programs.
How can I make this call out to client .msi? It sounds like a "nested .msi" will not give me the desired result of having a separate entry for the client piece, and I've seen lots of things about this being deprecated, etc...
Since you can't run two .msi instances simultaneously, one thought I had was to put an entry into the registry under "RunOnce" so the client would be installed after the next reboot. Another idea was to schedule the install for a few seconds after the first install finishes.
Also, I'd like to call out to the client .msi that I'm putting onto the target system anyway. When I looked at using "Nested .MSI", it seems to want to bundle the client .msi into the Console .msi, even though the client .msi is already in there.
Any ideas? I'm in a time crunch here, so I really need to get this done quickly.
Usually, the simplest way of installing a second MSI package from another is to use an executable custom action. An EXE (path referencing a directory) action can launch msiexec.exe with the following arguments: /I "\PathToMsi\MsiPackage.msi"
The path to the MSI package would likely be stored in a property (for example, [SUPPORTDIR] if the MSI was extracted at runtime by using the Support Files view).
This action would need to be sequenced in the install UI sequence (any point after CostFinalize; after SetupProgress if the action condition is dependent upon user interface selections).
joshstechnij wrote: Usually, the simplest way of installing a second MSI package from another is to use an executable custom action. An EXE (path referencing a directory) action can launch msiexec.exe with the following arguments: /I "\PathToMsi\MsiPackage.msi"
The path to the MSI package would likely be stored in a property (for example, [SUPPORTDIR] if the MSI was extracted at runtime by using the Support Files view).
This action would need to be sequenced in the install UI sequence (any point after CostFinalize; after SetupProgress if the action condition is dependent upon user interface selections).
Thanks Josh, makes sense, I'm under time pressure here, so I wasn't thinking about the obvious fact that msiexec is an executable... it would have hit me eventually 😉
