I have been working on an issue at my client site for a while around SharePoint 2013 workflows failing immediately after starting. When they failed the error from the WF status screen contained:
Details: An unhandled exception occurred during the execution of the workflow
instance. Exception details: System.ApplicationException: HTTP 401
denied. You do not have permission to perform this action or access this
Pretty self explanatory I thought when I first started working on it. The user starting the WF didn’t have the necessary rights to one of three key places: the list containing the workflow, the workflow tasks and history lists or workflow.aspx (found in /<site>/_layouts/15/workflow.aspx). Checked those locations and the user had the necessary access. So started digging a bit deeper.
Up to this point I had been using active directory groups for all user access to the site. I decided to start using individual users as this would allow for easier testing. Suddenly things started to work just fine. Workflows would initiate and complete as expected. After a great deal of more testing it was determined the problem was that SharePoint 2013 WFs wouldn’t work with AD groups at all. We could give the group full control of the site, but any user contained within could not kick off a workflow. While investigating I came across a support forum post going on a couple of years that had a number of people with the same problem as we were experiencing (you can review the forum post here)
To make a long story short, the problem finally was determined to be the AD groups we were using in the SharePoint sites were not being pulled into SharePoint. We had Users and Groups selected within our UPS so everything should have been pulled in. To determine this I ran a query against our UPS profile database.
Quick disclaimer: you void your warranty by changing the SharePoint DBs directly. This query does not make any changes and it was provided to me by Microsoft so I can’t take all the credit ;-p
-- Return group members (all members of a specific group) select mg.displayname as GroupName, mg.Id as GroupID, mg.SourceReference as GroupDN, upf.ntname as UserName, upf.PreferredName, upf.RecordID as UserID from userprofile_full upf join usermemberships um on upf.recordid = um.recordid join membergroup mg on um.membergroupid = mg.id where mg.displayname like '%SharePoint_Testers%' order by mg.displayname, upf.ntname
When I ran this query nothing came back. However, when I ran the query again after removing
where mg.displayname like '%SharePoint_Testers%'
all kinds of groups came back. They were all contained withing the Users OU of our AD. The groups we use for SharePoint are in their own OU. We had earlier confirmed the UPS settings had the SharePoint OU selected, but based on this it appeared to not actually be pulling them in.
The final fix? We simply unchecked and rechecked the OU we wanted and reran the UPS sync. Ran the above query again and the database now had all the groups and the members of the groups within it. I tested the workflows again and running them as I had planned (with AD groups). Everything ran fine.
I have said it before and will say it again: SharePoint User Profile Services is the flakiest service within SharePoint. I haven’t played with it yet in SharePoint 2016, but I hope they have made more improvements beyond replacing FIM.
I hope this solution helps you. It certainly helped us when we didn’t expect a nice fix.
Thanks for reading!!