Azmaeus
Level 6

What's triggering ISSQLServerInitialize to overwrite my IS_SQLSERVER_SERVER property?

Jump to solution

In my installer I run an in-house app that builds our databases, and in the SQL Scrips configuration I am removing the databases on uninstall. The issue I'm running into is that any custom SQL server/instance will fail to uninstall (and roll-back the uninstall so it can't be uninstalled unless manually). I plan to create a CA that will gather the custom SQL server and instance, but in the meantime I was hoping to uninstall the affected computers by passing the parameter to the uninstall the custom server and instancename, for example

-v"IS_SQLSERVER_SERVER=localhost\SQLEXPRESS"

Interestingly however, the uninstall still fails with the same message that it can't connect to the SQL instance, and it gives the name of the default instance instead of the one I passed as a parameter. I looked at the logs, and discovered that ISSQLServerInitialize is changing the parameter?? I took just portions of the log below, I can fill-in gaps if I skipped gathering a crucial line:

MSI (c) (A0:D8) [10:53:16:850]: Command Line: IS_SQLSERVER_SERVER=localhost\SQLEXPRESS SETUPEXEDIR=C:\Users\my.user\Downloads\myInstaller SETUPEXENAME=setup.exe CURRENTDIRECTORY=C:\Users\my.user\Downloads\myInstaller CLIENTUILEVEL=0 CLIENTPROCESSID=1696 
MSI (c) (A0:D8) [10:53:16:850]: PROPERTY CHANGE: Adding IS_SQLSERVER_SERVER property. Its value is 'localhost\SQLEXPRESS'.
MSI (c) (A0:D8) [10:53:16:865]: Doing action: SetHostPropertyIfEmpty
Action 10:53:16: SetHostPropertyIfEmpty.
Action start 10:53:16: SetHostPropertyIfEmpty.
MSI (c) (A0:D8) [10:53:16:865]: PROPERTY CHANGE: Adding VAR_DB_HOST property. Its value is 'MYHOSTNAME'.
Action ended 10:53:16: SetHostPropertyIfEmpty. Return value 1.
MSI (c) (A0:D8) [10:53:16:865]: Skipping action: Set_IS_SQLSERVER_SERVER_IfEmpty (condition is false)
MSI (c) (A0:D8) [10:53:16:865]: Doing action: ISSQLServerInitialize
Action 10:53:16: ISSQLServerInitialize.
Action start 10:53:16: ISSQLServerInitialize.
MSI (c) (A0:F4) [10:53:16:865]: Invoking remote custom action. DLL: C:\Users\my.user\AppData\Local\Temp\2\MSI2113.tmp, Entrypoint: ISSQLServerInitialize
MSI (c) (A0:E4) [10:53:16:865]: Cloaking enabled.
MSI (c) (A0:E4) [10:53:16:865]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (A0:E4) [10:53:16:865]: Connected to service for CA interface.
1: Reading the SQL script data from ISSQLConnection table...
MSI (c) (A0!F4) [10:53:16:928]: PROPERTY CHANGE: Modifying IS_SQLSERVER_SERVER property. Its current value is 'localhost\SQLEXPRESS'. Its new value: 'MYHOSTNAME\SQLEXPRESSDMA'.
MSI (c) (A0!F4) [10:53:16:928]: PROPERTY CHANGE: Adding MsiHiddenProperties property. Its value is 'SAPWD'.
MSI (c) (A0!F4) [10:53:16:928]: PROPERTY CHANGE: Adding IS_SQLSERVER_INITIALIZED property. Its value is '1'.
Action ended 10:53:16: ISSQLServerInitialize. Return value 1.
You'll see I pass the parameter correctly, and it sets the property. I have a CA that gathers the hostname, and another that populates IS_SQLSERVER_SERVER if it wasn't passed as a parameter, and you can see that the CA is skipped because IS_SQLSERVER_SERVER is populated already. Then we get to ISSQLServerInitialize, and it clearly states that it's changing the property IS_SQLSERVER_SERVER from what I had it to the default. I can't find where that default might be set though, nor how to tell it to take the parameter over falling-back to the default. Any ideas? Thanks in advance.
Labels (1)
0 Kudos
1 Solution
Azmaeus
Level 6

For future generations, I found the issue. By default, ISSQLServerInitialize overwrites the SQL connection properties with what it has stored somewhere in the registry (I never looked into where specifically). To bypass this, you need to add a property "IS_SQLSERVER_DO_NOT_USE_REG" and set it to "1". This will skip that step, allowing you to set your own connection properties.

View solution in original post

1 Reply
Azmaeus
Level 6

For future generations, I found the issue. By default, ISSQLServerInitialize overwrites the SQL connection properties with what it has stored somewhere in the registry (I never looked into where specifically). To bypass this, you need to add a property "IS_SQLSERVER_DO_NOT_USE_REG" and set it to "1". This will skip that step, allowing you to set your own connection properties.

View solution in original post