Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Due to problems we found with the restore of sites/site collections using stsadm (our tasks generated from workflows were not restored), we've taken a different route for backup/restore. We plan a major customization to our SP site and want to take a backup so we can rollback in case the install fails. In our System Testing (not production) environment, we've backed up the 12 hive, the virtual dir's that the IIS points to SharePoint, and the SharePoint databases in SQL (using SQL server to do the db backups).
We have custom event handlers and workflows built with Visual Studio, and deploy the dlls to the GAC as version 2 (signed and versioned in Visual Studio). So when we deploy, the GAC will contain 2 versions of the workflows - version 1 and version 2. During the deploy we use SP stsadm features to install/activate the WF's. We also go to each library and add the new, version 2 WFs. This automatically sets the version 1 WF's to "Not Allow" new instances (which is what we want) and the version 2 as active - perfect so far.

When we've completed the install, we then assume a failure and attempt to restore to the same machines (SharePoint on one server, SQL on another). We start by uninstalling the version 2 WF's from the GAC, reset IIS (to clear cache of these ver. 2 WF dlls'), restore the 12-hive and virtual directory folders, then restore the SQL dbs. This is all just as manual as you read it - no stsadm here. All seems to work after our restore, it appears the restore was successful - the mods we made to column names, data changes, etc during the install are all reverted back to the original pre-install state. With one exception. When we run a workflow, it always fails and the Logs in the 12-hive indicates the WF is still trying to use the version 2 of the dll (System.IO file not found error) We think we've backed up and restored all the moving pieces of Sharepoint but we're missing something here, does anybody have any ideas why the version 2 WF dlls are still being referenced eventhough we restored all the folders and db's of SharePoint?

Thanks, Kevin

share|improve this question
1  
Update - I have it on good authority that the SP Config database cannot be restored in the manner we are attempting, it just won't work. We're still using the RTM version and have also been told that the patches and hotfixes for SP2007 includes 50+ fixes for backup/restore, we need to upgrade. That would explain our problem with stsadm not restoring the Tasks that were generated from our Workflow. We're looking at the AvePoint product DocAve Backup and Recovery to do our backup. Will post again if it is successful. Kevin –  Kevin Sep 3 '09 at 21:37
1  
restore of configuration db is not supported. The "restore method" to restoring the content is creating a new farm and setting the values appropriately for the new environment. –  shufler Sep 14 '09 at 18:00
add comment

3 Answers 3

Kevin,

If I'm properly understanding your order of operations, I have one big question: are you restoring content databases but leaving the farm configuration database (and other databases, like SSP databases) intact during your restore? If the answer is "yes," then I suspect that SharePoint is throwing a fit because your configuration database still maintains a reference to v2 of your workflow. Here's what I suspect might be happening.

When you install a Feature to your SharePoint farm, the SPFarm.FeatureDefinitions collection (which is maintained in the farm configuration database) is updated to reflect what you added. This includes all the standard information you'd expect your Feature to contain: name, scope, ID, version, etc. It also maintains FeatureReceiver assembly information and a RootDirectory value, amongst other things. The RootDirectory property points to the folder in the 12-hive where the Feature manifest is located for the Feature.

When you add your v2 workflow Feature to the farm and activate it, the configuration database is updated. Even if you restore a pre-v2 workflow version of your content database, the farm is still going to be looking for v2 of your workflow because of the Feature association that is maintained at the configuration database level. If the v2 Feature folder still exists in the 12-hive and its manifest points to the v2 assembly in the GAC, it's easy to see where problems might arise.

At the same time, if your workflow Feature leverages a FeatureReceiver, that information is also stored (in the configuration database) in the ReceiverAssembly property of the FeatureDefinitions collection when the Feature has been installed.

If I'm mistaken and you're actually restoring your entire farm in-place (including configuration database), then what I've written doesn't apply. In that case, I would be left scratching my head a bit, too. :-)

I hope this helps!

share|improve this answer
1  
Sean, Thanks for the reply. We double checked and we are backing up all the SharePoint databases - content, config, all. We use the SQL backup, then we restore with "Overwrite", all db's report back 100% complete, no errors. So we are still at a loss as to where it's getting the v2 assembly reference. Thanks again, Kevin –  Kevin Aug 28 '09 at 18:20
    
If you're backing up the databases and file system first (12-hive + inetpub folders), installing and deploying your Feature after that, and then seeing references following a file system + DB restore ... I guess I'm at loss. The only other OOTB references would be search index information, but that doesn't explain (to me, anyway) where the assembly references are being held. You could explicitly dump the ASP.NET JIT/temp compilation area for good measure, but I have a hard time believing that's in play. If you gain additional insight, please post. I'm very interested! –  Sean McDonough Aug 28 '09 at 19:50
add comment

Could you try to remove the workflow bindings from the lists after you have completed the install, so first you delete all workflow associations from the list, then remove the V2 dll's from the GAC, then redeploy dll's, then reassociate the workflows, to make sure all remaining references to the workflows are gone (from both the content db and config db) and force sharepoint to rebind / reconfigure the workflow associations.

P.S. It is VERY strange the workflow related tasks are not restored, they are nothing more than content and should be in the content db, I think the workflow tasks are bound to a workflow which is not restored correctly (seeing as workflow associations are stored both in the content db and the config db...). When the restore takes place, the workflows are basically reinitialized, getting a new GUID etc. To sharepoint, this would seem to be a new workflow, so the tasks relating to the old workflow cannot be bound anymore).

I suggest you delve deeper into the actual problem instead of creating a custom solution.

have a look at this site and this article for more info on workflow related restore / packaging troubles and how a workflow is actually saved / created..

share|improve this answer
1  
Hi Colin, If we do what you suggest in your first paragraph, removing all workflow associations, then we'll lose all the tasks that were created by workflow V1.0. I can see how stsadm might want to generate new GUIDs, but that doesn't make sense if stsadm provides a backup/restore, then it should restore 100%. Our method would seem to eliminate that possibility in that we're backing up all the databases, and presumably all associations. Don't know why after our restore process I described, that V2 of the workflow is being referenced. –  Kevin Sep 2 '09 at 15:44
add comment

I've never used it (not even a Sharepoint guy), but this might work for you. Stumbled on it on CodePlex...

http://spbackup.codeplex.com/

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.