Hi

I have a SharePoint 2013 site called "Team Meetings". There are a number of lists and an InfoPath form library.

The site's SharePoint Group "Team Meeting Members" has two Active Directory groups (All Club Managers and All Club Police) as members. Those two AD groups contain all the people that I want to have  access to the library and list, except for a few additional folk who I have made individual members. 

My PROBLEM:

I  have created a SharePoint 2013 Workflow using SPD 2013 associated with the  Form Library. Workflow is set to start on new or modified item. The first action is to write to history list, then determine the status (Submitted or Pending) of the form and go to different Stages depending on that status.

The workflow works perfectly for any user who has been added directly to the SharePoint group (Team Meetings Members) BUT FAILS at the very first action for anyone who is a member of one of the AD groups. I know the Workflow is fine because I've tested it with numerous people who are direct members of the SharePoint Group, but whenever a person who is a member of the AD group tries it the Workflow just fails.

Here's a print of the info from the Workflow Status page (I don't have access to server logs):

 

RequestorId: 4494760f-92ff-2e8c-90d2-cc7df0e6baa4. Details: System.ApplicationException: HTTP 401 {"Transfer-Encoding":["chunked"],"X-SharePointHealthScore":["0"],"SPRequestGuid":["4494760f-92ff-2e8c-90d2-cc7df0e6baa4"],"request-id":["4494760f-92ff-2e8c-90d2-cc7df0e6baa4"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"MicrosoftSharePointTeamServices":["15.0.0.4420"],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1; RequireReadOnly"],"Cache-Control":["max-age=0, private"],"Date":["Mon, 10 Mar 2014 01:31:42 GMT"],"Server":["Microsoft-IIS\/8.0"],"WWW-Authenticate":["NTLM"],"X-AspNet-Version":["4.0.30319"],"X-Powered-By":["ASP.NET"]} The HTTP response content could not be read. 'Error while copying content to a stream.'. at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor 

Members of the SharePoint Group "Team Meetings Members" have Contribute Access to both the form library and another list that the workflow writes to as well as the Workflow History list (which in SP 2013 uses the credentials of the user who started the workflow, unlike 2010 which used System Account).

All members of the Team Meetings Members group, whether they are individual members or part of one of the AD groups, have no problems opening and saving forms etc. It's just the Workflow that doesn't like them...

I am stumped. I've spent many hours searching for a reason for this. There are about 200 people in the two AD groups so I really don't want to have to add them all individually - especially when these groups are managed in AD for a whole bunch of other reasons and using the AD groups means I'll basically never have to worry about modifying the SharePoint access permissions.

Does anyone have any ideas why this is happening and what I can try to f

Hi emjem,

According to my understanding, permission issue occured. I suggesting you to check the user permission in first step of workflow. Usually in 2010 workflow we can use "Find Manager of this user(Output to Variable: Manager)", if user permission is not enough, you can assign appropriate permission dynamically to that user using Impersonation step. I don't have much idea in 2013 designer workflow regarding this, but I strongly believe this will work in 2010 designer workflow.

I hope this may help you out!

Hi Sam Thanks but SharePoint 2013 workflows do not have the impersonation function so I can't use that work around. Hopefully someone else will have the answer....

Mark,

But you can create 2010 workflow in SharePoint 2013, then why cant you try with that? thanks.

Hi

Yes I could do that, but then I'd have to recreate about 20 workflow variables and I couldn't use the great goto stage functionality. I'd really rather figure out why the workflow doesn't like Active Directory groups... If it turns out that is a design feature by.Microsoft I would be surprised, and I'd have to add about 150 users to the SharePoint group but I'd rather do that than go back to a SP2010 workflow to be honest.

I appreciate your thoughts though.

Hi Mark

We just moved from SharePoint 2010 and ran into the same issue. No Problem with 2010 Workflows. 2013 workflows are not starting due permission problems. Our permission setup: AD-Users are in an AD-Group and the AD-Group is linked to the SharePoint Group. If I place the AD-User directly in a SharePoint Group then the workflow starts.

Do you have a solution in the meantime?

Lars

Hi Lars,

I'm afraid not so far but we are trying a few things today so I will post back with results.

First thing we are doing is making the AD Group universal because one of our (external provider) gurus remembers seeing something about that. He also sent me a link to a post where they were talking about earlier versions but having similar issues and their solution was to make sure the app pool account has sufficient permissions in AD::

http://social.msdn.microsoft.com/Forums/sharepoint/en-US/27a547da-5cc0-49d7-8056-6eb40b4c3242/failed-to-start-workflow-access-is-denied-exception-from-hresult-0x80070005-eaccessdenied

This part of that thread looks interesting but we haven't checked it yet as were trying the universal setting first:

• "If the users participating in the workflows have been added to the SharePoint site via Active Directory groups, SharePoint has to update the users security token periodically by connecting to the domain controller. By default, the token times out every 24 hours. But if the application pool account did not have the right permissions on the domain controller to update the users token, user will keep getting the access denied error. The error was intermittent because when the user browsed to any page other than the workflow form, the token was getting updated successfully.

 

You can try to fix it through granting the application pool account the appropriate permission by adding the account to the group Windows Authorization Access Group in Active Directory."

_----------------------------------------------

I'll update when we try these ideas. If you have any luck please do the same.

Mark

(sorry about formatting - using my phone....)

 

Hello Mark,

We have similar issue, 

Could you please confirm if the above steps worked for you. 

Please let me know if you have found the solution for this issue.

----------------------

Masthan