Workflow Manager Farms for SharePoint 2013 Part Four: End to End Configuration using Domain CA issued certificates

Print | posted on Friday, August 02, 2013 9:44 AM

In the previous parts of this article we covered the core concepts and critical considerations, creating a Workflow Manager Farm using Auto Generated Certificates and converting that farm to use Domain CA issued certificates.

This part will cover the end to end configuration of a Workflow Manager Farm using Domain CA issued certificates. This is of particular importance to those who have an organisational policy in force which prohibits the use of self signed or auto generated certificates. Whilst we can change an existing farm which uses auto generated certificates to use Domain CA issued certificates, it is NOT possible to do so for the Outbound Signing certificate.

It is imperative to be familiar with the material covered earlier, and in particular part one. I assume you are so make sure to have read this before continuing!

Let’s dive in!

Example Scenario

As usual I have contrived a sample scenario in order to demonstrate the configuration aspects necessary. Clearly such a scenario is not representative of an actual production deployment, and concentrates only on the elements which are important. Basically it’s the least amount of machines necessary to demonstrate the configuration.

I have a single domain, called fabrikam.com. Six members of that domain run Windows Server 2012 and are:

FABDC1 (10.1.1.50)
DNS, Active Directory Domain Controller
FABSQL1 (10.1.1.60)
A single default instance of SQL Server Database Services
FABWFM1 (10.1.1.70)
Workflow Manager Host
FABWFM2 (10.1.1.71)
Workflow Manager Host
FABWFM3 (10.1.1.72)
Workflow Manager Host
FABSP1 (10.1.1.80)
SharePoint Server 2013

There is also another machine, running Windows 8:

FABCLIENT1 (10.1.1.90)
Visual Studio 2012, SharePoint Designer 2012, Office 2013 etc.

Obviously the only element which will be fault tolerant or high available is the Workflow Manager farm! I assume that you are familiar with how to deal with high availability for domain services, SQL Server and SharePoint.

The end result we are looking to achieve here of course is a working connection to a load balanced SSL Workflow Manager farm.

Pre-requisite Software

Workflow Manager has very light requirements in terms of pre-requisites. Basically it only needs IIS, .NET 4 PU3 or .NET 4.5. Then the Workflow Manager piece requires Service Bus 1.0, Workflow Client 1.0 and Windows PowerShell 3.0. Workflow Manager itself is installed primarily via the Web Platform Installer (WebPI) which will take care of the pre-requisites as well. There is also an offline installation approach if your machines do not have Internet access.

The upshot here is if you are using a single sysprep (or similar) base image you can use the same one for your Workflow Manager hosts as you do for SharePoint. Another bit of good news is that Workflow Manager’s minimum “hardware” requirement is only 2 cores and 2Gb RAM.

Workflow Client

We will need however to install the Workflow Client 1.0 on every SharePoint server in the farm. Without the Workflow Client we won’t be able to create connections to the Workflow Manager farm, create, initiate or otherwise interact with workflows.

Again the Workflow Client is primarily delivered by the WebPI but can also be installed in “offline” scenarios. What I have done is bake this into my base image. However you should get familiar with performing the offline installation which is common across all products delivered via WebPI.

The trouble is of course, there isn’t a good specific guide to doing this for Workflow Client. The steps are almost accurate but detail Workflow Manager. Also the path in the documented command will not work! It’s just a couple simple changes needed. Since I’ve been asked about this repeatedly, here are the steps:

On a machine with Internet access, download and install the Web Platform Installer v4 Command Line.
For a while this was Preview, now it’s RTW and it’s right now v4.6. The version changes over time so use the “permalink” above to get the latest and greatest.
Open a command prompt or Windows PowerShell host under UAC elevation (run it as an administrator)
1. Change to the directory for the Web Platform Installer. By default this is:
```
cd "c:\Program Files\Microsoft\Web Platform Installer"
```
2. Execute the following command (on a single line):
```
webpicmd /offline /Products:WorkflowManager 
/Path:c:\WorkflowManagerFiles
```
  This will take quite a while - the WebPI will download a manifest of available products and create the folder specified in the Path switch containing the Products specified in the Products switch and any of its dependencies. It’s roughly around a 300 Mb download in total.
  Note that I specified WorkflowManager in the Products switch. Because the Client is a dependency for the Manager, this one set of files can be used to perform an offline install of both the Manager and the Client.
Copy the c:\WorflowManagerFiles folder to the destination server (or zip it up and stick it someplace useful for later)
On the destination server(s) open a command prompt or Windows PowerShell host under UAC elevation
1. Change the directory to the location of the offline installers:
```
cd "c:\WorkflowManagerFiles\bin"
```
2. To install Workflow Manager execute the following command (on a single line):
```
WebpiCmd.exe /Install /Products:WorkflowManager
/XML:c:/WorkflowManagerFiles/feeds/latest/webproductlist.xml
```
3. To install Workflow Client execute the following command (on a single line):
```
WebpiCmd.exe /Install /Products:WorkflowClient
/XML:c:/WorkflowManagerFiles/feeds/latest/webproductlist.xml
```
  Note that all the documentation talks about c:/WorkflowManagerFiles/feeds/shadow-webproductlist.xml.
  That path does not exist. Use the path above and you will see the following:
  
  Also, never use Workflow for the Product. That will install a nasty old pre-release build, and we don’t want that.
Type Y, and hit Return and the installation will proceed.

Network Load Balancing

Our other pre-requisite if of course Network Load Balancing (NLB). We also need to install this on each server in the Workflow Manager farm.

This is a snap to install via Server Manager. Simply select the Windows Server Feature Network Load Balancing. By default this will include NLB and its remote administration Windows PowerShell module and the circa NT4 Option Pack GUI.

Alternatively we can install NLB and its tools with the following Windows PowerShell:

Add-WindowsFeature NLB #nlb
Add-WindowsFeature RSAT-NLB #nlb management UI and PoSh

This is something else I bake into my base sysprep image for application servers.

Creating a Network Load Balancing Cluster for Workflow Manager

We configure a NLB cluster so that we can access Workflow Manager from SharePoint using a virtual name. We need a DNS A record for that virtual name which we will use when creating the NLB Cluster.

On FABDC1 perform the following steps:

Open DNS Management
Double click the fabrikam.com Forward Lookup Zone
From the Action menu, choose New Host (A or AAAA)…
In the Name text box, enter: wfm
In the IP Address text box, enter: 10.1.1.100
Click Add Host
Click OK, followed by Done.

Alternatively we can create the DNS A record with the following Windows PowerShell:

Import-Module DnsServer
Add-DnsServerResourceRecordA -Name "wfm" -IPv4Address "10.1.1.100" -zone "fabrikam.com"

Now we can proceed and create the NLB Cluster. The Remote Administration Tools for NLB still ship with the NLBMgr.exe tool, a GUI for managing NLB. It works after a fashion, and as much as it makes me feel all comfy with its NT4 Option Pack style and finesse, I really don’t like using it. It often causes more problems than it solves and we can do the same thing much more easily with Windows PowerShell, so I am not going to detail the steps with NLBMgr.exe.

Also depending upon your virtualisation platform, how many network adaptors in your hosts, and how you are connecting to the hosts will determine where to run NLBMgr and what will happen when the NIC is updated with the cluster configuration.

Because I don’t know what type of environment you have, we will configure a Multicast cluster – which while not optimal will work everywhere, even on a Hyper-V machine with a single NIC in each guest. The safest option is to run this script from a machine which is NOT going to be part of the cluster – that will avoid your connection being dropped if you are using Remote Desktop to connect to the hosts. Remember to install the Remote Administration Tools for NLB using Add-WindowsFeature.

Execute the following Windows PowerShell on the machine of your choosing. You will need to update the $interface variable to reflect the name of the NIC you wish to configure for NLB. By default this is “Local Area Connection” but it is a good practice to rename this, especially when hosts have multiple NICs:

Add-WindowsFeature NLB #nlb
Add-WindowsFeature RSAT-NLB #nlb management UI 

$interface = "10net"
$initialHost = "FABWFM1"

# Create a new NLB Cluster
New-NLBCluster -Interface $interface -OperationMode Multicast -ClusterPrimaryIP "10.1.1.100" -ClusterName "WFMCluster" -HostName $initialHost

# Remove the stupid default port rule for everything
Get-NlbClusterPortRule -HostName $initialHost | Remove-NlbClusterPortRule -Force

# Add port rules for 12290
Add-NlbClusterPortRule -HostName $initialHost -StartPort 12290 -EndPort 12290 -InterfaceName $interface

# Add other hosts to cluster
Add-NlbClusterNode -HostName $initialHost -InterfaceName $interface -NewNodeName "FABWFM2" -NewNodeInterface $interface 
Add-NlbClusterNode -HostName $initialHost -InterfaceName $interface -NewNodeName "FABWFM3" -NewNodeInterface $interface

Enrolling the required certificates

In order to make use of Domain CA issued certificates for our farm, we need to enrol them. In plain English, request them from the Certificate Authority. If the certificate we needed was a plain old web server certificate, this is very easy to do using Internet Information Services Manager. However, as detailed in part one, it’s essential that we use a certificate which also includes Subject Alternative Name (SAN) attribute(s). This is not something we can do using IIS Manager.

We also cannot use the Computer Certificate Template , as this will have it’s attributes auto-generated and does not include an alternate name. Thus the first thing we need to do is to make the Web Server Certificate Template available for enrolment on one of our Workflow Manager machines. By default this is not the case with a Windows Domain CA.

We will use a single certificate for all Workflow Manager and Service Bus certificates. There is no good reason to do otherwise however if you do have a requirement for individual certificates, you can simply repeat the steps for each one. When we configure the Workflow Manager and Service Bus farms later on, we are prompted to select each certificate in turn.

On the machine hosting our Certificate Authority, FABDC1, perform the following steps:

Launch Certification Authority
Expand the CA (fabrikam-FABDC1-CA) node
Right click on Certificate Templates and click Manage
In the Certificate Templates Console, within the Templates list, right click Web Server and click Properties
On the Web Server Properties dialog, click the Security tab
Click Add…
Click Object Types…
Check the Computers check box, and click OK
Enter FABWFM1 in the Enter object names to select text box and click OK
Check the Enroll Allow check box, and click OK

This allows us to request a Web Server certificate from the Certificates MMC snap in on FABWFM1 in the next step. Once we are done, we can go ahead and revert this security configuration if we wish to.

Next up, we enrol a certificate on on of the Workflow Manager hosts, perform the following steps on FABWFM1:

Launch MMC.exe
From the File menu, click Add/Remove Snap-in…
From the Available Snap-ins grid view, select Certificates and click Add >
On the Certificates snap-in dialog, select the Computer account radio button and click Next
Click Finish and OK
Expand the Certificates (Local Computer) node
Right click on Personal, click All Tasks, and click Request New Certificate…
On the Before You Begin page, click Next
On the Select Certificate Enrollment Policy page, click Next
On the Request Certificates page, check the Web Server check box, and click the “Click here to configure settings.” hyperlink
In the Subject tab of the Certificate Properties dialog
1. In the Subject name area, select Common Name in the Type combo box
2. Enter a Value of wfm.fabrikam.com, and click the Add > button
3. In the Alternative name area, select DNS in the Type combo box
4. Enter a Value of *.fabrikam.com, and click the Add > button
5. Ensure your settings exactly match the below screenshot before proceeding
Click the General tab
1. Enter a Friendly name of wfmSanCert
2. Enter a Description of Workflow Manager SAN Certificate
Click the Private Key tab
1. Expand the Key options area by clicking the down arrow icon to the right, and check the Make private key exportable check box
Click OK
Click Enroll to create the certificate, followed by Finish
Note that the new certificate will be displayed in the Personal\Certificates store for the Local Computer

Note that in the above steps above, we might choose to enter multiple values of fabwfm1.fabrikam.com, fabwfm2.fabrikam.com, fabwfm3.fabrikam.com and wfm.fabrikam.com for an Alternative name. This would in principal allow us to be more prescriptive regarding membership of the Workflow Manager farm. However this will not work with SharePoint 2013. Thus the DNS=*.fabrikam.com alternate name is an absolute hard requirement.

Exporting and Importing the Certificate

The next step is to export and import the cert to the two other machines in the Workflow Manager farm. This is simple to achieve using the Certificates MMC Snap-in. Basically you export the certificate with it’s private key to a file, and then import that on the other two machines. We can also achieve the same end result with the following Windows PowerShell.

Execute the following Windows PowerShell on FABWFM1, to export the certificate to a file. You will be prompted to enter a password used to protect the certificate file:

$filePath = "c:\wfmSanCert.pfx"
$friendlyName = "wfmSanCert"
$cert = dir Cert:\LocalMachine\My | ? {$_.FriendlyName -eq $friendlyName}
$password = Read-Host "Certificate Password: " -AsSecureString

Export-PfxCertificate -Cert $cert -Password $password -FilePath $filePath

Execute the following Windows PowerShell on FABWFM2 and FABWFM3 to import the certificate. You will need to enter the same password you entered in the step above:

$filePath = "\\fabwfm1\c$\wfmSanCert.pfx"
$password = Read-Host "Certificate Password: " -AsSecureString

Import-PfxCertificate -Password $password -FilePath $filePath -CertStoreLocation "cert:\localMachine\my"

You will note the output of the above includes the Thumbprint on the certificate we have just imported:

    Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\my


Thumbprint                                Subject                                                                                                                                                                 
----------                                -------                                                                                                                                                                 
6DE8ABD6B1D475136865DC835EC1774D974F15E2  CN=wfm.fabrikam.com

You will also be able to view the certificate in the Certificates MMC Snap-in or indeed IIS Manager on both FABWFM2 and FABWFM3.

Creating and Configuring a Workflow Manager Farm

Now we have our base platform taken care of, we can proceed to create and configure the Workflow Manager Farm. There are a few things I like to do as standard for Workflow Manager production installations. These are not “best practices”, just recommendations!

Use a SQL Alias for the SQL Server.
It’s all very well and good having HA for the Workflow Manager hosts, but we shouldn’t overlook the database platform in this respect :). I’m using a SQL Alias of SQLWFM in this example.
Don’t store the Service Bus and Workflow Manager databases on the same SQL Instance that hosts your SharePoint databases.
Don’t collocate this stuff in production, it will only hurt you later. For this example I have a single instance hosting everything.
Use a dedicated Service Account Identity.
I use the same one for both Workflow Manager and Service Bus. In this example I’m using wfm@fabrikam.com (fabrikam\wfm). The Workflow Manager documentation refers to this as the RunAs Account.
Leverage a Workflow Manager Administrators Domain Security Group.
For multi server Workflow Manager farms, it makes sense to leverage a Domain Security Group to provide control of who can administer the services. In this example I’m using the group WFMAdmins, and the user account I am using to performing the steps is a member.
Everything else I leave at the defaults.
One could change up the database naming convention, but that is only really of help if you are co-locating databases. Don’t go there with changing up ports! That only makes sense if you are running other things on those ports on the server, and you shouldn’t be doing that!

We can either use the Workflow Manager Configuration Wizard or Windows PowerShell to create and configure our farm. In reality, the Configuration Wizard simply is a UI which guides us through entering the settings. It then generates Windows PowerShell to actually perform the install and executes it. It also allows us to view and save that Windows PowerShell for later use. Are you paying attention SharePoint? :)

On the first server for the Workflow Manager Farm (FABWFM1):

Launch the Workflow Manager Configuration Wizard
Click the Configure Workflow Manager with Custom Settings option
On the Workflow Manager Configuration page

Enter SQLWFM as the SQL Instance
Enter wfm@fabrikam.com as the User ID
Enter the password as the Password :)
In the Configure Certificates section, un-check the Auto-generate check box
Click the Browse… button to the right of Specify an installed certificate for the Services SSL Certificate
On the Windows Security dialog, click the wfmSanCert entry and click OK
Click the Browse… button to the right of Specify an installed certificate for the Workflow Manager Outbound Signing Certificate
On the Windows Security dialog, click the wfmSanCert entry and click OK
Click the Browse… button to the right of Specify an installed certificate for the Encryption Certificate
On the Windows Security dialog, click the wfmSanCert entry and click OK
Enter fabrikam\wfmadmins in the Configure Admin Group text box
Click the “Next” icon and wait whilst the configuration is validated

On the Service Bus Configuration page

In the Configure Service Account section, check the Use the same service account credentials as provided for Workflow Manager check box
In the Configure Certificate section, un-check the Auto-generate check box
Click the Browse… button to the right of Specify an installed certificate for the Farm Certificate
On the Windows Security dialog, click the wfmSanCert entry and click OK
Click the Browse… button to the right of Specify an installed certificate for the Encryption Certificate
On the Windows Security dialog, click the wfmSanCert entry and click OK
Enter fabrikam\wfmadmins in the Configure Admin Group text box
Click the “Next” icon and wait quite a while whilst the configuration is validated and the Windows PowerShell is generated

On the Summary page you can review the configuration. Note the Get PowerShell Commands link.
Click the “tick” icon to apply the configuration. Wait while the farms are created and configured.
Once complete, click the “tick” icon to close the Configuration Wizard

Here’s the Windows PowerShell the wizard generates for us, and can be used when replicating the environment:

# To be run in Workflow Manager PowerShell console that has both Workflow Manager and Service Bus installed.

# Create new SB Farm
New-SBFarm -SBFarmDBConnectionString 'Data Source=SQLWFM;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False' -InternalPortRangeStart 9000 -TcpPort 9354 -MessageBrokerPort 9356 -RunAsAccount 'wfm@fabrikam.com' -AdminGroup 'fabrikam\wfmadmins' -GatewayDBConnectionString 'Data Source=SQLWFM;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -FarmCertificateThumbprint '6DE8ABD6B1D475136865DC835EC1774D974F15E2' -EncryptionCertificateThumbprint '6DE8ABD6B1D475136865DC835EC1774D974F15E2' -MessageContainerDBConnectionString 'Data Source=SQLWFM;Initial Catalog=SBMessageContainer01;Integrated Security=True;Encrypt=False' -Verbose;

# To be run in Workflow Manager PowerShell console that has both Workflow Manager and Service Bus installed.

# Create new WF Farm
New-WFFarm -WFFarmDBConnectionString 'Data Source=SQLWFM;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=False' -RunAsAccount 'wfm@fabrikam.com' -AdminGroup 'fabrikam\wfmadmins' -HttpsPort 12290 -HttpPort 12291 -InstanceDBConnectionString 'Data Source=SQLWFM;Initial Catalog=WFInstanceManagementDB;Integrated Security=True;Encrypt=False' -ResourceDBConnectionString 'Data Source=SQLWFM;Initial Catalog=WFResourceManagementDB;Integrated Security=True;Encrypt=False' -OutboundCertificateThumbprint '6DE8ABD6B1D475136865DC835EC1774D974F15E2' -SslCertificateThumbprint '6DE8ABD6B1D475136865DC835EC1774D974F15E2' -EncryptionCertificateThumbprint '6DE8ABD6B1D475136865DC835EC1774D974F15E2' -Verbose;

# Add SB Host
$SBRunAsPassword = ConvertTo-SecureString -AsPlainText  -Force  -String '***** Replace with RunAs Password for Service Bus ******' -Verbose;


Add-SBHost -SBFarmDBConnectionString 'Data Source=SQLWFM;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False' -RunAsPassword $SBRunAsPassword -EnableFirewallRules $true -Verbose;

Try
{
    # Create new SB Namespace
    New-SBNamespace -Name 'WorkflowDefaultNamespace' -AddressingScheme 'Path' -ManageUsers 'wfm@fabrikam.com','Administrator@FABRIKAM' -Verbose;

    Start-Sleep -s 90
}
Catch [system.InvalidOperationException]
{
}

# Get SB Client Configuration
$SBClientConfiguration = Get-SBClientConfiguration -Namespaces 'WorkflowDefaultNamespace' -Verbose;

# Add WF Host
$WFRunAsPassword = ConvertTo-SecureString -AsPlainText  -Force  -String '***** Replace with RunAs Password for Workflow Manager ******' -Verbose;


Add-WFHost -WFFarmDBConnectionString 'Data Source=SQLWFM;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=False' -RunAsPassword $WFRunAsPassword -EnableFirewallRules $true -SBClientConfiguration $SBClientConfiguration -Verbose;

Now we go ahead and run the Workflow Configuration Wizard on the second and third servers in the farm (FABWFM2 and FABWFM2).

Launch the Workflow Manager Configuration Wizard
Click the Join an Existing Workflow Manager Farm option
On the Join Farm page

Enter SQLWFM as the SQL Instance
Click the Test Connection button
Click the “Next” icon

On the Join Workflow Manager Farm page

Enter the Password for the Service Account
Click the “Next” icon

On the Join Service Bus Farm page

Check the Use the same service account credentials as provided for Workflow Manager check box
Click the “Next” icon

On the Summary page you can review the configuration. Note the Get PowerShell Commands link
Click the “Tick” icon to apply the configuration. Wait while the farms are joined.

Here’s the Windows PowerShell the wizard generates for us, and can be used when replicating the environment:

# To be run in Workflow Manager PowerShell console that has both Workflow Manager and Service Bus installed.

# Add SB Host
$SBRunAsPassword = ConvertTo-SecureString -AsPlainText  -Force  -String '***** Replace with RunAs Password for Service Bus ******' -Verbose;


Add-SBHost -SBFarmDBConnectionString 'Data Source=SQLWFM;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False' -RunAsPassword $SBRunAsPassword -EnableFirewallRules $true -Verbose;

Try
{
    # Create new SB Namespace
    New-SBNamespace -Name 'WorkflowDefaultNamespace' -AddressingScheme 'Path' -ManageUsers 'wfm@fabrikam.com','Administrator@FABRIKAM' -Verbose;

    Start-Sleep -s 90
}
Catch [system.InvalidOperationException]
{
}

# Get SB Client Configuration
$SBClientConfiguration = Get-SBClientConfiguration -Namespaces 'WorkflowDefaultNamespace' -Verbose;

# Add WF Host
$WFRunAsPassword = ConvertTo-SecureString -AsPlainText  -Force  -String '***** Replace with RunAs Password for Workflow Manager ******' -Verbose;


Add-WFHost -WFFarmDBConnectionString 'Data Source=SQLWFM;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=False' -RunAsPassword $WFRunAsPassword -EnableFirewallRules $true -SBClientConfiguration $SBClientConfiguration -Verbose;

We can view the status of our Workflow Manager farm by executing the following Windows PowerShell on one of the hosts:

Import-Module WorkflowManager

Get-WFFarm
Get-WFFarmStatus

Which will give us the following output:

FarmType                   : Workflow
WFFarmDBConnectionString   : Data Source=SQLWFM;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=False
RunAsAccount               : wfm@fabrikam.com
AdminGroup                 : fabrikam\wfmadmins
Hosts                      : {Name: FABWFM1.fabrikam.com, Configuration State: HostConfigurationCompleted, Name: FABWFM2.fabrikam.com, Configuration State: HostConfigurationCompleted, 
                             Name: FABWFM3.fabrikam.com, Configuration State: HostConfigurationCompleted}
InstanceDBConnectionString : Data Source=SQLWFM;Initial Catalog=WFInstanceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False
ResourceDBConnectionString : Data Source=SQLWFM;Initial Catalog=WFResourceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False
HttpPort                   : 12291
HttpsPort                  : 12290
OutboundCertificate        : Thumbprint: 6DE8ABD6B1D475136865DC835EC1774D974F15E2, IsGenerated: False
Endpoints                  : {https://FABWFM1.fabrikam.com:12290/, https://FABWFM2.fabrikam.com:12290/, https://FABWFM3.fabrikam.com:12290/}
SslCertificate             : Thumbprint: 6DE8ABD6B1D475136865DC835EC1774D974F15E2, IsGenerated: False
EncryptionCertificate      : Thumbprint: 6DE8ABD6B1D475136865DC835EC1774D974F15E2, IsGenerated: False

HostName      : FABWFM1.fabrikam.com
ServiceName   : WorkflowServiceBackend
ServiceStatus : Running

HostName      : FABWFM1.fabrikam.com
ServiceName   : WorkflowServiceFrontEnd
ServiceStatus : Running

HostName      : FABWFM2.fabrikam.com
ServiceName   : WorkflowServiceBackend
ServiceStatus : Running

HostName      : FABWFM2.fabrikam.com
ServiceName   : WorkflowServiceFrontEnd
ServiceStatus : Running

HostName      : FABWFM3.fabrikam.com
ServiceName   : WorkflowServiceBackend
ServiceStatus : Running

HostName      : FABWFM3.fabrikam.com
ServiceName   : WorkflowServiceFrontEnd
ServiceStatus : Running

At this stage it’s prudent to test the Workflow Manager farm is responding on it’s virtual name from a machine which is not part of the farm.

On FABSP1, open Internet Explorer and browse to https://wfm.fabrikam.com:12290. We should see the Workflow Manager configuration returned:

There are no certificate warnings of course, because the certificate is issued by our Domain CA, and thus is trusted on every machine in the domain.

Create a Workflow Service Connection in SharePoint

Now we have a functional, load balanced Workflow Manager farm, we can use it’s virtual name to create the Service Connection in SharePoint.

These tasks assume that your SharePoint Farm is up and running, and all the necessary pre-requisites for 2013 Workflows are in place. Furthermore an SSL Web Application and Site Collection is expected.

We don’t need to worry about importing any certificates into the SharePoint Trusted Root Authorities store as we are leveraging a Domain CA issued certificate.

Perform the following tasks on FABSP1:

Register the Workflow Service Connection with SharePoint by executing the following Windows PowerShell:
```
Register-SPWorkflowService -SPSite "https://intranet.fabrikam.com" -WorkflowHostUri "https://wfm.fabrikam.com:12290"
```
Watch out with this cmdlet. If this command fails the Service Application Proxy will still be created but it will be effectively broken. Again monitor the output for any errors. Clean up the connection and re-run Register-SPWorkflowService after resolving the problem.
We can open up Central Administration and click the Workflow Service Application Proxy in Manage Service Applications to view the Workflow Status Page:

If there is a problem, in some cases we will see a different display:

But be wary, this will not always be the case. It’s entirely possible to have a broken Workflow connection, but for this page to display a connection.

The only real way to test properly is to crack open SharePoint Designer, create and publish a workflow, and then execute it. Feel free to do that now to verify functionality!

Conclusion

Pretty simple. We sort out our base infrastructure, create a NLB Cluster, enrol a certificate, create a Workflow Manager farm, and create a connection between SharePoint and Workflow Manager. Using Domain CA issued certificates for everything, including the Outbound Signing Certificate, which is often required due to organisational policies, also reduces the configuration overhead and operational service management.

Hopefully this article series has been useful and look out for future posts on Workflow Manager as it relates to SharePoint 2013 coming soon!

Wait for Event in List Item!

Recent Posts

Articles

Post Categories

Archives