UAC in MSI Notes: Modifying System in InstallExecuteSequence outside of Script
This is the eleventh 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
- Introduce...
- Architecture Insights
- Common Package Mistakes
This entry will talk about the third common mistake we found packages making with UAC in MSI: improperly modifying the system during a custom action in the InstallExecuteSequence.
Server Custom Actions Modifying the System
Given the pre-Vista operating systems did not enforce the architectural intent to that modifying the system should not occur outside the script of the InstallExecuteSequence, application compatibility testing found a number of packages that had custom actions failing. Here's the "saw tooth" diagram I draw on my whiteboard to illustrate this mistake.
With the permissions changes in the context of UAC, that the server outside the script is always executed as Standard User causes the Application Compatibility problems to show up. The red “no” circle is where this mistake is generally made. This mistake is generally mitigated by moving the custom action into the script (represented by the green circle in the above diagram).
Conversations Around this Mistake
Generally folks make this mistake due to lack of awareness as they followed that they needed to be in the server via InstallExecuteSequence.
If the custom action is logging its errors, the trick is to look for an error code that translates to Access Denied.
Comments
- Anonymous
September 24, 2006
PingBack from http://blog.devinstall.com/?p=6 - 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
September 30, 2006
This is the nineteenth in a series of notes about UAC in MSI. Per the earlier caveat, these are...