Posts tagged ‘SharePoint’

How to migrate SharePoint 2010 List based workflows

How to migrate SharePoint 2010 List based workflows

Problem Statement:

We have a SharePoint 2010 list on our site and a workflow is associated to that list.

Sometimes, the existing list gets corrupt and we have to replicate the list using the list template saved earlier. Now, the existing workflow does not get associated to the new list and we have to re-create the entire workflow in SharePoint Designer.

Another scenario for associating an existing workflow is when the site is migrated; as, the workflow-list association is broken.


Re-creating the entire workflow in SharePoint Designer can be a tedious process.

The alternative to this is to modify the source workflow files to force it to re-attach to the new list.

Note: There should be no schema mismatch between the old and new list.

When a workflow is created in a site for the first time, a Tasks list and a Workflow History list are automatically created/used by the workflow.

We will be using this concept for the migration.

Follow the below mentioned three steps in order to associate the workflow with the new list:

Step 1 – Create a Blank Workflow

  1. Using SharePoint designer, connect to your destination site
  2. Create a new list-based workflow called “test” (or any other name), attaching it to your migrated list
  3. Create one condition (e.g. if 1 = 1) and one action (e.g. add comment “hello”)
  4. Save and publish the workflow

Your site will now have a Tasks list and Workflow History list.

Step 2 – Get the List IDs for the new workflow

The list ids are required to configure your migrated workflow.

  1. Using SharePoint Designer, connect to your destination site
  2. In the left navigation page, under Site Objects, select All Files
  3. In All Files list, select Workflows
  4. Select your new workflow that you just created (in this example, “test”)
  5. You should see (at least) four files:
  6. Right-click on test.xoml.wfconfig.xml and select Open With, Notepad
    Look for the <Association…> tag in the xml:
    <Association ListID=”{770980F2-DA18-4089-96A2-066DF774BEA5}” StartManually=”true” TaskListID=”{DA6A8029-A1BE-4775-9E9B-1558CEA98791}” HistoryListID=”{44B38DD6-B5F1-4BF2-B063-B624DE88A207}”/>
    Record the GUID entries for ListID, TaskListID and HistoryListID.

Step 3 – Update the Existing workflow

  1. Using SharePoint Designer, All Files, Workflows, select your existing workflow
  2. You should again see (at least) four files. Right-click on “<your-workflow>.xoml.wfconfig.xml” and select Open with SharePoint Designer (As XML)
  3. Find the Association tag and very carefully change the GUIDs so that your migrated List IDs are the same as the “test” workflow List IDs
    Association tag
  4. Save the file
  5. Close SharePoint Designer
  6. Open SharePoint Designer again and open your site
  7. Instead of All Files, this time click on Workflows
  8. Select your workflow
  9. Save the workflow
  10. Publish the workflow

Your existing workflow should now be re-associated with the new list.



SharePoint Configuration Database in Suspect Mode


Unable to load my SharePoint site hosted on a VM. Page threw the error viz. ‘Cannot connect to configuration database’

Resolution (Steps taken):

  1. Observed that ‘SharePoint_Config’ DB was in Suspect mode. In SSMS, I found the Suspect status with SharePoint_Config DB
  2. On restarting SQL services, Recovery status was displayed with SharePoint_Config DB
  3. After the recovery process completed, the DB name was rendered properly in SSMS; but, page still threw the error viz. ‘Cannot connect to configuration database’
  4. After some time, Suspect status had resurfaced on viewing in SSMS. This showed that the DB was still corrupt
  5. In such scenarios, one option would have been to restore the DB with an old backup. In my case, I did not have a backup L
  6. On searching the net, I found few blogs mentioning this issue
  7. As per the blogs, the SharePoint DB gets corrupt occasionally when the VM restarts untowardly
  8. Script that helped me resolve the issue:
    -- Use the Master database
    Use Master
    -- Verify that database has issues
    EXEC sp_resetstatus 'SharePoint_Config'
    -- Put the database in emergency mode
    DBCC checkdb('SharePoint_Config')
    -- Set the database in single user mode
    -- Repair the database with data loss
    DBCC CheckDB ('SharePoint_Config', REPAIR_ALLOW_DATA_LOSS)
    -- Set the database in multi-user mode
    -- Verify that database is reset
    EXEC sp_resetstatus 'SharePoint_Config'
  9. PFA: SharePoint_Config_Recovery.sql, SQL script mentioned in the blogs which helped me resolve the issue
  10. Script tries to set the DB in Emergency mode and repair the data loss. This should be applicable to any DB which gets corrupt and goes into Suspect mode