Console Apps for SharePoint Lists

Posted by devaaron

I recently had a requirement to update a SharePoint list based on a Date and Time field. The list contained two important fields: the Date and Time field called ‘Hire Date’ and a field called ‘Active’. The goal was to update the list item when the ‘Hire Date’ field was equal to today’s date and change the ‘Active’ field to false.

This is simple in a workflow, however, the item was NOT getting updated when ‘Hire Date’ was equal to today so there was no way to trigger the workflow. A simple alternative is a .NET console app that runs every day using Windows Task Scheduler.

The app itself is simple, it uses CSOM to get the values of the item and updates the Active column when appropriate.

There are several advantages to using a console app and running it on a schedule:

It’s easy to parse the values of a list and preform an update
I don’t need to do something as unnecessary as pause a workflow on Item Creation to the ‘Hire Date’ and leave it paused for potentially weeks
And most importantly, I’m not using a Custom Timer Job. SharePoint Timer Jobs, particularly custom ones, can be resource intensive strains on your SharePoint server. If your SharePoint server is already strained for resources, like ours, console apps are a quick and efficient way to check for and make updates to SharePoint Lists.

Changing Workflow Service Account

Posted by devaaron

Recently, I needed to change the workflow service account for workflow 2013 platform. While this seemed relatively easy, there were several strange errors that I ran into. We had the Workflow 2013 Platform configured but the RunAs account needed to be changed. We were using the System Account, when we should have had a Service Account created for the workflow service itself. After creating that Service Account for the workflow service we need to set it as the RunAs account.

After a little hunting with google, I stumbled on this powershell script:

Stop-SBFarm
Set-SBFarm -RunAsAccount Domain\Username
$RunAsPassword = ConvertTo-SecureString -AsPlainText -Force ‘<password>’
[RunOnAllNodes] Update-SBHost -RunAsPassword $RunAsPassword

Start-SBFarm

It looks easy enough, but if I tried and run Set-SBFarm, I received the below error:

At this point, it’s important to note that we have Workflow Manager 1.0 which has a dependency of Service Bus 1.0. The above cmdlet is part of Service Bus 1.1. So, you’ll need to do some upgrading to use it. Of course, the order of installation matters.

First, you need to install Service Bus 1.0 CU 1: https://support.microsoft.com/en-us/kb/2799752

Secondly, you’ll need to update to Workflow Manager 1.0 CU 1: https://support.microsoft.com/en-us/kb/2799754 or Workflow Manager 1.o CU 2: https://www.microsoft.com/en-us/download/details.aspx?id=42036 both of which have a dependency of Service Bus 1.0 CU 1 and you need Workflow Manager 1.0 CU 2 to install Service Bus 1.1.

Preferably, you should update directly to Workflow Manager 1.0 CU 2 which has support for Service Bus 1.1 which you will need to run the above cmdlet. The Web Platform Installer is preferable in this situation as it will download the correct install for you without having to choose the files yourself.

Finally, you will want to install Service Bus 1.1, which will require you to uninstall Service Bus 1.0. After that you should have the correct cmdlet.

This order is important because Service Bus 1.0 CU 1 is necessary to install Workflow Manager 1.0 CU 1 or Workflow Manager 1.0 CU 2, the latter has support for Service Bus 1.1 which has the cmdlet you will need. The alternate way, if you can’t upgrade, is to remove and reconfigure your farm. Please note that this will cancel all in progress workflows and require them to be republished and manually restarted.

A final note: the installation of Service Bus 1.1 requires you to leave the Service Bus Farm and rejoin it. Make sure that you have the database connection string which you can get by running the get-sbfarm cmdlet and know the certificate auto generation key — if you don’t you can set it by running the set-sbcertificateautogenerationkey cmdlet.

It’s a little frustrating, that before Service Bus 1.1, the only way to change the Service Account is to remove and reconfigure the farm, and while that’s simple, it can be time consuming and, as noted above, requires that you republish and manually restart your workflows.

Workflows still won’t publish

Posted by devaaron

I’ve made two posts about this in the past: one about running previous versions of workflows and another about workflows not publishing.

In the first post, I discovered that when running workflows in the 2010 platform previous versions may need to be deleted; in the second, I found that the activity cache on your local machine can prevent new versions of your workflow from being published.

This post is related. If a workflow fails to run with the error: something went wrong to try again reload the page and the start the workflow, you may need to restart two services. To do so check the server SharePoint is on and look for the two services:

Service Bus Gateway
Service Bus Manager Broker

If either of these services is stopped, restart them and try to rerun your workflow.

M	T	W	T	F	S	S
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30