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
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.
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.
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.