Is your MSI Package ready for Vista?

Here’s a quick tip I’ve been meaning to post for a while. By now you all know that Windows Vista is coming and if you’ve been following the buzz about the new operating system you’ve probably heard of LUA, er UAP, no UAC. All those three letter acronyms basically mean that even when you are logged in as a user in the Administrators group (but not the Administrator user) you do not have all privileges of the built-in Administrator user. I suggest reading the UAC team’s explanation of why UAC is an important security advancement for Windows to get some background.

So what does this mean for we setup developers? Well, if you have not specified the appropriate elevation privileges for your CustomActions and simply relied on a global check at the beginning to say, "Is this user an Administrator?" then you’re going to see your install failing on Vista in many of the UAC scenarios.

If you don’t have any CustomActions in your installation package then you are probably safe. However, I know a lot of you like to write code (yes, yes, I know the Windows Installer doesn’t provide everything you need built-in. I still highly suggest avoiding CustomActions if at all possible and if reuse the actions from the WiX toolset if at all possible since those CustomActions have a lot of testing already).

So you’ll probably want to do a couple quick checks to see that everything installs okay on right now, right? What? You don’t have access to a CTP build of Vista? S’okay, thanks to information from Carolyn Napier, you can mimic the UAC behavior of the Windows Installer by doing the following on a Windows XP box (probably works on Windows 2000 as well):

1.  Log in as the Administrator (actually, any administrator will do)
2.  Machine advertise your MSI package by doing: msiexec /jm my.msi
3.  Log off
4.  Log in as standard user (any non-administrator will do, make one up in step 1 if you have to).
5.  Kick off the install of your MSI package by doing:  msiexec /i my.msi

What this does is get the MSI package “blessed” by the Administrator on your machine but not actually installed (step 2). Then you launch the install as a non-privileged user (step 5). The Windows Installer will elevate portions of the install to system privilege as necessary to install the package because the administrator said it was okay from the beginning. That “as necessary” part is the important part. If you’re CustomAction requires elevation but is not marked appropriately then the CustomAction will fail… just like it would on in UAC.

Try it out. You might be surprised what you find.

By the way, this very issue caught Dare and RSS Bandit recently. One of a few reasons, I’m going to be helping out there next month… more next month.

Comments (9)

  1. Wayne Steele says:

    Very nice, but these steps don’t work for me.

    My setup program specifically checks to see if you’re in the Administrators group, and won’t let you install if you’re not.

  2. LinWinOverlord says:

    I have been wondering on trying out WiX for my packaging of software for a website that I work on… I am not sure whether the WiX toolkit can be easily used…. I have not found any programs that work similar to HM NIS Edit that can convert other installer scripts (NSIS, Inno) to WiX and be able to create installers in a wizard-style (click and point)…. I figured that would be easy to find, but I was definitely wrong… If you know of any, tell me!

  3. Curtis Sawin says:

    I’ve always been puzzled that getting ones setup program "logo compliant" does not include requirements for advertising/installing in a "locked" environment.  Even though one of the ICEs ensures that one uses the "Privileged" property and not "AdminUser" in conditional statements.

    I’m kinda glad we chose to deploy MSIs in our environment by assigning/adversting to users using Group Policy, as this forced us to preprare (in this respect) for our MSIs being deployed on Vista.

    But you’re right, we see many MSIs that have "AdminUser" as a LaunchCondition due to some custom actions not having the "msidbCustomAction

    TypeInScript" and "msidbCustomActionTypeNoImpersonate" attributes.  

    In many cases, this is easily correctible.

    Lastly, I enjoy the blog.


  4. Doug says:

    So what needs to be done for a custom action to be "Marked Appropriately"?

  5. Curtis-

    Here is a page for you to read:

    BTW I wonder what effect this will have on SMS 2003 pushes under the context of the SYSTEM account.  I assume that SYSTEM will have full priv like the built in Administrator account.

  6. UACBlog says:

    Hi, I’m Jenn, the tech writer for UAC. We’ll sometimes post links in the blog to useful/interesting articles…

  7. Alexandra says:


    I observed that empty C# Custom Actions hang on Vista while empty C++ Custom Action do not.

    The following error appears in the Event Viewer on the hang :

    Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface.  hr = 0x800706f7.

    Do you have any insights/leads on that ?

    .NET framework 1.1 is installed.



  8. g- says:

    Wayne Steele-

    Well your installer won’t install on vista at all then.  Checking if the user is in the administrator group will return a false even if you’re the machine administrator.  Even administrator’s use a stripped down sacl for executing processes.

  9. Phil Wilson says:

    "Marked appropriately" in custom actions on Vista means to run without impersonation, so you’re running with local system privileges. Otherwise you’re running with an impersonated account that you think is admin but in fact is not because of UAC.