6 replies to this topic

[Deli Radivoje]

I'm working on installation of an application that uses SQL server as a database server. For most of our users the database server will be the SQL Express 2008 which can be installed with the application. But few more demanding users prefer to use their own SQL servers as a storage. Usually they don't want to install anything else on that server, just to put the database there.
So, I have two scenarios during installation:

1. Database is installed on a local computer. In that case, I have to set the In-script execution type of custom actions ISSQLServerInstall, Uninstall and rollback to Deffered Execution in system context (which is default), because otherwise in Windows Vista or 7 installer cannot connect to newly installed instance of SQL Express 2008 (setup is actually not running with full administative rights).

2. Database is installed on a remote computer. In that case I have to set the In-script execution type of custom actions ISSQLServerInstall, Uninstall and rollback to Deffered Execution because they have to authenticate themselfs on SQL Server using current windows user name, not as a local system.

I,ve cloned the ISSQLServerInstall CA and made ISSQLServerInstallNetwork CA, and set the In-script execution type to only Deffered Execution. First is executed if a SQL server is on a local computer and second if the SQL server is on remote computer. I've did the same with ISSQLServerUninstall and ISSQLServerRollback.
The problem is, even my new CA ISSQLServerInstallNetwork executes as planned during the installation of a remote database, it actually does nothing (ie not run any script):

MSI (s) (C0:10) [09:07:46:221]: Skipping action: ISSQLServerInstall (condition is false)
MSI (s) (C0:10) [09:07:46:221]: Doing action: ISSQLServerInstallNetwork
Action 9:07:46: ISSQLServerInstallNetwork.
Action start 9:07:46: ISSQLServerInstallNetwork.
ISSQLServerInstallNetwork:
Action ended 9:07:46: ISSQLServerInstallNetwork. Return value 1.

The behavior of my CAs ISSQLServerUninstallNetwork and ISSQLServerRollbackNetwork is the same (executes but doing nothing).

Does anybody have an idea how to solve the problem?

Edited by Deli Radivoje, 20 November 2009 - 09:59.

[Stefan Krueger]

Do the original actions work if you change their type to defeered (not in system context)? Maybe they just cant work in that mode.

[Deli Radivoje]

No, they don't work on Windows 7. The problem is that they authenticate as a user that is installing application and in Windows 7 (and Vista probably) that user by default doesn't have permissions to create a database. I'm creating DB from SQL script, not automaticly, because I want to set physical location of files.

Now I'm in process of making CA that will add user that is installing application in sysadmin role in our instance of SQL Express (if it is installed). That action then will be run as a Deffered Execution in system context. After that, I hope that ISSQLServerInstall will run in Deffered Execution mode even on Windows 7 machines.

[Deli Radivoje]

I've done a CA that add current user (that is installing application) to the sysadmin group of newly installed instance of Sql Express 2008 and now the installation can do a CREATE DATABASE statement if ISSQLServerInstall CA is not running from the system context.

But, I've found another interesting issue: in a scenario when my database is on the remote computer, I can change a name of a database server in the UI part of the installation procedure using standard SQLLogin dialog and standard properties like IS_SQLSERVER_SERVER The installation works fine both on Windows XP x32 and Windows 7 X64 (my virtual test enviroments). During the uninstallation the procedure should also delete the database.

On Windows XP, the procedure correctly removes the database from the server which name is stored in property IS_SQLSERVER_SERVER during the UI part of the installation phase.

On Windows 7 x64, the procedure tries to remove the database, but in that process it using base value of IS_SQLSERVER_SERVER property, and not the value which is supplied during installation. Of course, the delete database statement then fails.

I assume that it has connection with fact that the CAs ISSQLServerInstall and ISSQLServerUninstall are not running in the system context. Has anybody experienced a similar behaviour?

Edited by Deli Radivoje, 22 November 2009 - 14:45.

[Deli Radivoje]

It looks like it has something with UAC. When I disabled it during installation phase, uninstallation on Windows 7 started to behave as expected.
Any thoughts?

Edited by Deli Radivoje, 23 November 2009 - 10:10.

[Stefan Krueger]

You may need to list these properties in the SecureCustomProperties property. Otherwise you may see notices about "disallowing insecure properties" in the log and the value switches back to the default.

[Deli Radivoje]

I haven't found "disallowing insecure properties" neather in installation nor uninstallation logs.
These properties (IS_SQLSERVER_SERVER etc.) are provided by InstallShield and I think the installation encrypts and stores them somewhere during the execution of one of the built-in CAs that are used to execute SQL scripts.
When I changed CAs ISSQLServerInstall, ISSQLServerUninstall and ISSQLServerRollback not to run in system context one of them probably started to lack privileges to store those properties if setup is going on Windows 7 with UAC enabled.