Migrate In-Process Workflows from MOSS 2007 to SPS 2010 (Part 2 of 2)

Part 1 of this Article is Located - Here

Okay, now that we have a deeper understanding of the workflow process, and we have inspected our MOSS 2007 workflows to ensure they are ready to migrate, we are now ready to start the step-by-step methodology to migrate our in-process workflow:

(Two quick notes, the steps that follow are not all the steps involved in a SharePoint migration, and these steps assume the use of the Database Attach Upgrade Method).

Steps on the MOSS 2007 Server:

1. Run: stsadm -o preUpgradeCheck, Correct any Errors

2. Stop All Workflow Auto Cleanup Timer Jobs

• Central Administration > Operations > Timer Job Definitions > Edit Timer Job > Workflow Auto Cleanup - Disable

3. Quiesce the Farm

• Central Administration > Operations > Quiesce Farm - Start Quiescing - 5 minutes (more for production)
• Allow Quiesce to complete

4. Provide Sufficient Time for In-Memory/In-Process Workflows to Dehydrate (Usually No More Than 2 Hours)

5. Set the Content Database to Read Only

• SQL Server Management Studio > Databases > WSS_Content_MyCDB > Properties > Options > State > Database Read Only > True

6. Run PowerShell Command

• Start > All Programs >Accessories > Windows PowerShell > Windows PowerShell ISE
• Test-SPContentDatabase -Name WSS_Content_cdbTestIPWF -WebApplication http://shrpnt2007:8000/

7. Backup the Database

• SQL Server Management Studio > Management > Backup > Accept Defaults > OK
• C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\ 

Steps on the SPS 2010 Server:

1. Copy Workflow Solution Package to the SPS 2010 Server

• C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN

2. Deploy Custom Workflow WSP to Solution Management Store

• stsadm -o addsolution -filename
• stsadm -o deploysolution -name -immediate -allowGacDeployment

3. Copy Restore Database to...

• C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup

4. Stop All Workflow Auto Cleanup Timer Jobs

• Central Administration > Monitoring > Timer Jobs > Job Definitions > Workflow Auto Cleanup for > Disable

5. Remove CDB Database from

• Central Administration > Application Management > Databases > Manage Content Databases > > Remove Content Database > OK

6. Reset IIS - IISReset

7. Set the Content Database to Read Only

• SQL Server Management Studio > Databases > WSS_Content_MyCDB > Properties > Options > State > Database Read Only > True

8. Restore Database to SQL Server

• SQl Server Management Studio > Databases > Restore Database >
• General
• To Database (SPS 2010 CDB)
• From Device (MOSS 2007 Backup Copy)
• Check Restore
• Options
• Overwrite the Existing Database

9. Set Read Only Back to False

• SQL Server Management Studio > Databases > WSS_Content_MyCDB > Properties > Options > State > Database Read Only > False

10. Mount/Migrate the Database

• stsadm -o addcontentdb -url http://sp2010srv:8000 -databasename WSS_Content_cdbTestIPWF

11. Attach the Database to the Web Application

• CA > Application Management > Databases > Manage Content Databases > Add a Content Database > Database Name

12. Restart All Workflow Auto Cleanup Timer Jobs

• Central Administration > Monitoring > Timer Jobs > Job Definitions > Workflow Auto Cleanup for > Enable

Go to the SPS 2010 Sites, Lists and Libraries and test your migrated in-process workflows!


I hope that helps!

Tom

Migrate In-Process Workflows from MOSS 2007 to SPS 2010 (Part 1 of 2)

Part 2 of this Article is Located - Here

Recently I had the opportunity to develop a methodology for migrating in-process SharePoint workflows from MOSS 2007 to SPS 2010.  As you may be aware, in-process workflows are those workflows which have been started but which are not yet completed.  In this two part article I will provide a step-by-step methodology for migrating in-process workflows and thereby avoiding the gotcha's that are out there waiting for you. 

Understanding In-Process Workflow Migration

Before I dive into my methodology I wanted to provide a little background understanding of workflow processing:

Starting: Workflows can be Started in a Number of Different Ways

• Manually
• When an Item is Created
• When an Item is Changed
• Programmatically Through the API
• Programmatically Through the Web Service

 Hosting: Workflows can be Hosted by a Number of Different Processes

• W3wp.exe – When Started from the SharePoint Interface
• Owstimer.exe – When the Workflow is Delayed
• The Programmatic Process that Executes the Workflow Code

Delayed: When the Workflow Action needs to be Delayed the Workflow Dehydration Process Occurs

• The Windows Workflow Foundation Calls the SQL Workflow Persistence Service
• The SQL Workflow Persistence Service
• Assigns Correlation Token to Task
• Serializes Workflow Object – Turns Into Binary String
• Saves with a Unique ID in the Content Database

Reactivated: When the Workflow Action Needs to be Carried Out the Workflow Rehydration Process Occurs

• The Windows Workflow Foundation Calls the SQL Workflow Persistence Service
• The SQL Workflow Persistence Service
• Finds the Workflow task Using the Unique ID
• Deserializes Workflow Object – Turns Binary String Back Into an Object in Memory
• Performs Many Checks to Ensure the Right Workflow Object is Returned

 In-Process and In-Memory Workflows: Workflows can be In-Process and In-Memory (Not Dehydrated)

• Any Workflows that are In-Process and In-Memory will be Lost in Migration
• Custom Workflow Code can Prevent Workflows from Dehydrating – Therefore They Persist in Memory

DelayActivity – UnloadOnIdle: In-Process Workflows can be persisted in memory programmatically

• If Custom Workflow Code Uses a Delay Activity and UnloadOnIdle Property is Set to False the Workflow Object will Persist in Memory
• Custom Code Must be Reviewed and if Necessary Modified to Prevent UnloadOnIdle from Persisting Workflow Objects – Set Property to True

External Applications: If External Application Activate Workflows Within SharePoint then Those Workflows Could be In-Progress and In-Memory When Migration Occurs!

Preparing for In-Process Workflow Migration

Okay, now armed with this greater understanding we are ready to prepare for our workflow migration.  To start the process we must inspect the workflows on the MOSS 2007 Server Farm with concern for the following:

Ensure Workflows are Functioning Properly: Before attempting to perform a migration of In-Process Workflows you must first be sure the workflows are functioning properly

• Review ULS and Event Logs For Any Signs of Issues Related to Workflows
• Correct Issues Before Attempting Migration

Ensure DelayActivity – UnloadOnIdle is Set to True: You must also inspect any custom code to ensure it does not prevent the Workflow Dehydration Process

• Review Custom Workflow Code – Ensure UnloadOnIdle is Set to True
• Correct Any Code that Sets UnloadOnIdle to False

Run PreUpgrade Checker and Review Results: Run the preupgradecheck command on the Content Database(s) that is being migrated – inspect for additional key issues

• Issue ID: 956447 - The Declarative Workflow Actions File has been Modified
• Issue ID: 956448 - The Custom .ACTIONS Files Exist in the Farm
• Issue ID: 956449 - The Web.Config File Contains Modified Authorized Types for Workflows

If your Moss 2007 workflows meet all this criteria then they are ready for migration!

In part 2 of this article (coming soon!) I will provide the step-by-step process I use for migrating in-process workflows.

Many thanks to the great blog I found on the 14 folder.

I hope that helps!

Tom