[Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6 - Part 7]
SharePoint 2010 includes a couple of modifications related to content deployment and the content deployment and migration API.
In case you already had a chance to use the new version might have noticed a new option which is available if the Content Databases of the Source System are hosted on Enterprise Edition of SQL Server 2005 or 2008: the possibility to take a SQL snapshot before running the export and to use this snapshot to perform the export.
What are the benefits in using a SQL snapshot when it comes to exporting content? A major problem in MOSS 2007 and WSS 3.0 was that authoring activities could badly interact with the export operation. E.g. if an author was moving an item which was earlier identified as an item that should be exported but before the export reached this object the export could fail.
Other activities could lead to deadlocks between the export operation and the authoring activities.
Often such problems introduced during export did not lead to a failing export but later caused problems during import if required items were not exported.
Creating a database snapshot decouples the data used by the authors and the data used for export which guarantees that the data visible to the export operation will not change while the export runs.
This will guarantee that export operations in SharePoint 2010 will run much more stable. This also guarantees a much more stable import operation as the data being exported is more consistent.
Requirement for this functionality is that the SQL server in the backend supports Database Snapshots.
It is also possible to use database snapshots outside the Content Deployment feature using the content deployment and migration API:
The first step is to verify if the SQL backend supports Snapshots. If yes a new database snapshot is created. As a next step the database snapshot is mounted as an unattaced content database and the site collection to be exported is retrieved from the snapshot. Afterwards the SPExportSettings are configured as usual except of the UnattachedContentDatabase property which is specific to exporting from a database snapshot.
The SPExportSettings object has now two additional properties:
The purpose of the UnattachedContentDatabase property has been explained already above in the Export from Database Snapshots section.
ExportFrontEndFileStreams is a new property which allows controlling the export of file content of ghosted items. File objects for ghosted items are stored on the file system and not in the content database. Using the ExportFrontEndFileStreams settings allows to control whether the file content of ghosted files should be included in the export or not.
Setting this property to false will reduce the amount of data exported and can therefore also improve performance of the export/import operation.
The SPImportSettings object has now two additional properties:
ActivateSolutions is a new property which allows controlling whether user solutions installed in the site collection should be marked as activated after the import is completed. The default value for this property is "false" which means that user solutions will not be marked as activated.
IncludeUserCustomAction is a new property which allows to control whether User Custom actions (explained here) are imported or not. Possible values are "All" and "None". Default is "All".
Most of you might not notice this change: in MOSS 2007 a retry mechanism has been added to the export functionality (discussed in Pimp my Content Deployment Job) of the content deployment feature to handle situations where export failed due to concurrent export and authoring operations. This functionality also increased the complexity of the export functionality of the content deployment and migration API. As we now have a much better solution for this problem (utilizing SQL Snapshots) this retry functionality has been removed again which also simplified the logic in the export operation.
In MOSS 2007 we often had support calls where content deployment failed due to event handlers firing and updating content during import.
Event handlers or feature activation code which modifies site content on the target system can cause all kind of issues:
To overcome this problem developers had the challenge to either detect that the event handler was fired in context of an import operation (which was not trivial) or a different version of the event handler code had to be installed on the target system to avoid performing the operations.
With SharePoint 2010 there is now a new class available (SPImportContext) which allows an event handler or feature activation code to detect easily if they are fired in context of an import operation or not.
On SharePoint 2010 all event handlers and feature activation code which modify content in the database can now (and should) implement a check of SPImportContext.Current.IsRunning to detect if the code execution is a side effect of an import operation or not.
That allows a developer to implement a separate code path in the event handler which avoids problems during import.
SPImportContext provides the executing code access to the following information:
We have written some content migration jobs using the SP basic API as you explained in other parts of this thread. I have see na common issue that occurs once in a while. The site navigation settings get overwritten by some event post migration.
Hi Rajini, I haven't seen this.
Did SPS 2010 (or 2013) remove any of the constraints or pitfalls you mentioned in MOSS ? Particularly the need to have exactly the same patch levels on all participating farms (item 10) ? Should we always assume hotfixes can change published functionality like that ?
it was recommended to have the same patch level. In general deploying to a higher patch level will also work. But deploying to a lower patch level is not supported and can fail if schema changes are involved between the patch levels.