The Windows Installer service can only handle one installation at a time. If you think about it, how would you handle rollback if two installation threads were making changes at the same time - and possibly changing the same resources differently?

Microsoft Office applications are all in MSI format already, so you can use these directly.

The only way to "wrap" multiple MSI installs within a single MSI, and keep them independent, is to put them into the UI sequence, but this technique is no use if you intend to perform silent deployments.

The other technique, which even Microsoft do not recommend, is to use the special "nested" custom actions to install each MSI in the Execute Sequence. The downside is that you lose the ability to maintain or uninstall any of the nested MSI files independently - they can only be changed via an upgrade to the installing "parent" MSI.

If your intention is to deploy a configured version of One Note, then you should research the method of doing this using the built in Admin function to generate an MSP with your configuration details.

...Microsoft made it all but impossible to use the MSIs directly.

@OP, you need to create a patch (MSP) using the special '/admin' switch with your customisations and deposit that file into the 'Updates' folder. It's very well documented in the 'Package KB' and various posts on AppDeploy.com.

@EDT:

1. Yes , agree with your opinion regarding ROLLBACK. The reason behind saying: "Windows Installer Engine can handle only one msi at a particular instance" is , as whenever we try to install two different msi at a particular instance then the installer usually prompts or fails to continue further with the second installation.

2. No for Nested Installation.

3. I can't go for placing the action in UI sequence because of the deployment point of view- As said by you too.

4. I have already made a .MSP for the desired configuration(using /admin switch) but still i want the whole installtion to get trigerred from the msi taking into consideration the same can be achieved with the help of external vbscript or wisecript but as said earlier NO to wise and vb in this case.

@VBScab:

I have already created the .MSP using the admin switch for the desired changes but i want the whole installation to be handled using a msi rather callling the whole MS NOTE 2007 source from a msi and synchronously.

Thanks!

What you are asking for is nigh on impossible, as there is no easy way to install an MSI from another MSI without either using the UI sequence or using nested custom actions.

The only way I can think of is highly inelegant but if you have a customer who is too brainless to understand MSI technology is not the answer to 100% of all installation issues, then maybe you will want to try this method.

1. Create a Wisescript EXE that waits 30 seconds, then installs all your component files to a temp folder, runs the install and then cleans up and exits. The Wisescript should have logging turned off as the apps you are installing will make their own entries in Add/Remove programs. The Wisescript should also uninstall the MSI used in step 2. Finally the Wisescript should add an entry to the RUNONCE registry key that will delete the Wisescript EXE at the next reboot.

2. Package that EXE in your MSI, so that the EXE installs to the temp folder, and then run the EXE from a custom action placed after InstallFinalize, so that it runs after the MSI installer has completed all system changes and therefore is free for the next install.  This action needs to run in SYSTEM context to make sure it inherits the system permissions. Running in USER context will fail.

Running the MSI will therefore install your EXE, start the EXE, which waits 30 seconds to allow the MSI to complete, and then terminate. The EXE then installs the MSI and MSP and runs the install. It then cleans up by deleting the MSI and MSP, and uninstalling the wrapper MSI from step one. Finally it records the RUNONCE key so that the EXE is deleted at the next reboot, when it is no longer running.

Remember to test that the reboot allows the EXE to be deleted in case the TEMP folder does not have the right permissions (it should).

Plan B is to educate your client as the standard deployment systems all handle installs based on EXE and other non MSI techniques, as well as MSI files.

...that you're trying to do this via Group Policy, hence the "MSI Only" stipulation. Forget it.

Windows Installer 4.5's Installation Chaining capability is pretty neat.  You can store multiple MSI's inside of one wrapper .MSI and specify the installation order.  It does not suffer from the same downsides as "nested" MSI installations but, unfortunately, using it in Wise Package Studio is not going to be particularly easy.  But I hear that there's another packaging tool that supports it :)