Compartilhar via

UAC in MSI Notes: The AdminUser Mistake

  • Artigo

This is the ninth 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

This entry will talk about the first common mistake we found packages making with UAC in MSI: incorrectly using the AdminUser property in places that are evaluated in the client.

The AdminUser Mistake

The Windows Installer SDK has guided against the use of the AdminUser property in favor of the Privileged property.  Windows Installer also provided Internal Consistency Evaluator, ICE 86, to warn package providers of potential mistakes with AdminUser. Here's the whiteboard "saw tooth" drawing I use when trying to explain the problem in the context of the architecture.

 

With the permissions changes in the context of UAC, the AdminUser property would never be true. The Application Compatibility for this particular mistake was brutal so we needed a systematic solution.

Fake until the Service

To more systematically mitigate the application compatibility problem, we changed the default on Vista to make the AdminUser property follow the rules of the Privileged property. The Privileged property semantics fake the Privileged property in the UI sequence and correct for it in the execute sequence.  Morphing the AdminUser semantics into Privileged semantics fixed the majority of the application compatibility issues with legacy packages.

For new packages, we now advise that the LaunchCondition table no longer be used to test for AdminUser or Privilege, rather the package author write a type 19 custom action run in the Execute sequence only.

When Real AdminUser Value is Required

As the feedback from the customer preview programs noted there were cases where the use of AdminUser was intentional, we further added a MSIREALADMINDETECTION property to return the historical behavior of the AdminUser. The MSIREALADMINDETECTION property is expected to be set when a package has designed different UI behavior if the user is an admin.  More data on this will be in the RTM SDK.

Comments

  • Anonymous
    September 24, 2006
    PingBack from http://blog.devinstall.com/?p=6

  • Anonymous
    September 26, 2006
    Windows Vista introduces a security concept called User Account Control (UAC) which has multiple impacts

  • Anonymous
    November 07, 2006
    PLEASE tell me why MSIREALADMINDETECTION is not working in my package. I really, really, need it to detect the admin for UI reasons. Please, what is the name of this property in the latest Vista releases? It seems to be ignored. -Perplexed.

  • Anonymous
    December 05, 2006
    Hi, I tried to use AdminUser property in my installer. In XP, this value is set proper. But in VISTA, this value is always set as 1 irrespective of the user is admin or not. Tried to use the MSIREALADMINDETECTION poperty in VISTA and this seems to be not working. Can anyone help? Joby