CommVault SQLiDA: Unable to get SQL version

Recently one of our development servers crashed. Upon recovery we started to receive the following error messages when backing up the Microsoft SQL databases: “Unable to get the SQL Version for the server [DEVSERVER]. Please check if the SQL Services are running.

It’s important to note:

  • Before the crash the backups ran fine;
  • the file “SQLServerInstanceList.txt” listed the following information: “(local);Clustered:No;Version:11.0.5058.0“;
  • the SQLiDA log only mentions “Unable to get the SQL Version for the server“;
  • the server has been restarted and the SQL iDataAgent has been reconfigured (removed keeping software in place and reconfigured).

The involved components are:

  • CommVault Simpana 9 Service Pack 14;
  • SQL2012 Service Pack 2 installed on a Windows Server 2012 R2 (standalone SQL server);
  • the CommVault Simpana iDataAgent for SQL is entirely up to date and on the same level as the CommServe.

At first, we thought it could be related to some missing security settings for the local system account which is running the CommVault services. The error still occurs, even though when we gave him sysadmin permissions.

It still astonished me, the software was able to see the SQL version (based on what we see in the logfiles). After deleting a database in the default subclient and triggering a manual discover the process, the database is not being discovered anymore.

Eventually I activated verbose logging for the SQLiDA (EventManager hive > SQLiDA_DEBUGLEVEL DWORD) and gave it value 5 (log everything) and restarted the CommVault services on the client.

SQLversionNotFound

During an additional validation of the SQLiDA log, the following record caught my eye: “4800 728  05/28 16:18:47 ### CsqlDMO::InitializeCOM() – Error : COM Initialization failed. Error : [0x80131700]“. After some research I found out this is related to authentication in combination with Microsoft .Net Framework 4.5 (KB2252691).

Resolution:

  1. We compared the installed .Net components between the production server (backup & recovery works) and the development machine.
  2. Installed the following components on the development server again: “.Net Framework 3.5 (Includes .NET 2.0 and 3.0)” and “ASP.NET 4.5“.
  3. Reboot server

Once the above listed components are installed the backup of the databases is executed without any problem.

Thanks for reading!

 

 

Leave a Reply