msi runs in uninstall mode when CA fails
Posted 10 May 2010 - 07:51
I got a very strange and weird problem while deploying my msi using SCCM. Here are the details of my msi:
MSI:
There are three Custom action:
1. CAI: Immediate mode CA which runs only in "NOT REMOVE" condition. (Type 1)
2. CAU: Immediate mode CA which runs only in "REMOVE" condition. (Type 1)
3. CAD: Deferred mode CA which runs with no condition. (Type 1025)
Deployment using SCCM:
The msi is deployed in silent mode through SCCM in the user context. The msi logs are created in %temp% folder of the logged in user. Custom actions makes its log in %temp% also.
When the deferred custom action fails, the msi is run in uninstall mode and the REMOVE mode immediate CA runs as well as the deferred mode CA. However, in msi logs, there is no indication of launching msi in uninstall mode. This behavior is quite weird and cannot be reproduced when we try to install the same msi on the local machine in silent mode. The uninstall mode running of msi is detected by the CA logs in %temp% folder. The overall workflow of msi is:
1. CAI runs and succeeds
2. CAD runs and fails
3. CAU runs and succeeds
4. CAD runs and fails
Has anyone also faced the same issue? Can anyone provide any reason for this behavior.
Thanks..
Posted 10 May 2010 - 11:33
Edited by VBScab, 10 May 2010 - 11:33.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
Posted 10 May 2010 - 12:32
QUOTE (VBScab @ 2010-05-10 11:33) |
What context is the deferred CA set to execute in, User or System? If the former, does the user account have sufficent privileges to complete the action? If the latter, is it perhaps trying to do something user-profile based? |
Hello,
In the summary information stream, i have set the privileges required to be "Administrative".
This problem is arising when we try to install the msi using SCCM in the user context. When msi is deployed in system context using SCCM, the deployment goes as expected.
Posted 10 May 2010 - 12:52
Find the CA in the 'CustomAction' table. What value do you have in the 'Type' column for the CA?
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
Posted 10 May 2010 - 13:20
QUOTE (VBScab @ 2010-05-10 12:52) |
The SI stream is irrelevant, I'm afraid. Find the CA in the 'CustomAction' table. What value do you have in the 'Type' column for the CA? |
The value is 1025 for deferred mode CA.
And the value is 1 for both immediate mode CA.
Posted 10 May 2010 - 14:21
So it's a call to a DLL function running in user context. Change '1025' to '3073' (which changes it to execute in System context) and re-test.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
Posted 10 May 2010 - 15:34
QUOTE (VBScab @ 2010-05-10 14:21) |
What a twerp I am: you already told us that So it's a call to a DLL function running in user context. Change '1025' to '3073' (which changes it to execute in System context) and re-test. |
All right. I am testing that now. But the problem is that the immediate mode Custom actions also get executed when the deferred mode CA fails.
However, I did another test by creating an msi and inserting two immediate mode CA. One with "NOT REMOVE" condition (for install mode running) and another with "REMOVE" condition (for uninstall mode running).
The install mode CA is made to fail every time. And the same problem arises. When the msi is deployed in user context through SCCM, both the CA gets executed.
The type of both CA is 1.
Posted 10 May 2010 - 15:58
QUOTE (saurabhgupta1403 @ 2010-05-10 15:34) |
But the problem is that the immediate mode Custom actions also get executed when the deferred mode CA fails. |
You need to understand the difference between these two modes. I'll leave that to you to research. MSDN is a good place to start.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
Posted 10 May 2010 - 17:00
QUOTE (VBScab @ 2010-05-10 15:58) | ||
|
What i mean by that statement is that when a custom action in deferred mode fails, the msi runs the uninstall mode immediate custom action also which is a weird behavior. As far as i know, even in rollback mode, the immediate custom actions never gets executed.
Posted 01 June 2010 - 17:58
In general, the logical value of a property that has been set is true.
So i am guessing by default REMOVE will have a value, irrespective of whether it is an install or uninstall. Hence the conditions might be evaluating to true.
So probaly REMOVE=ALL should ensure that the action runs only during an uninstall. Have you tried this?
Regards,
Kiran Hegde
Posted 01 June 2010 - 18:01
QUOTE (kirann_hegde @ 2010-06-01 17:58) |
Probably you should use conditions such as REMOVE=ALL. In general, the logical value of a property that has been set is true. So i am guessing by default REMOVE will have a value, irrespective of whether it is an install or uninstall. Hence the conditions might be evaluating to true. So probaly REMOVE=ALL should ensure that the action runs only during an uninstall. Have you tried this? Regards, Kiran Hegde |
I have tried this method also and the result is same. The more weird behavior is that with other SCCM servers, this behavior is not reproducible at all while with others, this is reproducible when msi is run in system context also.
I tried three different SCCM servers and different msi but with no resolution to this problem.
Posted 01 June 2010 - 18:05
Regards,
Kiran Hegde
Posted 02 June 2010 - 12:47
Just keep in mind that REMOVE="ALL" is only valid after the InstallValidate action in the execute sequence. So are your actions sequenced with this in mind?
Also after building your msi, did you happend to inspect the custom action table using orca?
Regards,
Kiran Hegde
Posted 08 June 2010 - 09:00
QUOTE |
When the deferred custom action fails, the msi is run in uninstall mode |
Stefan Krüger
InstallSite.org twitter facebook
Posted 13 July 2010 - 09:39
QUOTE (Stefan Krueger @ 2010-06-08 09:00) |
Note that rollback is different from uninstall. |
Hi Stephan,
Sorry for my late reply. Yes, uninstall is different from rollback. What happens is that after the CA fails, the msi rolls back and in msi logs the transaction ends. But in our CA logs, we can see that the immediete mode CA with REMOVE condition is also getting executed after that. And then the deferred mode CA gets executed for second time.
We have filed a bug with microsoft for this issue and they are able to reproduce to the issue also. But the reason is yet to be discovered.
Posted 13 July 2010 - 10:20
Stefan Krüger
InstallSite.org twitter facebook
Posted 13 July 2010 - 10:55
QUOTE (Stefan Krueger @ 2010-07-13 10:20) |
Please post back once Microsoft figured out why this happens. |
Sure.... Also, if anyone has access to SCCM, he/she can try to generate this issue at their end. More findings to this problem is that with some SCCM server, this issue is occurring only when msi is pushed in user context (means msi will run with logged in user priviledge) and with some SCCM servers, it is occurring every time.
Quite weird but true.
Posted 23 July 2010 - 05:27
QUOTE (grewxaa @ 2010-07-23 03:59) |
there is no indication of launching msi in uninstall mode. |
The only indication of msi running in uninstallation mode is through the custom action logs. In custom logs, we get to know that the msi got executed in uninstall mode. We got both immediate as well as deferred mode CA logs in uninstall mode. It shows that msi was executed in uninstall mode after installation failure.
Posted 25 August 2010 - 14:55
Finally the microsoft Msi team has found the reason for this behavior. When msi is deployed via SCCM and it fails, the advertisement of msi rolls back and according to them, it is the desired behavior of SCCM to launch the msi in remove mode when the advertisement is getting uninstalled.
So, i need to modify my custom action conditions so that they don't get executed in case of advertisement roll back. This we have found by the condition that the feature of our msi is in advertised state or not.
Strange but this is the behavior of SCCM.