Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

LaunchConditions Question


8 replies to this topic

sjimmerson

sjimmerson
  • Members
  • 36 posts

Posted 01 September 2005 - 21:39

We ran into an issue with Active Directory deployment where our installations would fail because the LaunchConditions get run in both the UI and Execute sequence and some of the public properties being used by the LaunchConditions were set by custom actions that were only run in the UI sequence (e.g. - AppSearch). Since public properties are not reused/transferred from the UI sequence to the Execute sequence unless the public properties are listed in the SecureCustomProperties property, the LaunchConditions failed in the Execute sequence.

I see two solutions to this issue.

1. Don't run the LaunchConditions if the UI sequence is run by setting a condition on the LaunchConditions in the Execute sequence like so: "Not Installed And (UILevel = 2 Or UILevel = 3)". Is there any particular reason the LaunchConditions are run in both sequences? Is there any downside or pitfalls to this solution?

2. Add the public properties used by the LaunchConditions to the SecureCustomeProperties property.

Seems to me like the first option would be better because you wouldn't have to remember to add a public property to the SecureCustomProperties property if you add more LaunchConditions. Am I missing something? Are there any other options?

Thanks,
Shane

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 01 September 2005 - 22:53

Why don't you run this particular CA in both sequences?
BTW All public properties are transferred from UI to execute sequence. You would use the SecureCustomProperties property to prevent anyone setting this option on the command-line.

sjimmerson

sjimmerson
  • Members
  • 36 posts

Posted 02 September 2005 - 21:59

Actually, when deploying via Active Directory(AD)/Group Policy, public properties are not transferred from the UI to the execute sequence.

In deployment scenarios you will see entries like the following indicating that the public properties are not transfered from the UI to the Execute sequence:

MSI (s) (74:60): Running product '{B2B46DC0-3C43-46B2-8EE3-DC9386E0A9F4}' with elevated privileges: Product is assigned.
MSI (s) (74:60): Machine policy value 'EnableUserControl' is 0
MSI (s) (74:60): Ignoring disallowed property WINDOWS_NT
MSI (s) (74:60): Ignoring disallowed property ACCESSORIES
MSI (s) (74:60): Ignoring disallowed property INSTALLDIR
MSI (s) (74:60): Ignoring disallowed property ADDINS
MSI (s) (74:60): Ignoring disallowed property MICROSOFT
MSI (s) (74:60): Ignoring disallowed property ADDINS1
MSI (s) (74:60): Ignoring disallowed property TARGETDIR

The LaunchConditions and AppSearch custom actions are built-in MSI actions.

Thanks,
Shane

Edited by sjimmerson, 02 September 2005 - 22:38.


Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 02 September 2005 - 23:52

I believe the SecureCustomProperty values specifies a delimited list of public properties that ARE to be passed from client to server process when run in restricted environments. I don't think it has anything to do with specifying values of public properties in the command line.

As such you may be able to add all the public properties you need to the SecureCustomProperty list to ensure you have the property available in both sequences. Private properties are never available in both sequences (unless you run on Win9x where there only is one process - and it is a client process).
Regards
-Stein Åsmul

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 05 September 2005 - 15:25

I would recommend adding the custom action to the execute sequence, too. Otherwise your setup may fail in silent mode, because the UI sequence is completely skipped in this case.

sjimmerson

sjimmerson
  • Members
  • 36 posts

Posted 07 September 2005 - 17:09

There seems to be some confusion (at least on my part)...

AppSearch and LaunchConditions are Standard Actions. We are using AppSearch to set some public properties that are used in the LaunchConditions. By default (at least with DevStudio 9) both AppSearch and LaunchConditions standard actions are listed in both the UI and execute sequences. The AppSearch standard action is run only once even if both the UI and Execute sequences are run. On the other hand, the LaunchConditions standard action is run twice if both the UI and Execute sequences are run. Based on this information, the installation runs fine in basic or none UI modes, but fails in reduced or full UI modes because the public properties that the LaunchConditions rely on are not passed from the UI to the Execute sequence and the AppSearch standard action is not run in the Execute sequence because it has already been run in the UI sequence.

There aren't any conditions that I can find on the AppSearch standard action that limit it to only running once, so is the MSI installation engine limiting this or am I just missing something?

I understand that I can add the public properties to the SucureCustomProperties property to pass these public properties from the UI to the Execute sequence. To me the downside to this is if the LaunchConditions standard action needs to check additional/new public properties in the future the install develper also has to remember to add those public properties to the SecureCustomProperties property.

Is there any reason you can think of that I should not limit the LaunchConditions standard action to only run in the UI sequence if the installation is run in reduced or full UI modes? It would still be run in the Execute sequence when the installation is run in none or basic UI modes.

Thanks,
Shane



Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 07 September 2005 - 20:34

Sorry, didn't notice you were using AppSearch. What I said assumed you are using a custom action.

You are right, AppSearch will not run in the execute sequence agai if it has already run in the UI sequence.
You can condition the LaunchConditions action in the execute sequence to run only in basic or none ui modes.

sjimmerson

sjimmerson
  • Members
  • 36 posts

Posted 08 September 2005 - 18:08

Stefan,

Thanks for the information. I didn't think it would be a problem conditionalizing the LaunchConditions, but I wanted to get some confirmation since I don't understand why the LaunchConditions are run in both the UI and Execute sequences in reduced and full UI modes in the first place. Do you know why the LaunchConditions are run twice?

Thanks,
Shane

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 14 September 2005 - 09:11

QUOTE
Do you know why the LaunchConditions are run twice?

No, I don't know.