locked
The EXECUTE permission was denied on the object 'proc_putObjectTVP', database 'MSSQL', schema 'dbo' RRS feed

  • Question

  • While trying to create a custom SharePoint timer job at feature activation I got the following error from the log files:

    System.Data.SqlClient.SqlException (0x80131904): The EXECUTE permission was denied on the object 'proc_putObjectTVP', database 'MSSQL', schema 'dbo'.     at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)     at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)     at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)     at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)     at System.Data.SqlClient.Sql... 5c6d109c-dbc6-e02e-7ae4-010d7f559e0b

    In order to make it work i located the stored procedure proc_putObjectTVP and granted execute permission to the site apppool userID. It worked as desired.

    My question is:

    1. Is this a bug in Sharepoint 2013?
    2. Is this the proper way to do it? (On production environment I may not be allowed by the server administrator to perform such operations)

     

    Monday, April 15, 2013 9:50 AM

Answers

  • Firstly, you should not be modifying database objects or use DDL statements against any of the SharePoint databases as such an action puts your farm in an unsupported state. Are you activating the feature from SharePoint UI or through PowerShell?

    Registering a timer job definition involves update to the SharePoint Configuration database to which the application pool identity of the web application is only granted WSS_CONTENT_APPLICATION_POOLS role, and will not have Shell Admin or db_owner rights. I believe this was so even in 2010 and aligns with the principle of least privileged access.

    Timer Job definitions may be registered through PowerShell whose process account on the server would have Shell Admin access on all databases.


    This post is my own opinion and does not necessarily reflect the opinion or view of Slalom.



    • Edited by Guru Karnik Tuesday, April 16, 2013 7:29 PM typo
    • Marked as answer by Vivek Sisodiya Monday, April 22, 2013 1:05 PM
    Tuesday, April 16, 2013 7:23 PM

All replies

  • Firstly, you should not be modifying database objects or use DDL statements against any of the SharePoint databases as such an action puts your farm in an unsupported state. Are you activating the feature from SharePoint UI or through PowerShell?

    Registering a timer job definition involves update to the SharePoint Configuration database to which the application pool identity of the web application is only granted WSS_CONTENT_APPLICATION_POOLS role, and will not have Shell Admin or db_owner rights. I believe this was so even in 2010 and aligns with the principle of least privileged access.

    Timer Job definitions may be registered through PowerShell whose process account on the server would have Shell Admin access on all databases.


    This post is my own opinion and does not necessarily reflect the opinion or view of Slalom.



    • Edited by Guru Karnik Tuesday, April 16, 2013 7:29 PM typo
    • Marked as answer by Vivek Sisodiya Monday, April 22, 2013 1:05 PM
    Tuesday, April 16, 2013 7:23 PM
  • Thanks Guru, it helps!
    Monday, April 22, 2013 1:06 PM