Forum Discussion

mhale's avatar
mhale
Level 2
4 years ago

SharePoint credential failure with SQL Availability Group

We are trying to use Backup Exec 21.1 to protect a SharePoint 2016 farm that is sitting on top of a SQL 2016 Availability Group.  I understand the capability to back up availability groups is new in this version.

BE discovers the farm topology no problem and adds all the component servers and the database listener without issue.  I can back up all these servers in the normal way as just a bunch of servers, and likewise can back up databases from the listener without issue.  However when I create a job to back up the whole thing as SharePoint the credentials fail on certain components - mostly the configuration and content databases - where it works for other parts of the SharePoint farm.  These are the same credentials that work successfully when I back them up as just a bunch of servers and databases.

I have spent the better part of a month meticulously reviewing the permissions of our BE service account within SharePoint, within SQL, on the farm servers, and the security policy on all the farm servers.  I am fairly confident it has all the right permissions.  However I believe there may be a certificate issue.

I say this because I have installed SQL Server Management Studio on the backup server and it produces the following error when I try to connect to the listener using the BE service account:

"A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.) (Microsoft SQL Server)"

Does BE attempt to make a secure connection to the database listener when it backs up SharePoint? If so, then I believe it may be encountering a similar error when it tries to connect using the same account. In the case of SSMS there is an option to force trust of the server certificate and the connection succeeds when I choose this, but I am not aware of a similar option in BE. Trust is established between BE and both nodes of the SQL cluster, however it is not possible to establish trust with the listener because it's not a real server, just cname of whichever node holds the primary role.  If BE uses a certificate I am not sure how to view it or verify what name might be on it.

Am I on the right path?  How do I troubleshoot the communication between BE and the listener, beyond just succeed/fail of the credentials?

Thanks.

  • I am sorry to advise that while SQL Availability Group support was added in Backup Exec 21.1, that is for SQL Agent backups only. Sharepoint Agent backups do not yet support SQL Availability Groups.

    This mentioned as a note in the start of the 'Agent for Applications and Databases Compatibility' section of the Software Compatibility List (https://www.veritas.com/content/support/en_US/doc/BE_21_SCL)

    • Backup Exec does not support protecting SharePoint Server which has its Databases configured on SQL Always On Availability Groups.

    I understand this can easily be overlooked, if reviewing only the relevant product tables below that.

  • I am sorry to advise that while SQL Availability Group support was added in Backup Exec 21.1, that is for SQL Agent backups only. Sharepoint Agent backups do not yet support SQL Availability Groups.

    This mentioned as a note in the start of the 'Agent for Applications and Databases Compatibility' section of the Software Compatibility List (https://www.veritas.com/content/support/en_US/doc/BE_21_SCL)

    • Backup Exec does not support protecting SharePoint Server which has its Databases configured on SQL Always On Availability Groups.

    I understand this can easily be overlooked, if reviewing only the relevant product tables below that.

    • mhale's avatar
      mhale
      Level 2

      Oh.

      Well that isn't the answer we were looking for but I appreciate it nonetheless.

      I know better than to ask when we might expect support :) however I can't believe we are the only BE users to be running SharePoint in this way.  It is one of Microsoft's recommended configurations, after all.  What I will say is I hope support comes soon before we are forced to consider other solutions.

      Thanks.