Recently going through a farm install and configuration of Workflow in a 2013 multi-server farm, I learned a couple things along the way that weren’t covered by the still-catching-up documentation.
First of all, prior to RTM, the messaging was that Workflow needed to be installed on a dedicated server and could not be on an existing server in your farm. This changed when RTM became available and it is now supported, although perhaps not recommended for environments needing scalability, redundancy, and availability to support a high throughput of processes. In my case, I chose to install and run Workflow on an app server that was running Central Administration.
Once that decision is made, we need to make sure we have the accounts and groups in AD we need:
- Install account – A domain user with admin rights on the server being configured, as well as SysAdmin rights in SQL Server
- RunAs account – A domain user with login rights to SQL Server (additional rights will be granted during the configuration)
- Admin group – A domain security group with the RunAs account as a member, optionally the Install account as a member as well (see note later regarding starting the service)
A couple other requirements noted in the documentation that need to be checked:
- SQL Server 2008 R2 SP1, SQL Server Express 2008 R2 SP1, or SQL Server 2012
- TCP/IP connections or named pipes configured in SQL Server
- Windows Firewall enabled
- Ports 12290 and 12291 must be available (the configurator will open these ports in the firewall and use them for workflow traffic)
Now we can start the install and configuration of Workflow Manager (download link). The TechNet documentation (and here) is pretty bare, but it was sufficient to get me going. The installer will install any prerequisites that are missing and then install Workflow Manager. For configuring, you can either use the Configuration Wizard or PowerShell. I went with the wizard since the PowerShell documentation on Workflow was a skeleton and didn’t have much. I went with the Custom Settings option in the wizard so I had more control over things like database names. I also let the wizard generate a certificate for me with my provided key. If you don’t have your own, we’ll need to use this later. Everything else should be self-explanatory.
Depending on your scenario, the next steps may vary. The TechNet covers the options well so I won’t repeat them, but the decision is based on whether Workflow Manager is on a server in the farm and whether communication is over HTTP or HTTPS (in production, you should be using HTTPS.) I have Workflow Manager on a server in my farm using HTTPS so I needed to:
- Install my certificates on my WFEs by exporting the cert and then importing it into the Trusted Root Certification Authorities store in each WFE, and then running New-SPTrustedRootAuthority cmdlet (all of which is covered well on TechNet)
- Install the Workflow Manager Client on each WFE (download link above)
- Run the Register-SPWorkflowService cmdlet:
Register-SPWorkflowService –SPSite “https://myserver/mysitecollection” –WorkflowHostUri “https://workflow.example.com:12290”
That last step has a couple things worth noting.
- To get the WorkflowHostUri, go into IIS where you installed Workflow Manager and find the workflow service web application. Check it’s properties to get the Uri, with port (which is the same port you entered during the configuration, by the way)
- The command needs to be run using an account that is a member of the admin group you created earlier. If you added your install account, you can use that. If you didn’t, you need to run the command as your RunAs account
Following the TechNet docs, your next step would be to validate the install using SharePoint Designer. It’s been my experience that SPD will only be able to create 2013 workflows after two more steps, that aren’t documented:
- You need to have an App Management Service Application created. You don’t need to completely configure apps in your environment, but you need to at least create the service app or you’ll get an error when you publish a workflow from SPD.
- I wasn’t getting the 2013 workflow option to appear in SPD at first. I didn’t find the culprit, but a reboot of the Workflow Manager server did the trick for me.
If you need help creating an App Management Service Application, here are some scripts:
Register-SPWorkflowService –SPSite "https://myserver/mysitecollection" –WorkflowHostUri "https://workflow.example.com:12290" $appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $applicationPool -Name "App Management Service Application" -DatabaseName "AppManagement_DB" New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc
You should be able to create 2013 workflows after all that. If you run into any hiccups, post a comment and I’ll do what I can to help out.