Queueing Multiple IA Setups

[kpendergast]

I have a customer who is running multiple IA MSI packages (different products) in Group Policy and is getting conflict issues that he believe stems from one setup not completing before the prior setup has completed. Two questions:

1. Is there a way to explicitly instruct an IA MSI to wait until the others have finished?
2. Is there a "best practices" about queueing up multiple IA MSI packages?

Thank you.

Ken Pendergast
Levit & James, Inc.

[giaviv]

Dear Ken,

I can't think of a straight forward way to do that - how are the MSIs run?

[kpendergast]

Hi Aviv:

There are a number of MSI installs that are attached to an OU in the Group Policy Object. They are set at the Computer (i.e., not the User) level, so that the GPO initiates the installations at machine startup. In this case there are about 20-25 MSI installs that are performed, but only my 3 installs are IA MSIs built with the Group Policy Wizard.

Here's what happens:

When the GPO initializes, the first MSI (not IA) is executed. Once it has completed, the second MSI (also not IA) starts its execution. And so on down the order of MSIs. When the GPO reaches the IA MSI, the MSI starts execution but issues some sort of return code immediately and so the next MSI (also an IA MSI) initializes before the IA MSI has completed. It also issues a return code immediately and so the next MSI (also an IA MSI) is initiated. Now, because we have three IA MSIs all running simultaneously, they ALL FAIL.

The integrator ran a test detaching two of the IA MSIs from the OU and the single IA MSI now installs successfully, but there is still a problem. Because it returns before it has completed, the GPO actually completes before the IA MSI does. The IA MSI eventually finishes and the application runs OK.

So the question is, how do I configure the IA setup (and subsequent MSI) to tell everything else to wait until it has completed?

Thanks
Ken

[giaviv]

Dear Ken,

I am not sure if this is at all possible. The actual Windows Installer part runs and returns immediately when Apply Changes is called...

[kpendergast]

Aviv:

The only thing I know about this is that my IA MSIs are the only ones out of ~30 that are having this problem.

Ken

[giaviv]

Dear Ken,

In order to allow the flexibility, strength and customization ability that IA supports, our MSI's are different in some ways from other MSI's.
I apologize that this is causing you issues.

[kpendergast]

So what do you recommend on how to solve this problem?

Thanks
Ken

[kpendergast]

Could you please escalate this issue? This is a serious problem for our customer and they've been waiting for resolution. Please let me know if any more information is required.

Thank you
Ken

[giaviv]

Ken,

I checked and its not possible to work around the fact that IA generated MSI's return immediately when run.

[giaviv]

Dear Ken,

Furthermore, the reason that InstallAware Group Policy MSI's return immediately is because the outer MSI (the group policy MSI) holds a mutex locked and we cannot install the inner MSI (the real IA MSI) until that mutex is released. So the outer MSI runs the inner setup.exe (IA binary) which waits until the mutex is free. This will never cause conflicts among IA setups because they will all wait until the mutex is free, polling regularly. But if the moment they grab the mutex, another MSI setup is also being run (such as one queued by policy) than those setups may fail due to that mutex. Unfortunately, there is no way to work around this behavior. Do you have any suggestions how to improve the handling of this?

Thanks!