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

Artikkeli
10/01/2006

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

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

Jaa

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

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

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

Comments

Lisäresursseja