UAC in MSI Notes: What are the Hurdles in Windows Vista Logo compliance related to UAC and MSI?
This is the twenty-sixth 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
- Architecture Insights
- Common Package Mistakes
- More Architectural Insights
- Conversations with Customers
- Should I write my installer as a Standard User install? If yes, how?
- When General Custom Action Mitigation Fails
- How do I get the shield on the advertised shortcut?
- How do I troubleshoot UAC in MSI via the log?
- Do I need to consider "this" when I'm designing for UAC in MSI? Generally, no.
- Is "this" intentional? If so, why?
- How to Build Packages that work for both Standard User and Per-Machine?
- Easier for my current custom installer to support UAC than switch to MSI?
- How do I get one credential dialog for a multiple package install?
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: What are the Hurdles in Windows Vista Logo compliance related to UAC and MSI?
Hurdles in Windows Vista Logo compliance related to UAC and MSI?
Windows Installer has returned to the Windows logo program. UAC has occurred for the first time. The support of UAC in MSI has created the following questions related to Logo compliance.
When I run my application at the end of the install, it runs as the administrative user. How do I stop that?
Like the correct user locations question above, there are a couple of solutions available.
- First, start by consider not launching the application at all. The reason you would do this is that you can guarantee that 100% of the time the package would be running in the correct user context.
- Second, minimally make sure the custom action launching the application is immediate. Immediate custom actions do not impersonate.
- Third, the first two cases are vulnerable to the context before the MSI being elevated to an administrator who is different than the user. One can try to use WTSQueryUserToken to impersonate the root user but this is not guaranteed to work on 100% of the cases.
Why are my Internal Consistency Validator (ICE) checks failing on my LUAAware package?
The Windows Installer section of the Windows Vista Platform SDK contains an updated version of the ICEs for Windows Installer 4.0. You can get them by installing the new version of Orca.MSI or MsiVal2.MSI.
Unsigned Binaries are Getting Flagged when I run Validation on my Package. Is this required?
The Windows Vista Logo program does have a requirement for signed binaries but it is not part of the install section. This validator is actually coming from another source than the Windows Installer ICE validators. Some tools vendors have gone the extra mile to help you get your software prepared for Logo and are providing those validators are part of their value add.
If you are not interested in the Logo program, talk to your vendor about how to turn off the Logo portion of the validation. If you are interested in the Logo program but you can't sign these files (for example, they were provided to you by another vendor) please contact the Logo authority about their recommendations for handling this situation.
The Innovate On Windows Vista site contains the information on both the Works With and Certified For Windows Logo programs. Windows Installer is specifically in the Certified For program. The available documents are the Requirements Document and the Test Document. I tell folks that if they are confused about what a requirement means, examining the specific tests for that requirement is usually a good step to figuring it out.