Oi pessoal,
Chato e estressante pra caramba quando você fica travado em uma coisa que você não consegue identificar o verdadeiro problema. Suspended states com SharePoint 2013 workflows é um deles, bem difícil de investigar.
Problema
Estava obtendo esse erro pela UI, depois de iniciar o 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))
Por trás esse era o erro com os ULS logs:
Original error: System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Troubleshooting
No meu caso apenas poucos usuários podiam executar os workflows, como Contributors, mas outros não podiam. Eles chegavam ao "Suspended" state. Verificando as permissões dos usuários na Library, de um usuários que podia executar o workflow e de um que não podia, as permissões eram exatamente as mesmas como Contributors.
As permissões não estavam quebradas, possuiam acesso as Listas de Workflow History e Tasks, como indicadas aqui:
http://zasharepoint.blogspot.co.nz/2014/05/sharepoint-2013-workflow-gets-suspended.html
Verificando o User Profile Services, a sincronização dos usuários estava configurada, como sugerida aqui:
http://sharepoint.stackexchange.com/questions/58772/sharepoint-2013-workflow-authentication-error-401
Também explorei essas URLs, mas não tive sucesso:
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
Estava ficando cabuloso.
Solução
Ao fazer uma investigação minuciosa no site, OOTB SharePoint groups estavam mapeando ambos AD Users e AD Groups. Havia uma boa evidência que eu tinha deixado passar despercebida, os usuários que estavam obtendo "suspended" state estavam sendo mapeados por um AD Group.
Quando um usuário foi adicionado manualmente no SharePoint group, o workflow funcionou. :)
Indo um pouco mais além, o AD Group era de um OU diferente que não havia sido mapeado pelo User Profile Synchronization. Quando o OU path foi mapeado e o sync rodado novamente...BANG! Todos os usuários que não podiam rodar o workflow, agora podiam.
Então não é apenas a OU onde os usuários estão que precisa ser mapeada com o User Profile Sync, mas o OU de AD groups também.
Lição aprendida! espero que isso te ajude com troubleshooting!
[]'s,
Marcel Medina
Clique aqui para ler o mesmo conteúdo em Inglês.