Recently, I had to upgrade the infrastructure for a Service Manager management group, and as part of this upgrade I had to change the workflow management server to a newly built management server.  At first, this looked like a straight forward process as defined on Microsoft TechNet.

I prepared the new management server, run the SQL query, and restarted the System Center services, and everything was completed successfully.  After checking the new management server, I could see that the workflows were now running on it, so I was happy that this job was complete.

On further investigation though I noticed that the registered Data Source for the operational management group on the Data Warehouse still had an SDK Server defined as the original workflow management server.

SCSM Data Source

As this information was pulled from the database when the data source was created, I realised that the data source would need to be recreated or updated, so the correct SDK server is defined.  Rather than risking removing the data source, and creating it again, I decided to use the SCSMRegisterDW tool from, as this tool updates the existing data sources rather than recreating them.

As the tool runs, it displays information it will use to update the data sources from the relevant databases.  The key information in this scenario is what is returned when getting “SM WF Server in DB is:”.  In my case, the old workflow management server was still being returned, therefore the update to the data source would be the same as the original.

Register DW

This clearly indicated that somewhere in the ServiceManager database, the workflow management server hadn’t been updated, so I started looking at the relevant tables in the database.  After digging around, I found that the old management server was still set within the MT_Microsoft$SystemCenter$ResourceAccessLayer$SdkResourceStore table.

Running this query against the ServiceManager database will return the what the SDK Server (workflow management server) is.

As this was incorrect, it needed updating to the correct value, which can be done running the query below.

Before doing this though, I stopped all management server services on all management servers, and then started them again after I had confirmed the update in SQL had been successful.

With everything running again, I tried the SCSMRegisterDW tool again, and this time it picked up the correct workflow server name, and updated the data source appropriately.  So, after refreshing the Data Sources view in the SCSM console, the SDK Server value was defined correctly.  Now, the workflow MS move is complete!!


If you have any experiences with changing the workflow management server that isn’t documented, please let me know!!