23149 Views // 0 Comments // Not Rated

SharePoint 2013 Quick Tips: Workflow And The User Profile Service

I ran into a real annoying scenario where I couldn't use Visual Studio 2012 to build SharePoint 2013 Workflows. Creating the workflow and right-click-deploying its WSP to my local farm worked fine. So I hooked it up to the root web's Pages library of the associated site collection, created a new page, and kicked off an instance of the workflow. When it was done, its status was "Canceled." Here's why:

RequestorId: 0a3d70fc-b1d9-d6f5-c7f1-2f5d04a64970. Details: System.ApplicationException: HTTP 401 {"error_description":"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."} {"x-ms-diagnostics":["3001000;reason=\"There has been an error authenticating the request.\";category=\"invalid_client\""],"SPRequestGuid":["0a3d70fc-b1d9-d6f5-c7f1-2f5d04a64970"],"request-id":["0a3d70fc-b1d9-d6f5-c7f1-2f5d04a64970"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"SPRequestDuration":["15"],"SPIisLatency":["0"],"Server":["Microsoft-IIS\/8.0"],"WWW-Authenticate":["Bearer realm=\"e4932221-7f56-4ba7-b3b7-bbe69deb5565\",client_id=\"00000003-0000-0ff1-ce00-000000000000\",trusted_issuers=\"00000005-0000-0000-c000-000000000000@*,8eb03750-02d7-4d16-90cf-71524403cf6c@e4932221-7f56-4ba7-b3b7-bbe69deb5565,00000003-0000-0ff1-ce00-000000000000@e4932221-7f56-4ba7-b3b7-bbe69deb5565\"","NTLM"],"X-Powered-By":["ASP.NET"],"MicrosoftSharePointTeamServices":[""],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1; RequireReadOnly"],"Date":["Wed, 10 Jul 2013 19:58:19 GMT"]} 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 executor, BookmarkManager bookmarkManager, Location resultLocation)

Jesus. This is basically a lot screaming about a 401. But how could it be a 401? I'm in my local development site, which means I'm the domain administrator logged in via Windows auth. I'm the only user in the farm; how could I ever be denied access? Well, because just like with the app model permissions, the User Profile Service is the default identity provider for SharePoint 2013. You can read more about that here.

The point is that we need a User Profile Service to exist, and within it, a profile for whichever user is performing these actions (weather it's kicking off a workflow or the impersonation context for an app). The research I did to get me this far also elucidated me to that face that in addition to standing up a User Profile Service, I also need to have executed a successful profile synchronization therein. But since I'm running SharePoint 2013 on a domain controller in my local development environment, the sync won't work; the User Profile Synchronization Service simply refuses start under this configuration.

User Profile Sychronization Service

Well, after much consternation, the quick tip here is that you do not need to have a synchronization complete successfully (or even configured) to get workflows to flow work on SharePoint 2013 development machines. Just create profiles for your service accounts, and make sure that the User Profile Service is associated with the "default" Application Proxy Group. Since I was provisioning my service apps via PowerShell, I had omitted the DefaultProxyGroup switch that associates the service app's proxy with this group.

Service Application Associations

This was the missing piece of the puzzle. Once I fixed this in central admin (and updated my PowerShell scripts) everything began to work. Hopefully your service applications are provisioned correctly on your dev box so you don't have to deal with this. My main point, however, is that people shouldn't be discouraged from building local SharePoint 2013 workflows in Visual Studio 2012 because of something that's advertised as not being supported - when in reality, it's not even needed.

No Tags

No Files

No Thoughts

Your Thoughts?

You need to login with Twitter to share a Thought on this post.