Share via

UAC in MSI Notes: Answers to questions in comments from earlier blog posts.

  • Article

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.

Comments

  • Anonymous
    October 01, 2006
    PingBack from http://blog.devinstall.com/2006/09/24/understanding-uac-in-vista-and-windows-installer/

  • Anonymous
    October 02, 2006
    Windows Vista introduces a security concept called User Account Control (UAC) which has multiple impacts

  • Anonymous
    October 10, 2006
    This is going to sound like a stone age question, but I'd appreciate any help. If I have a standard VS2005 Setup and Deployment project that generates an .MSI file, then how do I change/update it so that the custom actions can run elevated as Adminstrator under UAC? The custom actions are included in a .NET assembly that uses the [RunInstaller(true)] attributes. These custom actions set a .NET Code Access Security local machine policy change. I realize that UAC will be triggered (which is good), but at the moment it just fails silently, plus there is no 'Run as Admin' action on the MSI. The workaround for some of my user has been to write a .bat file (!!) like this: 'msiexec.exe /i myinstall.msi' and then use the 'Run as Admin' action on that instead. If all this is not possible, and I need to go learn Wix and/or MSI 4.0 and avoid VS2005 S&D projects, then that's an answer too :-) Thanks for any help or advice!

  • Anonymous
    December 13, 2006
    Recently, I was helping a customer investigate an issue in an MSI-based installer that they created for

  • Anonymous
    May 02, 2007
    The goal I think that most things don't need to require a UAC prompt to install - just install it for

  • Anonymous
    January 18, 2008
    A new Channel9 video has been posted that I wanted to link to here. The video is located at http://channel9.msdn.com/ShowPost.aspx?PostID=374129

  • Anonymous
    January 18, 2008
    A new Channel9 video has been posted that I wanted to link to here. The video is located at http://channel9

  • Anonymous
    February 27, 2008
    When you work on a given subject for a while, you tend to jump right in and forget to start at the beginning.

  • Anonymous
    February 27, 2008
    When you work on a given subject for a while, you tend to jump right in and forget to start at the beginning

  • Anonymous
    August 15, 2008
    If you are reading this you have probably realized that installing an MSI on Server 2008 has gotten more