UAC in MSI Notes: Modify System with InstallUISequence Custom Action
This is the tenth 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 second common mistake we found packages making with UAC in MSI: improperly modifying the system during a custom action in the InstallUISequence.
Client 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 in the InstallUISequence, application compatibility testing found a large 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 client 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 the package author by either moving the custom action into the script (represented by the green circle in the above diagram) or by moving the action out of the package entirely into a bootstrapper or chainer that is capable of fulfilling the package prerequisites.
Conversations Around this Mistake
Besides mistakes made due to lack of awareness, some report they were intentionally working around sequencing and dependency issues. For example, some packages would choose to call out to a setup time dependency during this phase in order to enable the rest of the install to proceed correctly.
If the custom action is logging its errors, the trick is to look for an error code that translates to Access Denied.