SqlException (0x80131904): profile name is not valid or Error 14607 Procedure: 'sp_send_dbmail'
Recently I needed to patch my SharePoint 2013 on-premises environment with the August 2019 Cumulative Update (CU). After the binaries were installed on my farm, I proceeded to run the SharePoint Products and Configuration Wizard (henceforth, Config Wizard) to complete the process. Inevitably, this is where most SharePoint patches fail, but it usually takes a long time to do so. But this time, the failure was almost immediately, specifically Step 2 out of 10.
Symptoms and Error Messages
The error message indicated Exception: System.Data.SqlClient.SqlException (0x80131904): profile name is not valid. and gives you the link to the error log as shown below.
A review of the log didn't really provide any other details. After restarting the necessary SharePoint services, I was able to get back into Central Administration. I increased the logging level to Verbose to try and get more information about the error. Restarting Config Wizard and using a ULS Viewer to catch the error can be a tricky practice. Watching Config Wizard for the error to occur and go back to the ULS Viewer and select Pause. Filter your results to Critical or Error to try and narrow down only the useful information. And there it was: SqlError: 'profile name is not valid' Source: '.Net SqlClient Data Provider' Number: 14607 State: 1 Class: 16 Procedure: 'sp_send_dbmail' LineNumber: 141 Server: The "sp_" in front of that procedure is your clue this is SharePoint related.
Tip: Make sure you turn down your ULS diagnostic levels to the defaults now you have found the needle in a haystack.
Doing more research, this kind of error pointed to SQL DBMail not having a public profile for the account running Config Wizard (which should be your SharePoint Farm account). But in the 17 years of doing SharePoint patching, I had never run across this issue and this patch, with the exception of a pointless advertisement breaking Central Administration home pages, worked fine in my test environment.
Cause and Solution:
After speaking with my DBA, he had implemented a new SQL Trigger to email him whenever a new database was added or an existing database modified on the SharePoint SQL cluster. Unfortunately for me, he did not give the SharePoint Farm service account permission to it. This caused the Config Wizard to fail when it needed to gain exclusive access to a stored procedure as part of the patching process.
Symptoms and Error Messages
The error message indicated Exception: System.Data.SqlClient.SqlException (0x80131904): profile name is not valid. and gives you the link to the error log as shown below.
A review of the log didn't really provide any other details. After restarting the necessary SharePoint services, I was able to get back into Central Administration. I increased the logging level to Verbose to try and get more information about the error. Restarting Config Wizard and using a ULS Viewer to catch the error can be a tricky practice. Watching Config Wizard for the error to occur and go back to the ULS Viewer and select Pause. Filter your results to Critical or Error to try and narrow down only the useful information. And there it was: SqlError: 'profile name is not valid' Source: '.Net SqlClient Data Provider' Number: 14607 State: 1 Class: 16 Procedure: 'sp_send_dbmail' LineNumber: 141 Server: The "sp_" in front of that procedure is your clue this is SharePoint related.
Tip: Make sure you turn down your ULS diagnostic levels to the defaults now you have found the needle in a haystack.
Doing more research, this kind of error pointed to SQL DBMail not having a public profile for the account running Config Wizard (which should be your SharePoint Farm account). But in the 17 years of doing SharePoint patching, I had never run across this issue and this patch, with the exception of a pointless advertisement breaking Central Administration home pages, worked fine in my test environment.
Cause and Solution:
After speaking with my DBA, he had implemented a new SQL Trigger to email him whenever a new database was added or an existing database modified on the SharePoint SQL cluster. Unfortunately for me, he did not give the SharePoint Farm service account permission to it. This caused the Config Wizard to fail when it needed to gain exclusive access to a stored procedure as part of the patching process.
