I have a setup of my program written in VS2008. There are Custom Actions in setup which open SqlConnection to server for database interaction.

When SQL Server Authentication is used the there is no problem. In case when windows authentication is used and SQL Serveris not onthe same machine then Login Failed Exception is thrown, which is as follows:
Login failed for user '<Domain>\<Username>$'

Following is the connection string I used:
packet size=4096; integrated security=SSPI; data source=<Server Name>; persist security info=True; initial catalog=<Database Name>

I included the custom action dll to a sample project and called the function from there but there isno problem accessing the SQL Server.

The one thing I noticed was that the setup runs under system account, this might be the problem and the user contianed in the exception is terminated by a $ sign.

Any help is appreciated.

The most useful recommendation I have for everyone doing this is to stop.Instead, do this configuration step later, after
the install.

The issue is that yes, custom actions generated by VS 2008 run with the system account. This allows them to run privileged on UAC systems. To turn this behavior off you'll have to change the MSI file after you've built it (there's no option in Visual Studio to control whether the custom action runs withimpersonation or not). Use Orca to edit the MSI file. Go to the CustomAction table, identify your custom action and turn off the msidbCustomActionTypeNoImpersonate bit.
http://msdn.microsoft.com/en-us/library/aa368069(VS.85).aspx

You'll also need to ensure that the install is run from a an elevated environment on UAC systems.

It's not clear to me whether this will always work. It means your code will run impersonating the installing user, but impersonation cannot be indefinitely propagated, so if SQL also attempts impersonation of your code, an already-impersonated user, there might be an issue. The bottom line here is that setup projects are not a good place to application configuration because you are *not* running in an application environment.

---

Phil Wilson

The most useful recommendation I have for everyone doing this is to stop.Instead, do this configuration step later, after
the install.

The issue is that yes, custom actions generated by VS 2008 run with the system account. This allows them to run privileged on UAC systems. To turn this behavior off you'll have to change the MSI file after you've built it (there's no option in Visual Studio to control whether the custom action runs withimpersonation or not). Use Orca to edit the MSI file. Go to the CustomAction table, identify your custom action and turn off the msidbCustomActionTypeNoImpersonate bit.
http://msdn.microsoft.com/en-us/library/aa368069(VS.85).aspx

You'll also need to ensure that the install is run from a an elevated environment on UAC systems.

It's not clear to me whether this will always work. It means your code will run impersonating the installing user, but impersonation cannot be indefinitely propagated, so if SQL also attempts impersonation of your code, an already-impersonated user, there might be an issue. The bottom line here is that setup projects are not a good place to application configuration because you are *not* running in an application environment.

---

Phil Wilson