Custom Actions under UAC in Vista

Heath Stewart

Visual Studio 2005 works for the most part on Windows Vista, but there are some known issues being addressed beyond SP1. One compatibility issue when running on Vista with UAC enabled may actually occur when installing the recently released SP1 beta on certain editions of Visual Studio 2005.

User Account Control, or UAC, basically prevents even users in the local Administrators group from being administrators by trimming down their access tokens to remove all but necessary privileges. If an action requires more privileges the user is presented either with a prompt for credentials or with a simple Yes/No question to elevate. Before Vista there was Limited User Accounts, or LUA, for which Windows Installer added support. In Windows Installer, the server portion of the install – in which the InstallExecuteSequence table is processed – is already elevated but can impersonate the user who started the client install. Combined with UAC’s non-privileged token, impersonating an administrative user who isn’t the actual Administrator account means that custom actions may actually fail on Vista.

There are several custom actions defined in our product installer packages that do not set the no-impersonate bit in the CustomAction table, so that when they execute they execute using a non-privileged token. The custom action CA_GenerateEnvBat.3643236F_FC70_11D3_A536_0090278A1BB8 in Visual Studio 2005, for example, opens [ProgramFilesFolder]Microsoft Visual Studio 8SDKv2.0Binsdkvars.bat but a privileged token is required for write access. If you look at the Attributes column for that CA, you’ll see 1025, which is msidbCustomActionTypeDll + msidbCustomActionTypeBinaryData + msidbCustomActionTypeInScript – marking this as a deferred binary custom action declared in a DLL in the Binary table. What’s missing is the msidbCustomActionTypeNoImpersonate (0x0800, or 2048) bit that would cause this CA to run with a privileged token.

To work around this issue or to work with any Windows Installer package that doesn’t take UAC into account you can run a command prompt as the actual Administrator, then run msiexec.exe (or a setup’s bootstrap application) from that elevated command prompt. You could also put a manifest file in the same location as the executable, with the same name as the executable with .manifest appended to the filename. For example, a manifest for setup.exe would be setup.exe.manifest. If you are an ISV that wants to pre-elevate your installation, you could embed the same manifest in your executable as an RT_MANIFEST resource with an ID of 1. Either way, example content of that manifest follows:

<?xml version=1.0 encoding=UTF-8 standalone=yes?>

<assembly manifestVersion=1.0 xmlns=urn:schemas-microsoft-com:asm.v1>

    <assemblyIdentity

        type=win32

        name=nwrapdrvr

        version=3.12.0.0

        processorArchitecture=x86/>

    <description>Patch Wrapper</description>

    <trustInfo xmlns=urn:schemas-microsoft-com:asm.v3>

        <security>

            <requestedPrivileges>

                <requestedExecutionLevel

                    level=requireAdministrator

                    uiAccess=false/>

            </requestedPrivileges>

        </security>

    </trustInfo>

</assembly>

Of course, in Vista setup.exe is recognized automatically to be elevated for backward compatibility.

A transform could also be used to change the Attributes for a custom action when installing the product. Similarly, a patch transform could also fix this when patching the product.

For more information about this particular issues with custom actions, see Robert Flaming’s post, UAC in MSI Notes: The NoImpersonate Bit Mistake – part of a wonderful series on UAC support in Windows Installer that is definitely worth a read for any installation developer. His latest post is the fifteenth in the series and has links to all previous posts.

0 comments

Discussion is closed.

Feedback usabilla icon