This is the twenty-third 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
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: was "this" intentional? If so, why?
While rolling out the User Account Control (UAC) support for Windows Installer (MSI), we’ve been having a common conversation about how to build a single install package that works for both broad web and managed corporate deployment. The thread below homogenizes the questions into an imaginary ISV and the common scenario that drives this particular conversation.
Imaginary Independent Software Vendor (ISV):
Tim is an ISV who provides both a remote browser only and locally installed client experience where both are coupled with Tim's server side backend. The locally installed Tim client harnesses the horsepower of the client node providing a richer Tim experience.
ISVs Market Realities:
Accessing the Tim client market, Tim needs an Install experience that installs to either all-Standard-User or no-Standard-User writable locations. The all-Standard-User-writable install maximizes for reach while accepting a user could mess with integrity of the binaries. The no-Standard-User-writable install maximizes integrity of the binaries while accepting there will be less reach due to some (perhaps many) unable to get their administrators permission.
ISVs Reduction of UAC Messages:
Tim has reduced the messages from the UAC evangelists to:
ISVs Derivation from UAC Messages:
Tim is willing to assume that a Protected Admin will always elevate and a pure Standard User (thus an OTS prompt) will never elevate.
From a single install package, Tim wants to figure out whether the person initiating the install is Protected Admin or plain Standard User. If Protected Admin, then the install package will configure itself to run as no-Standard-User-writable; else (a plain Standard User), the install package will configure itself to run as all-Standard-User-writable.
Initial ISV Ask:
Please provide me a way to query if the Standard User is plain Standard User or Protected Admin user so that I can execute on this scenario.
A couple of things to consider
Second ISV Ask:
The Windows Installer team has actively encouraged ISVs not to use bootstrappers if they don’t need to and we’ve determined separate packages have no collisions so they can be easily merged as long as we have a decision point to chose between the paths. Isn’t there some way to make this work.
Assuming you’re willing to take the risks of the road less traveled, there is a mitigation path that involves
This is not the majority case for software distribution today so we are unable to provide the same assurances we would provide were you to follow the recommended path.
Third ISV Ask:
Is there a way to avoid the setup.exe bootstrapper in the home administrator case?
You could recommend folks run the install from an elevated command prompt.
Preliminary SDK page:
MSIUSEREALADMINDETECTION PropertySet the MSIUSEREALADMINDETECTION property to 1 to request that the installer use actual user information when setting the AdminUser property. When running on Windows Vista, the Privileged and AdminUser are the same. Authors should used the Privileged property in new packages. Legacy packages that require distinct Privileged and AdminUser properties can restore the difference by setting the MSIUSEREALADMINDETECTION property.