microsoft.public.dotnet.framework.setup

Phil Wilson

1/9/2009 8:48:00 PM

VS 2008 setup projects generate MSI files with custom actions that run with
the SYSTEM account. Maybe this looks like a network service (or computer
name) account when it connects to the other system. You'd revert to running
impersonated by editing the MSI file with the tool Orca in the Windows SDK
and turning off the msidbCustomActionTypeNoImpersonate bit in the
CustomAction table entries for your custom action, in the Type value.
There's no IDE support in VS for this, basically because it's not designed
as a fully-featured setup tool like those from InstallShield, WiX, Wise,
Advanced Installer etc.

The reason this change was made is related to Vista/2008 UAC. The default
behavior in UAC is that custom actions must run under the system account to
run elevated. Impersonated custom actions that run with the installing
user's credentials are not elevated by default in the same way that
administrators are not elevated by default. To get impersonated custom
actions to run elevated on Vista you'd have to launch the MSI from an
already-elevated environment, such as running the setup.exe launcher that
will ask for elevation and then run the MSI install.

The Windows Installer team does not support installer class forms running
out of the execute sequence of a setup, which is unfortunately where your
custom actions are running. Also, Vista doesn't allow services that
interact with the user's desktop, and running your forms UI off an msiexec
process with the SYSTEM account seems like the kind of security risk that
will be corrected some day. You should use the built-in dialogs that will
get text strings associated with properties and use those properties in your
custom actions. The best overall approach is to take all this kind of stuff
out of the install and into a separate configuration program you run
afterwards, where you have some control over the environment in which it's
running.

--
Phil Wilson
Definitive Guide to Windows Installer
http://www.apress.com/book/view/...


"georgina" <robert@softdev.net> wrote in message
news:4cce62e1-0741-4631-83ce-e676855a27ef@t39g2000prh.googlegroups.com...
>I migrated a windows app from VS2005 to VS2008, maintaining
> compatibility level for the app at .net 2.0 (because of 1000+
> clients). The setup project seems to no longer use the credentials of
> the user running the installer to access network services (sql server
> database). Instead it is using the Network Service identity. The
> Network Service user in my environment doesn't have sufficient
> database privileges to run scripts against databases if they are
> located on a remote machine, so the installation fails. I would like
> the setup project to work as it did in VS2005, where it used the
> credentials of the user running the installer to access network
> services. Under these conditions, remote databases can have scripts
> run against them if the person launching the installation has the
> required privileges on the (remote) database. Our clients are
> accustomed to this scenario. How can I make the 2008 setup project
> revert to how things were in 2005?
>
> The setup project uses a class library which opens a windows form
> where the user selects the database server and database name, and then
> runs an update script before the installer completes.