This is the twenty-seventh 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

1. Introduce...
   1. ...the UAC in MSI Notes series
   2. ...my view of the root problem
   3. ...the conflicting per-user definition
   4. ...it'll be just like Managed Installs
   5. ...the jagged edge to user
   6. ...my relief providing framework
2. Architecture Insights
   1. The "Saw Tooth" Diagram
   2. Credential Prompt and Permissions
3. Common Package Mistakes
   1. The AdminUser Mistake
   2. Modify System with InstallUISequence Custom Action
   3. Modify System with InstallExecuteSequence Custom Action Outside of Script
   4. The NoImpersonate Bit Mistake
4. More Architectural Insights
   1. My "Four Square" Diagram
   2. Challenges for a Beautiful Custom Action
   3. O Whitepaper, Where Art Thou?
   4. Read the Friendly Manual
5. Conversations with Customers
   1. Should I write my installer as a Standard User install? If yes, how?
   2. When General Custom Action Mitigation Fails
   3. How do I get the shield on the advertised shortcut?
   4. How do I troubleshoot UAC in MSI via the log?
   5. Do I need to consider "this" when I'm designing for UAC in MSI? Generally, no.
   6. Is "this" intentional? If so, why?
   7. How to Build Packages that work for both Standard User and Per-Machine?
   8. Easier for my current custom installer to support UAC than switch to MSI?
   9. How do I get one credential dialog for a multiple package install?
   10. What are the Hurdles in Windows Vista Logo compliance related to UAC and MSI?

The last entry marks the end of the document I had original written up and was converting into these blogs. This entry is a switch to an Odds and Ends section that will report the questions that still occur. For this entry in the Odds and Ends section, the topic is: answers to questions to comments from blog posts.

Megh's question under UAC in MSI Notes: Conflicting Definitions of Per-User

1. If we term "C:\Documents and Settings\UserName\Local Settings\Application Data" as the new Per-User location, where does "C:\Documents and Settings\UserName\Application Data" kicks into (based on XP)?

I'm not the shell folders guy but I'll offer you a few things.

• First, there's a pattern you'll find in the OS that they move the root of the users directly relatively often. Can't tell you why but this isn't the first time it has moved and is unlikely to be the last.
• Second, if you are using a CSIDL and the APIs, the shell will take care of you. I suspect the first point is to try and isolate those that are not following this point but I have no corroboration for this hunch.
• Third, I've heard talk that the old directories may be hard linked to the new directories for app compat but I can't tell you how or where I heard that.

I know the app compat teams are planning to expand their documentation but I don't know if this is on the list.

 

2. When you say, "Setup programs ... can loosen ACLs on anything not Windows Resource Protected", are we talking with the installation package install arena except WRP?

Yes, I think we're saying the same thing.

3. With the File and Registry Virtualization in Vista, when the UAC users are in illusion at folders like Program Files, are they redirected to CSIDL_LOCAL_APPDATA at their profile? How does this help with the per user security if all we are doing is re-directing?

I'm in the same building as the Virtualization team that implemented this feature (not to be confused with Virtual Machine, Virtual Server, or Softricity). This is documented to be an application compatibility measure that will be pulled from a future OS and is not even on the 64 bit platforms. Given the intended shelf life is small, the expected effect is to prevent apps (doing the wrong thing) from blowing up. The accompanying expectation is that eventually they will be either updated for Vista or replaced by a program in better compliance.

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.

RandomGuy's question under UAC in MSI Notes: The NoImpersonate Bit Mistake

Hmm... that works for everything except for custom actions which run after Installfinalize... Because they are not deferred custom actions and hence the noimpersonate bit cannot be set.

Yes, exactly right. This is because InstallFinalize is the edge of the Teal circle in the "Saw Tooth" diagram. Once you are outside of the circle, there is no elevation allowed. This is an intentional constraint on the system because it allows the system to be more secure and more deployable.