Share via

UAC in MSI Notes: How do I get one credential dialog for a multiple package install?

  • Article

This is the twenty-fifth in a series of notes about UAC in MSI. Per the earlier caveat, these are just my notes and not an official position from the Windows Installer team. The previous entries

  1. Introduce...
    1. ...the UAC in MSI Notes series
    2. ...my view of the root problem
    3. ...the conflicting per-user definition
    4. ...it'll be just like Managed Installs
    5. ...the jagged edge to user
    6. ...my relief providing framework
  2. Architecture Insights
    1. The "Saw Tooth" Diagram
    2. Credential Prompt and Permissions
  3. Common Package Mistakes
    1. The AdminUser Mistake
    2. Modify System with InstallUISequence Custom Action
    3. Modify System with InstallExecuteSequence Custom Action Outside of Script
    4. The NoImpersonate Bit Mistake
  4. More Architectural Insights
    1. My "Four Square" Diagram
    2. Challenges for a Beautiful Custom Action
    3. O Whitepaper, Where Art Thou?
    4. Read the Friendly Manual
  5. Conversations with Customers
    1. Should I write my installer as a Standard User install? If yes, how?
    2. When General Custom Action Mitigation Fails
    3. How do I get the shield on the advertised shortcut?
    4. How do I troubleshoot UAC in MSI via the log?
    5. Do I need to consider "this" when I'm designing for UAC in MSI? Generally, no.
    6. Is "this" intentional? If so, why?
    7. How to Build Packages that work for both Standard User and Per-Machine?
    8. Easier for my current custom installer to support UAC than switch to MSI?

This entry continues a section specifically focused on Question and Answers that often come up in the UAC in MSI dialogs. For this entry the topic is: how do I get one credential dialog for a multiple package install?

One Credential Dialog for a Multiple Package Install

One of the increasingly common behaviors seen in the market is building up an install from a set of two or more packages. Producers of the multiple package installs note that with our default guidance, their user will need to provide credentials multiple times. This can be a non-ideal experience particularly if one is concerned about credential fatigue.

The recommend solution here is to have two bootstrappers, one inside the other. The external bootstrapper would have an application manifest with requestedExecutionLevel at asInvoker and the internal bootstrapper would have an application manifest with requestedExecutionLevel at requireAdministrator.

 
Setup.exe (with asInvoker)
 -> InternalSetup.exe (with requireAdministrator)
    + msiexec /jm <path to MSI 1>
    + msiexec /jm <path to MSI 2>
    + msiexec /jm <path to MSI 3>
 <-
 + msiexec /i <path to MSI 1>
 + msiexec /i <path to MSI 2>
 + msiexec /i <path to MSI 3>

The external bootstrapper calls the internal bootstrapper which displays the elevation prompt then advertises all the applications in the package. The external bootstrapper returns to the internal bootstrapper and the internal bootstrapper then completes the installs in the users context. The reason to run the advertising first followed by the user install is to ensure the user context is correctly initialized for any user specific settings that may be in the package. If user context is not properly considered the Over The Shoulder case will result in the parent receiving the user context from an install intended for the child.

Comments