Issue

When trying to deploy in K2 Studio the following error occurs:

"The "SourceCode.SharePoint15.DeploymentTask.Task" task failed unexpectedly. System.Exception: Service: SharePointIntegration Service Guid: 71810da1-81e2-4f22-8cf2-4011dacfdf42 Severity: Error Error Message: Access denied. You do not have permission to perform this action or access this resource."

Symptoms

The error message showed details in regards to "Event Receiver". Due to this we executed the SharePoint Integration Helper Methods SmartObject and received an error that access was denied.

Afterwards we enabled SmartObject logging to track SMO and discovered brokerpackageIN.log and servicepackageIN.log.

The only output was brokerpackageOUT.log which only reflected the Access Denied error message. This meant that the error happened in SharePoint and we needed to inspect the ULS logs.

This didn't result in a match. However, in the User Profile Services Application (in SharePoint Central Admin), the "Connections" tab couldn't be opened which gave us more information.

Due to a recent migration, we discovered that there were leftover Event Receivers from a previous DB. The SmartObject responsible for creating Event Receivers was the "Event" SmartObject under the Management category of the Site Collection.

That SmartObject was executed, specifically the "Get List of Receivers" method, (the list GUID,which we got from clicking the "K2 Application" button in the ribbon bar and copying it from the address bar.) We discovered 3 event receivers registered, and trying to remove them resulted in an "Access Denied" error.

Resolution

Using a Powershell script modified to the environment, we removed all the event receivers and the workflow could be deployed. However, the workflow couldn't start after this. This was due to leftover workflows that don't exist in K2 Workspace anymore but are still in SharePoint, found in the following table in the K2 database: [K2].[Integration].[ProcessSharePointWorkflow].

After removing the old workflows, the workflow was deployed again, which recreated the entry in the abovementioned table, and also registered the new Event Receiver.