Whenever I try to package and run Idera SQL Diagnostic Manger 9.1 (x64) with WISE, I get the following error:


My command string is SQLDiagnosticManager-x64_c.exe /S /v"/qb".  I have tried running it with /QN, extracing the MSI with /QB and /QN.  The only time when it doesn't fail is when I run the EXE (or extracted MSI) interactively.  I've also tried as system and user context, and normal/administrator rights.  The same thing happens via CMD prompt.  I also have .NET Framework 4.0 installed.

The following is an excerpt from the MSI log:

MSI (s) (78:38) [13:02:59:051]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIEF4A.tmp, Entrypoint: ISSQLServerInstall
1: Processing the SQL connection 'SQLdm'... 
1: Determining if there is at least one SQL script scheduled to execute under the connection... 
1: The SQL script 'SQLdmDatabaseInstall.sql' is scheduled to execute. Note that the final decision will be made later if you have a schema version specified for this script. Script Execution=RunOnInstall, Action=Install, Component State=Install, Schema= 
1: Attempting to establish the SQL connection... Server: , Database:  
1: ADO Error: Number: -2147467259 Description: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied. Source: Microsoft OLE DB Provider for SQL Server SQL State: 08001 Native Error: 17 
MSI (s) (78!0C) [13:03:34:916]: Product: Idera SQL diagnostic manager (x64) -- Error 27502.Could not connect to Microsoft SQL Server ''. [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied. (17)

MSI (c) (DC:34) [13:03:32:248]: Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg

Error 27502.Could not connect to Microsoft SQL Server ''. [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied. (17)
CustomAction ISSQLServerInstall returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Answer Summary:
2 Comments   [ + ] Show Comments


  • Edited the command string. I am actually not running the EXE with MSIEXEC.
  • After more research, I found that the GUI install will default to a "Custom" install, which only installs the Console. The silent install seems to initiate a "Typical" install, which installs the SQL service. However, I am not able to read the MST to see where this is set. Thoughts?
Please log in to comment

Answer Chosen by the Author

Here is the correct MSI packaging instructions to install the Console only (and PowerShell snapins):

  • Received IderaSQLdmInstallationKit-x64.zip.
  • Extracted to IderaSQLdmInstallationKit-x64.exe
  • Extracts to UNPACKED FILES.
  • Browse to \X64\ and run SQLDiagnosticManager-x64_c.exe (Console Only).
  • Do not install complete install.
  • Browse to Users TEMP folder location to find extracted MSI (Installation MSI)

  • Add PROPERTY - ADDLOCAL=Console,PowerShell_Snapin
Answered 07/06/2015 by: creck
Senior White Belt

Please log in to comment


You'll probably find that, during the UI install, you're prompted to enter the name/instance of a SQL Server.

You need to find the name of the property "behind" the text-box and then pass that name and a value for it on the command line. So, let's say the property name is "SQLSRV" and your target server's name is "APP_DB", you need to use this on the command line:

msiexec /i [path_to_and_name_of_MSI] SQLSRV=APP_DB /qb /l*v %SystemRoot%\TEMP\Install_SQLDiags.LOG

Note that I have added logging to your command line.

Also, make sure that any relevant Custom Actions which are in the UI sequence also appear or are set to run in the ExecuteImmediate sequence. It's common for vendors to assume that all installations will be done via the UI and forget to account for silent installs.

Next, you need to be careful about which account you use for installation. The local System account won't have any network access so connections to servers will fail, as will any account which doesn't have access to the target database.

Lastly, your original command line is a mix of vendor EXE command line arguments and those for MSIExec. Extract the MSI and use that BUT...when you've test-deployed your package for the first time, use a lightweight snapshot tool to do a comparison against what the MSI does and what the EXE does (remembering to rename the registry's 'Uninstall' branch first, to prevent Windows Installer believing the package is already installed): it's not unknown for lazy vendors to add code to their set-up stub which really belongs in the MSI.
Answered 07/03/2015 by: VBScab
Red Belt

  • The GUI install does not prompt for a SQL instance, and I did mix up the command line. I edited the original question.
Please log in to comment
Your .exe command line is a little off, you're running 'msiexec' with the .exe - you should be running the .exe with a '/S /v...' to pass the parameters to msiexec.
But I don't think that this is your issue, as it only installs when run interactively anyway.

Do you provide any futher information (SQL server name etc.) in the GUI install?
If you don't then there could be a CA that is only running in the 'InstallUISequence' that is generating some configuration needed to complete the install.
You may be able to move the CA into the 'InsallExecuteSequence' to allow it to run in a non-IUI install.

You could also run a verbose log on a GUI install and check the properties populated as it runs through. Compare that to a non-UI install log and see if there is anything you can incorporate into an MST to pre-populate the properties.

Hope that helps,

EDIT: VBSCab beat to me it - with pretty much the same info!
Answered 07/03/2015 by: dunnpy
Red Belt

  • The log comparison steer is a good one. Forgot that :-)
  • The GUI install does not prompt for a SQL instance, and I did mix up the command line. I edited the original question.
    • There is likely a custom action in the UI sequence that populates a property for the SQL server, so check the logs for the property it populates, or see if you can move the CA into the InstallExecuteSequence.
Please log in to comment

I think you should create a response file, and try to install silently but with the response file, this will assure all the actions you performed with the UI will be done unnattendedly. If this solution doesn't work, take a look on the msi on the sequence tables, to check if there are some actions on InstallUISequence that are not present on InstallExecuteSequence, and copy them using a transform.

Finally, before doing the avobe actions, assure that you have connectivity to the server  and is reachable.

Hope it helps

Answered 07/03/2015 by: enzio
Orange Belt

Please log in to comment
>The GUI install does not prompt for a SQL instance
Does the EXE install prompt? Stupid question, it *has* to, or how would it know which server/instance to connect to?!? :-)

As stated above, examine the log and find out which property contains that value.
Answered 07/06/2015 by: VBScab
Red Belt

  • It may be helpful to know this product before responding.

    I downloaded the IderaSQLdmInstallationKit-x64.exe from IDERA. After extracting, I am executing the file SQLDiagnosticManager-x64_c.exe with the switches of /S /v/qn. /qb fails as well. This command worked for the last three iterations of the product.

    The product install walkthrough is:

    Launch SQLDiagnosticManager-x64_c.exe.
    Click Next.
    Accept EULA.
    Specify install location (kept default).
    Install this application for: All Users
    Setup type: Console Only

    I extracted out the MSI that the SQLDiagnosticManager-x64_c.exe and ran it with and without quiet switches (verbose logging). I am not able to use BeyondCompare to review the files, as they seem to be completely different. There are many changes to the properties table that I cannot determine which ones would be appropriate to change in an MST.
    • Going back to an earlier comment in this thread - have you examined a VERBOSE LOG of the MSI installation as obtained through a fully manual install of the program? This will report on property values throughout the install so that you can see what is going on. It may well be that the EXE containing the MSI presents dialogs of its own and sets property values that are passed to the MSI.
Please log in to comment
Answer this question or Comment on this question for clarity