Migrate In-Process Workflows from MOSS 2007 to SPS 2010 (Part 1 of 2)
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.
Migrate In-Process Workflows from MOSS 2007 to SPS 2010 (Part 2 of 2)
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!
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.
Migrate In-Process Workflows from MOSS 2007 to SPS 2010 (Part 2 of 2)
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!
No comments:
Post a Comment