What's the mechanism of handling the multi-msi issue

[victeur]

Hi, we do want to use your product. would you please tell us the mechanism how Installaware handle the multi-msi installation, nested or concurrent?thanks!

[Alex_Ronquillo]

This is handle via the Windows Installer 4.5 plug-in for IA. Please read http://www.installaware.com/news-msi-45.htm for more information

[Gizm0]

IF you don't want to use a beta software, you can simply nest the application with multiple IF statements and use (Un)Install MSI plugin to install them one by one.

[Justin Pava]

I've actually been trying to setup a nested installation where one installaware package installs an additional one as well. And, well, somethings just not working for me. I don't want to use beta software, so I'm really trying to get this to work. I'm sure I'm missing something obvious, so i'll just try to list what I'm trying to do and hopefully someone spots the problem?

The first installation package is pretty basic - just a collection of merge modules really. It's a single file web install (all offline content) and it installs fine if I just run the package by itself manually.

I used the 'group policy wizard' to covert that package into an msi file for the purposes of nesting it. I didn't set any parameters there (maybe that's missing?), just outputted as the same name, only now as .msi.

In my other install (which is also a pretty simple offline content web install, mostly of merge modules), I added the Install/Remove MSI Package line, pointing to $SUPPORTDIR$\\<PackageName>.msi. ADDLOCAL=ALL is the 'action string'. I've checked that it's an installAware generated install, and I've set it to log the install. This is placed immediatly before the main 'Apply Install' line in the second installation.

When I run the second installation, the log from the first (nested) install is created, so something ran. However, none of the files are installed, and the item does not show up in add/remove programs (which was my impression of what would happen if we don't use the beta version). The installation itself THINKS it runs (it returns 'success' to the main install, and the log file doesn't show explicit errors), but the files don't actually get installed. Also, this is the log file text for the 'installFiles' section (in the nested install log):

MSI (s) (64:6C) [17:09:48:051]: Doing action: InstallFiles
MSI (s) (64:6C) [17:09:48:097]: Note: 1: 2205 2: 3: ActionText
Action start 17:09:48: InstallFiles.
MSI (s) (64:6C) [17:09:48:207]: Note: 1: 2205 2: 3: Patch
MSI (s) (64:6C) [17:09:48:269]: Note: 1: 2228 2: 3: Patch 4: SELECT `Patch`.`File_`, `Patch`.`Header`, `Patch`.`Attributes`, `Patch`.`Sequence`, `Patch`.`StreamRef_` FROM `Patch` WHERE `Patch`.`File_` = ? AND `Patch`.`#_MsiActive`=? ORDER BY `Patch`.`Sequence`
MSI (s) (64:6C) [17:09:48:301]: Note: 1: 2205 2: 3: Error
MSI (s) (64:6C) [17:09:48:363]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1302
MSI (s) (64:6C) [17:09:48:472]: Note: 1: 2205 2: 3: MsiSFCBypass
MSI (s) (64:6C) [17:09:48:582]: Note: 1: 2228 2: 3: MsiSFCBypass 4: SELECT `File_` FROM `MsiSFCBypass` WHERE `File_` = ?
MSI (s) (64:6C) [17:09:48:629]: Note: 1: 2205 2: 3: MsiPatchHeaders
MSI (s) (64:6C) [17:09:48:691]: Note: 1: 2228 2: 3: MsiPatchHeaders 4: SELECT `Header` FROM `MsiPatchHeaders` WHERE `StreamRef` = ?
Action ended 17:09:48: InstallFiles. Return value 1.

That's it. (Don't recall if something SHOULD be there - it's a while since I've debugged msi logs. Regardless, the files/modules that ARE supposed to be installed are not to be found in the log).

Even STRANGER (from my perspective), I went ahead and installed the original single exe web package of the nested install on my test machine - it went through fine, so I uninstalled, verified that it cleaned everything, and then tried my nested one again (actually, to get the log info to write this post up). This time everything went through fine. It looks like it FOUND the package from when it had been installed itself and pulled the files from it. Which is fine, but it kinda defeats the point of the nested install to require that the package have been installed locally at some point.

So, it seems to me that all the code is set up right in general (as in, it actually runs)... but it's not actually finding anything inside the nested install to actually, you know, install.

Any thoughts? What am I doing wrong? :->

(Sorry about the VERY long explanation... figured that works better then trying to abbreviate and leaving out the important bit).

[ddebono]

Hi,

This is a known serious bug in IA that makes it useless when it comes to nested MSI's and GPO/SMS rollout.

IA has no idea of when/if they are going to fix this.

[Justin Pava]

I... see.

That's a bit disconcerting to hear. I actually was pursuing nested installations as a workaround to not being able to install merge modules conditionally (as I discussed in this thread: http://www.installaware.com/forum/viewtopic.php?t=2938). Since we have a number of components (that are also their own packages) in a main installation that need to be selectively installed based on install-time license checks or user selections, we need SOME way to conditionally install these other components (without, you know, having to make multiple copies of installations for them).

Ok, I hear conditional merge modules just isn't supported and I need to use nested MSI's. But now nested msi's don't work either? That's... well, like I said. A bit disconcerting. Since I keep being told to use nested msi's, I assume it's SUPPOSED to work, but there's some current bug with it or something? Could you elaborate, or link to something that discusses this? (I did try some forum searches, but kept getting people trying to run group policy created msi's by hand which seemed to be something else)

[Gizm0]

Bug only exists on GPO/SMS rollout cases and it's random. It does not affect other types of installations. If it was affecting them, prerequisities where not going to work either, but they work ok. As i said, it only exists on GPO rollout packages. It's going to be fix on InstallAware's next version.

[Justin Pava]

Hmm....

Gizm0, I'm using a GPO nested installation becuase I was under the impression that to use the 'install/uninstall MSI installation' command (and therefore get the benefit of, say, the progress getting incorporated into the main progress bar), the package had to explicitly be a .msi installation package - and that GPO was the only way to generate that (In which case, this 'random' bug would be present anytime I'm trying to nest one IA installation package within another?). Is that not the case?

Is there another way to nest one IA package in another and still get the benefits of using this 'install/uninstall MSI installation' command (as opposed to, say, 'run program' which presumably just launches it completely independent)?

[Justin Pava]

Update: Just stumbled along http://www.installaware.com/forums/viewtopic.php?t=3154 (whoops, didn't think to check the presales forum :-/ ). From that post, it looks like you just CAN'T use 'Install/Uninstall MSI Installation' with another generated Install Aware installation, you'd have to just use 'run programs'. I guess I can go ahead and give it a try for non-Install Aware generated msi's (since we've got a few of those too...)

[ddebono]

Hi Gizmo,

The bug also happens when calling IA MSI's in a installation.

The reason being that IA MSI's is giving control back to the calling application before the MSI is finished and therefore the next MSI will exit in error because a MSI is already in progress.

When calling IA EXE installations it works OK.

David