Insufficient SQL database permissions for user 'Name: NT AUTHORITY\SYSTEM SID: S-1-5-18 ImpersonationLevel: None' in database SP_ConfigDB

Question

I have this error on each server of SharePoint Farm(APP, WFE, Search).

Full message:

Insufficient SQL database permissions for user 'Name: NT AUTHORITY\SYSTEM SID: S-1-5-18 ImpersonationLevel: None' in database SP Config DB on SQL Server instance 'XXX'. Additional error information from SQL Server is included below.

The EXECUTE permission was denied on the object 'proc_getObject', database 'SP Config DB', schema 'dbo'

I don't think that it is a duplicate because the following steps weren't helpful.

Expand your SharePoint Configuration database 'SharePoint_Config' and navigate to ‘proc_getObject’ under Programmability ->Stored Procedures Right-click proc_proc_getObject and choose Properties Click on Permission on the left launch Select the Search button and browse for ‘WSS_Content_Application_Pools’ Provide ‘Execute’ permissions for ‘WSS_Content_Application_Pools’ Click OK

NT AUTHORITY\SYSTEM SID: S-1-5-18 is the LOCAL SYSTEM account.

SPDataAccess and WSS_Content_Applications_Pools db roles have Execute(dbo) permissions to this stored procedure.

Any ideas?

Update

It triggered by task scheduler job "Desired State Configuration - > Consistency"

Answer 1

I was curious to know how PowerShell.exe or PowerShell_ISE.exe processes are linked to Category of Upgrade in ULS log. Because, in our SharePoint 2013 on-prem farm, all databases' Upgrade Statuses are showing No action required. So, it doesn't make sense to me that it is related to any upgrade or SharePoint patching.

What I have found out is (I was not aware before) that launching "SharePoint 2013 Management Shell" or Window PowerShell ISE and then adding Microsoft.SharePoint.PowerShell PSSnapin creates ULS log items of Upgrade category, which might be confusing. Also, noticeable is that a connection to SharePoint Configuration database is also made, as can be seen in the log with the same correlation id.

Having said that, in your case, you may need to find out what process (or manually?) starts/launches the PowerShell process. Is the error being repeated with a specific time interval? If it does repeat at the same time every day then it would be worth to compare SharePoint TimerJobs' LastRunTime with the ULS logs' timestamps to figure out what job is involved, if any.

Answer 2

I figured out that it is triggered by Microsoft planning task - "Desired State Configuration - > Consistency".

Action: -NonInt -Window Hidden -Command "Invoke-CimMethod -Namespace root/Microsoft/Windows/DesiredStateConfiguration -Cl MSFT_DSCLocalConfigurationManager -Method PerformRequiredConfigurationChecks -Arguments @{Flags = [System.UInt32]1}"

Then I run PS command Get-DscConfiguration and find out that "Snow Inventory Agent" is involved.

Workaround: Configure "Desired State Configuration - > Consistency" job to run under SP Farm account(local admin + dbOwner).

If you know more elegant way, please suggest.