Hi guys,
It is really annoying when you get stuck on something that you cannot identify the real source of the problem. The suspended state with SharePoint 2013 workflows is one of them, really difficult to troubleshoot.
Problem
I was getting this error from the UI, after starting the workflow:
(RequestorId: 0cd909bf-f85a-1da7-0000-000000000000. Details: RequestorId: 0cd909bf-f85a-1da7-0000-000000000000. Details: An unhandled exception occurred during the execution of the workflow instance. Exception details: System.ApplicationException: HTTP 401 {"error":{"code":"-2147024891, System.UnauthorizedAccessException","message":{"lang":"en-US","value":"Access denied. You do not have permission to perform this action or access this resource."}}} {"Transfer-Encoding":["chunked"],"X-SharePointHealthScore":["0"],"SPRequestGuid":["0cd909bf-f85a-1da7-b6a7-48f3d5618b90"],"request-id":["0cd909bf-f85a-1da7-b6a7-48f3d5618b90"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"Cache-Control":["max-age=0, private"],"Server":["Microsoft-IIS\/8.0"],"WWW-Authenticate":["Negotiate","NTLM"],"X-AspNet-Version":["4.0.30319"],"X-Powered-By":["ASP.NET"],"MicrosoftSharePointTeamServices":["15.0.0.4481"],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1; RequireReadOnly"],"Date":["Tue, 25 Nov 2014 01:13:50 GMT"]} at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContextSystem.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation))
Behind the scenes from SharePoint ULS logs:
Original error: System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Troubleshooting
In my case only few users were able to trigger workflows, as Contributors, but others couldn't. They were getting to this "Suspended" state. By checking the user permissions on the Library, of a user that could execute the workflow and one that couln't, permissions were exactly the same as Contributors.
Permissions were not broken, they had access to Workflow History and Tasks Lists, as indicated here:
http://zasharepoint.blogspot.co.nz/2014/05/sharepoint-2013-workflow-gets-suspended.html
By checking the User Profile Services, the synchronization of users were in-place, as suggested here:
http://sharepoint.stackexchange.com/questions/58772/sharepoint-2013-workflow-authentication-error-401
I had also explored these URLs, with no success:
https://social.technet.microsoft.com/Forums/sharepoint/en-US/8671e31e-fde2-454c-aba4-0fc6484dd873/sharepoint-2013-workflow-suspend-with-401-error?forum=sharepointcustomization
https://social.technet.microsoft.com/Forums/sharepoint/en-US/653dcf25-131e-402a-9fd1-f0b3e60e7750/suspended-workflow-in-sharepoint-2013-with-http-401-error?forum=sharepointadmin
This was getting tricky.
Solution
By doing a thorough investigation in this site, OOTB SharePoint groups were mapping both AD Users and AD Groups. There was a good evidence there that I had overlooked, users that were getting to a suspended state were mapped by an AD Group.
When the user was manually added to the SharePoint group, the workflow worked. :)
Going a little bit further, the AD Group was from a different OU that wasn't mapped in the User Profile Synchronization. When the OU path was mapped and the sync was run again...BANG! All the users that couldn't run the workflow, now could.
So it is not only the OU where the users are that need to be mapped with User Profile Sync, but the AD groups OU as well.
Lesson learned! Hope it helps with your troubleshooting!
Cheers,
Marcel Medina
Click here to read the same content in Portuguese.