Archive

Posts Tagged ‘Configuration’

Configuring Workflow Manager 1.0

June 2, 2013 4 comments

If you have installed Workflow Manager 1.0 and everything went through successfully, at the end of the installation process, you should be presented with a configuration screen that will allow you to create a new Workflow Manager farm with default or custom settings OR join the computer on which you just installed Workflow Manager to an existing farm. To review the installation process, check out Installing Workflow Manager 1.0.

This article covers the configuration process using the Configuration wizard UI. If you are interested in running configuration through the Workflow Manager PowerShell console, refer to this post.

Before you proceed, ensure that the account that you are logged in as to configure Workflow Manager has sysadmin role on the instance of SQL Server where the Workflow Manager and Service Bus databases will be created. Configuration will be performed according to the steps outlined here.

Choose the option on the Configuration Wizard to install Workflow Manager with Custom Settings

clip_image001

On the following screen, for SQL Server Instance, choose the options as shown below and click Test Connection. If the connection is successful, a green check mark icon should be seen. Expand the Advance Options section and ensure Windows Authentication is selected and that the option to Use the above SQL Server Instance and settings for all databases is checked. We shall not use SSL for this particular installation.

clip_image002

Provide database names as shown below (I am using default names here) for the workflow, instance and resource management databases. Clicking on the Test Connection button each time will allow ensuring that the database names are not already used.

clip_image003

Scroll down to configure the service account that will be used to run the Workflow Manager and Service Bus services. Provide inputs as shown below.

clip_image004

This installation procedure allows Workflow Manager to generate its own certificates. Provide the Certificate Generation Key and retype it to confirm as shown below.

clip_image005

In the port configuration section, leave the default port selections for HTTPS and HTTP. Check the box to allow communication over HTTP. NOTE: This is being done as part of the current installation process since this is a non-Production environment. It is not recommended per the TechNet article to allow workflow management over HTTP in a Production environment. Uncheck the Enable firewall rules on this computer checkbox.

clip_image006

Next, specify the group that will be given access to all Workflow Manager databases. I am using the local admin group; on a full-fledged farm, a group with all farm administrators would make sense. Then click on the Next button to proceed to Service Bus Configuration.

clip_image007

On the Service Bus Configuration page, set the database names again as shown below. These are not the default names here, by the way. I did some clean up to have the names look consistent and remove the monikers “DB” or “Database” from them since that part is evident.

clip_image008

For the service account and certificate key, choose the same ones that were provided for the Workflow Manager configuration

clip_image009

For the port configurations, leave in place all the default port numbers. Uncheck the Enable firewall rules on this computer box.

clip_image010

NOTE: The firewall rules checkbox has been unchecked for both the Workflow Manager and the Service Bus because checking this box will cause the configuration wizard to try and edit the firewall rules on the computer. However, the firewall on the target server is set to Off. The setting made above is to skip the firewall rule setting. If the firewall, is turned back on, rules will need to be put in for each of the ports configured above. Otherwise, the workflow manager and service bus services may not respond correctly.

Finally, configure the admin group that will receive access to all Service Bus databases as shown below and click on the Next button to proceed.

clip_image011

The next screen provides a summary of all of the settings and selections made. Go through them to ensure that the right selections have been made for Workflow Manager.

clip_image012

Scroll down to view the settings and selections for the Service Bus as well. Once satisfied with all the settings made, click on the Check button at the bottom of the screen to proceed.

clip_image013

NOTE: You can copy a text manifest of all the settings made by using the Copy link at the bottom of the page. You can also, use the Get PowerShell Commands link to get the complete configuration process given out in script that you can quit the wizard and execute through the Workflow Manager PowerShell console to complete configuration. If you prefer using PowerShell, copy the commands now and refer to this article.

If you choose to carry on in the wizard, at this point the configuration process kicks off and goes through with the farm provisioning. If all goes well and configuration is successfully completed, the UI will display check marks against all stages and we may then proceed on to the step where SharePoint is configured to leverage Workflow Manager services.

clip_image014

If you have everything set up correctly, you should be able successfully add the Service Bus and Workflow Management farms and add the host to both. However, sometimes, a problem might occur during configuration that will require fixing before configuration can be run again. To check the workarounds or solutions to a couple of problems that I have faced and documented, refer here.

If everything got configured correctly, the Workflow farm should be ready to be consumed by clients such as SharePoint 2013. To learn how to configure SharePoint 2013 to consume the workflow services, please check out Configuring SharePoint 2013 to use Workflow Manager 1.0.

Advertisements

Configuring Workflow Manager 1.0 using PowerShell

June 2, 2013 1 comment

This post covers the process of configuring Workflow Manager 1.0 using PowerShell. It assumes that Workflow Manager 1.0 has already been installed. To get the step by step on the installation procedure, check this article. In Configuring Workflow Manager 1.0, I have detailed the post installation configuration process of the Workflow Manager product through the Configuration Wizard UI. If however, you like me, are the kind of person that would like to monitor as many steps along the process as you can, you may want to run configuration through PowerShell. Note that while you can follow the commands purely as shown in this article, and make required changes for your environment, it would be easier to refer to the configuration post and use the wizard to make all the settings but not run it. Instead, at the end of that article, you can see how the PowerShell commands based on the settings made are handed to you by the wizard so you can copy them, close out the wizard and move on to the console.

You can run the entire configuration process through a script that the configuration wizard provides you as mentioned above. All you need to do to generate this script is use the Get PowerShell Commands link on the Summary page. There are a couple of good reasons for using PowerShell instead of the wizard based configuration process

  1. You can run each command, verify the outcome and move on to the next step confidently.
  2. Error handling becomes easier since it is very evident what specific operation failed and you can resume after the last successful step.

If you have already copied, the PowerShell commands provided by the configuration wizard, you may have to or want to make some changes to it before you proceed. The following are the changes I made.

  1. If you open the commands, you will notice that text at the places where the RunAs account password or the certificate generation key are used have been replaced with some placeholder text (which looks like this – ‘***** Replace with Workflow Manager Certificate Auto-generation key *****’) so as not expose those. This will need to be corrected.
  2. The script instantiates a couple of references to hold the certificate generation key – $WFCertAutoGenerationKey and $SBCertificateAutoGenerationKey. These are used in the New-SBFarm, New-WFFarm, Add-WFHost and Add-SBHost commands to follow. It does this because this allows using different certificate auto-generation keys for each service. If you wish to use the same certificate, you can eliminate one of these statements and make sure you use the variable from the other in both commands.
  3. The same as above holds true for the RunAsPassword. One of these can be removed and the variable from the other statement can be used in both the Add-SBHost and Add-WFHost commands.
  4. Once all of this is done, you may choose to save the script as a PS1 file and run the entire set of commands at once through the console or type each command individually.

To start configuration, launch a new Workflow Manager PowerShell console. You should find a shortcut to this in the Workflow Manager 1.0 program folder in the Start menu. If not, you could navigate to %ProgramFiles%\Workflow Manager\1.0\Scripts and run StartWFConsole.cmd. Either way, you’ll end up launching Windows PowerShell with the WorkflowManager module imported.

clip_image001

STEP 1 – Get a secured string for the Certificate Generation Key

clip_image002

STEP 2 – Create a new Service Bus farm

clip_image003

In progress…

clip_image004

… and done.

clip_image005

STEP 3 – Create a new Workflow Management farm

clip_image006

In progress…

clip_image007

… and done.

clip_image008

STEP 4 – Get secure string for the super-secret password

clip_image009

STEP 5 – Add this host to the service bus farm

clip_image010

In progress. The part where the service bus services are started may take a while. This is where the Service Bus Gateway and the Service Bus Message Broker are being spun up. This is also the most troublesome part of the entire configuration process.

clip_image011

And done.

clip_image012

The farm information now looks as shown below

clip_image013

If you face any challenges with the addition of the host to the service bus farm, please check this post to see if you are having a problem similar to the ones documented. If everything went alright, you can proceed on to the next step.

STEP 6 – Create a namespace on the Service Bus to be used by Workflow Manager. Couple of things to note here.

First, you can call this namespace anything as long as you ensure you use the same name in the client configuration parameter you use when adding the host to the Workflow Manager farm.

Second, if you copied the configuration PowerShell from the wizard, it does some exception handling and implements a wait after the New-SBNamespace cmdlet is called presumably to allow the time it takes for the instantiation to complete before we proceed on to getting a client configuration based on it. I am not doing any of this below because I am running each command in sequence and can manually handle these things.

clip_image014

STEP 7 – Get a client configuration for the namespace just created. This provides you an XML structure that can be used by the Workflow Manager client to establish connections and communicate with the Service Bus.

clip_image015

STEP 8 – Finally, add the current host to the Workflow Manager farm. This usually goes through without a hitch and completes the configuration. At least on the Workflow Manager.

clip_image016

So you see a couple of HTTPS and HTTP endpoints. Let’s take a quick look at IIS Manager to see if these show up correctly. As you can see below, there is now a Workflow Management site on IIS that is bound to port 12290 for SSL and 12291 for HTTP based communication.

clip_image017

One final piece of verification is to hit up the workflow endpoint over HTTP in a browser. And everything looks good.

clip_image018

If you’ve gotten this far, you are done with the farm creation process and the addition of the host to the farms. The Workflow Manager farm should be online and humming merrily at this point. But if your original intent for the farm was to lend its cool new features to SharePoint 2013, check out how to Configure SharePoint 2013 to use Workflow Manager 1.0 services.

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.

clip_image001

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.

clip_image002

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.

clip_image003

When I tried to check the proxy status

clip_image004

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 *

clip_image005

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.

clip_image006

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.

clip_image007

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.

clip_image008

Splendid. Now to check on the proxy settings.

clip_image009

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.

clip_image010

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.

clip_image011

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

clip_image012

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.

clip_image013

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.

%d bloggers like this: