Home > SharePoint 2013, Workflow Manager > Configuring SharePoint 2013 to use Workflow Manager 1.0

Configuring SharePoint 2013 to use Workflow Manager 1.0

This article covers the final step in the process of setting up SharePoint 2013 for the new workflow platform for SharePoint 2013 workflows. This is where SharePoint is connected to Workflow Manager services.

This post assumes you have already installed the Workflow Manager product and configured the Workflow Manager and Service Bus farms using either the Configuration Wizard or through PowerShell. Here, we shall go ahead and set SharePoint up to use the Workflow farm. Based on whether SharePoint is collocated with the Workflow Manager and whether communication between SharePoint and Workflow Manager over HTTP is allowed, the steps through which this configuration is performed are different and are documented here. For the configuration in this instance we are using SharePoint on the same farm as Workflow Manager and communication over HTTP is allowed.

Configuration on SharePoint is about creating a service application proxy for workflow that has the service endpoint configuration for the Workflow service. This is done through the use of the Register-SPWorkflowService cmdlet in the SharePoint Management Shell. There is no UI based way of creating this proxy through the Central Administration application.


Before we proceed to do this however, let’s take a look at a few things. Here, I am using the Get-WFScope cmdlet to view the scope at the root of the workflow service endpoint. Note: In order to get scope details you’d need to know the ScopeUri of the scope you’re accessing. Without knowing what scopes are on the instance, it is hard to know or remember all the URIs. There is no way to list available scopes through existing cmdlets. Here’s a PowerShell script that helps with this.


When we create a Workflow Service Application proxy, we add a combination of a SharePoint site collection and the URI of the scope in the workflow service that it is bound to. Looking at the above, we see that there is just one root scope at this point with no child scopes.

Typically, there would not be a Workflow Service Application or proxy on a fresh new SharePoint environment. Because of whatever experimentation I was doing on my trial environment, I already did have a pair.


When I tried to check the proxy status


This is understandable since I have not made the connection with the workflow service yet. Just so I understood how this was set up, I ran the following from the SharePoint Management Shell.

Get-SPWorkflowServiceApplicationProxy | Format-List *


This didn’t tell me much – in fact it told me it was Online which it quite clearly was not and could not be. So I tried the following set of commands.


Both scope name and service address come up null. Again, since we have not made the connection with the workflow service yet. I have the option of deleting this proxy set up and starting afresh. Just to see how Register-SPWorkflowService would respond to the existence of the proxy, I went ahead without deleting it.


And it went through just fine. Or so it seems from the silent return on the command above. So let’s verify.

First, on refreshing the proxy management page on Central Administration.


Splendid. Now to check on the proxy settings.


Nice. You can see that a new scope called SharePoint has been created and its address has been bound to the proxy. Let’s hit up this URI in the browser for a second.


Very cool. There is obviously a lot more going on here than when we hit the root scope URI. One thing that pops out is how the security configuration type is OAuthS2SSecurityConfiguration. This is why we used the AllowOAuthHttp switch parameter when running Register-SPWorkflowService. But all that for a different discussion. Next, a quick look again at the root scope.


Now checking for the scope in question – the one called SharePoint that is apparently connected to the proxy on SharePoint.


How do we know this is linked to the proxy we were looking at? Notice the GUID in the UserComments property? Compare that with the Id property of the service application proxy that we got above from running Get-SPWorkflowServiceApplicationProxy. But to have the proof of the pudding, let’s go get the “after” picture on SharePoint Designer 2013.


The default platform choice now is SharePoint 2013 Workflow. This means our configuration went through fine and we are done.

Update [6/20/2013]: Sometimes it has been found after all configuration has been completed that the platform selection doesn’t show up in SharePoint Designer 2013. If you have gone through all of the validation steps above to ensure that the connection has been made right, there’s no need to panic. Here are a couple of additional steps that help with troubleshooting…

1. If you are on a multi-server environment and you set up Workflow Manager on an app server, you have to remember that when you use SharePoint Designer, that works with your web server and therefore, in order to make a connection to the Workflow Manager end points, it will need the Workflow Manager client. Make sure you have installed Workflow Manager client on all of your farm servers.

2. Sometimes, it requires an IISReset on the server just to shake things up and get them connected properly. There are people who have reported not seeing the SharePoint 2013 Workflow option after configuration and come back the next day to find it magically appear. This is likely because their app pools got recycled overnight. Definitely worth a shot.

  1. October 30, 2013 at 4:29 AM
  2. Ernesto
    January 27, 2014 at 8:42 AM

    Thank you, very useful!

    We are using Sharepoint 2013, and it turns out we got 2 service proxies instead of 1! Simply deleted the service application and re-run the association script and that got it running.

  3. Ernesto
    January 27, 2014 at 8:43 AM

    I meant Sharepoint 2013 in Spanish, and we got one proxy with English name and one with Spanish name.

  4. Maya
    April 8, 2014 at 3:39 AM

    Thanks a lot for your detailed and useful explanation
    you made my day 🙂

  5. Eric
    October 15, 2014 at 7:55 PM

    Thanks for the article, clearly a little known area…to address the question of “waiting overnight” see this: http://blogs.technet.com/b/projectsupport/archive/2014/01/13/sharepoint-2013-workflow-token-contains-invalid-signature.aspx
    it has worked for me.

  6. Christian De-Nardi
    November 25, 2014 at 10:16 AM

    I used the cmdlet Register-SPWorkflowService without error but my workflow still NOT connected.

    My Workflow Manager 2013 is in English but My Sharepoint is a french version. Can it be the reason why my WF is not connected??? weird

    • February 26, 2016 at 2:49 AM

      Hi all, I have the same setup as Christian de-nardi ( SP in FR and Workflow manager in ENG) and the same problem as him Have you found a solution ?

      Thanks for your help

  7. Abhi
    September 29, 2015 at 1:28 PM

    Can I remove SharePoint server and register it again?

  8. February 26, 2016 at 2:48 AM

    Hi all, I have the same setup as Christian de-nardi ( SP in FR and Workflow manager in ENG) and the same problem as him Have you found a solution ?

    Thanks for your help

  1. December 12, 2013 at 6:34 AM
  2. February 12, 2015 at 6:58 AM

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: