Best practices for content deployment (SharePoint Server 2010)
Applies to: SharePoint Server 2010
This article is one of a series of Best Practices articles for Microsoft SharePoint Server 2010. This article describes best practices for using content deployment. For additional information and resources about content deployment, see Web content management in SharePoint Server 2010 (http://go.microsoft.com/fwlink/p/?LinkID=220230).
For more articles in the series, see Best practices (SharePoint Server 2010). For additional information and resources about best practices for SharePoint Server 2010, see the Best Practices for SharePoint Server 2010 resource center (http://go.microsoft.com/fwlink/p/?LinkID=220280).
1. Ensure that the source and destination server farms have identical updates
Content deployment is only supported if the update levels on the source servers are identical to the update levels on the destination servers. To help ensure that content deployment jobs are successful, use the following guidelines:
Ensure that all servers in the farms have had all the current SharePoint Server 2010, Windows Server 2008 R2, and Windows Server 2008 SP2 updates applied.
A content deployment job between servers that have different update levels might fail if hotfix releases have changed the schema of the export packages so that the source server has a higher update level than the destination server. This applies to content deployment jobs run by using the Central Administration Web site or by using the Windows PowerShell Export-SPWeb and Import-SPWeb cmdlets.
Language packs used in the source site collection must also be installed on the destination farm. A content deployment job fails if a required language pack is missing from the destination farm. For more information, see Deploy language packs (SharePoint Server 2010).
If you have custom code or custom SharePoint solution packages on the source server, you must also deploy those items on the destination server. This includes any assemblies that are not included in the .wsp file that must be installed in the global assembly cache on the destination server.
If you have features that are installed on the source server, you must install — but not activate — them on the destination server before you run a content deployment job that deploys content to the destination server. Typically, deploying a solution package should install all features to the destination server. However, if you are not using .wsp files, ensure that all features are installed but not activated.
During the import process on the destination server, any site collection features that are required by items that are included in the import are activated. The content deployment job fails if features that it requires are not installed on the destination server. For more information, see "Problem 9: Features used in the site collection are missing on the exporting server" in Content Deployment - Best Practices (http://go.microsoft.com/fwlink/p/?LinkId=223429).
2. Make sure that the destination server can accommodate the size of the CAB files for import
Content deployment first exports all content to the file system as XML and binary files, and then packages these files into CAB files. The CAB files are then uploaded by using HTTP POST to the destination server, where they are extracted and imported. The preconfigured maximum size of the CAB files generated by the content deployment process is 10 megabytes (MB). SharePoint Server 2010 does not split single exported files into multiple CAB files. Therefore, if a SharePoint Server 2010 site contains single files that cannot be compressed to smaller than 10 MB, and the resulting CAB file size exceeds the value defined below, the content deployment job fails.
If the size of CAB files in content deployment jobs on the server exceeds the value in the attribute below, make sure that you adjust the allowed file size on the destination server by modifying the Web.config file in \Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\ADMIN\Content Deployment. To do this, modify the existing entry, similar to the following:
<system.webServer> <security> <requestFiltering> <requestLimits maxAllowedContentLength="157286400"/> </requestFiltering> </security> </system.webServer>
The value of the maxAllowedContentLength property is a number, expressed in bytes, that represents the maximum size of the CAB file to be uploaded to the server. In this example, 157,286,400 equals 150 MB. You should adjust this value to the specific needs of the deployment environment. Please note that the default value for this attribute in SharePoint Server 2010 is "104857600".
For more information, see KB article 925083, Error message when you try to upload a large file to a document library on a Windows SharePoint Services 3.0 site: "Request timed out" (http://go.microsoft.com/fwlink/p/?LinkId=149968).
3. Make sure that the value for maximum upload size on the destination Web application is large enough to accommodate the files that are being deployed
The Web application that hosts the Central Administration Web site on the destination server is often created with default values, which means that the maximum upload size is set to 50 MB. If the source site collection contains files that are bigger than the upload limit on the destination server, the content deployment job fails.
Make sure that the maximum upload size of the Web application that hosts the Central Administration Web site on the destination server is at least as large as the largest item in the source site collection. For information about how to change the maximum upload size for a Web application, see Configure settings for a Web application (SharePoint Server 2010).
Although the content deployment job succeeds, parts of the site may not have been deployed, so make sure that you review the content deployment report for warnings or non-fatal errors, even if the status of the job is Succeeded. For more information, see View content deployment job reports and history.
4. Make sure the source and destination servers have enough hard disk space for storing the files that are used during export and import
During export, all files to be included in the content deployment job are stored in a temporary directory in the export server farm and are compressed before they are sent to the destination server for import. Likewise, during import, files to be imported into the database are stored in a temporary directory on the destination server farm. By default, the compressed and uncompressed files are put in separate directories. Make sure that the locations of the temporary directories for each server farm have sufficient disk space to accommodate the files that are included in the deployment job. For more information, see "Temporary files" in Content Deployment - The Complete Guide - Part 3 - Configuration (http://go.microsoft.com/fwlink/p/?LinkId=223430).
5. The export and import servers must each host an instance of the Central Administration Web site
When you configure content deployment settings for the server farm, you select the servers in the server farm to designate as export servers and import servers for content deployment. The Central Administration Web site must be deployed on each export and import server. If you configure an export or import server and later remove the Central Administration Web site from the server, no error message is displayed, and the export or import phase of the content deployment job does not start.
6. Always deploy an initial content deployment job to an empty site collection
If a site collection already contains content, the initial content deployment job might fail. To create an empty site collection on the destination server, use the < Select template later > option on the Custom tab of the Create Site Collection page in Central Administration. The first time that the content deployment job runs, the correct template and all associated configuration settings are applied to the destination server.
Do not use the Blank Site template to create a destination site collection. The Blank Site template does not create an empty site collection and can cause the content deployment job to fail.
7. If content deployment jobs will run infrequently, adjust the time for keeping changes in the change log
By default, the change log is configured to keep a record of any changes for 60 days. If the time between two incremental deployment jobs exceeds this time — for example, if it was 70 days since the last content deployment job was run — the change log will not contain entries from before the last change token. If the time between jobs will be more than 60 days, change the number of days specified for the Web application in Central Administration. For information about how to change the length of time that entries are kept in the change log, see Understand and Configure Resource Throttling on SharePoint Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=223768).
8. Do not run content deployment jobs in parallel if the same path is used by both jobs
Changes that were made by one job might conflict with changes that were made by another job that is running along the same content deployment path at the same time. If this happens, the content deployment job might fail.
9. Run custom deployment jobs and scheduled content deployment jobs at different times
Do not mix scheduled content deployment jobs with custom content deployment jobs that are created by using Windows PowerShell 2.0, the Stsadm command-line tool, or custom code. If you try to run both kinds of content deployment jobs at the same time, the jobs may fail.
10. Educate users before you enable Quick Deploy jobs
A Quick Deploy job might fail if a page author includes references to sites, lists, or other items that have not already been deployed by a non-Quick Deploy deployment job. If you plan to enable Quick Deploy jobs within the farm, make sure that users understand the content deployment process and the timing and scope of content deployment jobs used by your organization. Also consider limiting the number of users who are members of the Quick Deploy users group. For more information about Quick Deploy jobs, see Content Deployment – The Complete Guide – Part 5 – Quick Deployment (http://go.microsoft.com/fwlink/p/?LinkId=223431).
11. Do not edit the destination site directly
If you have to quickly deploy content changes, do not directly edit the destination site because the next time content is deployed, it will be overwritten. Instead, use a Quick Deploy job to quickly update the site. For more information, see Manage Quick Deploy jobs.
12. Use SQL Server database snapshots on the export server
By using the SQL Server database snapshot option, you eliminate the possibility that users might edit content in the content database while a content deployment job is running. When the database snapshots option is enabled, a snapshot of the source content database is created before the export phase of the content deployment job starts. The content deployment job then uses the database snapshot to perform the export, instead of exporting directly from the live content database. After the export is successfully completed, the snapshot is deleted. The SQL Server database snapshot option is available only if the database server is running Microsoft SQL Server 2008 Enterprise.
13. Make the code content deployment–aware
Care must be taken when solution packages deploy features that add data to the content database. The data must be added to the content database on only the source farm. Content deployment will move any necessary data from the source site to the destination site during the deployment job. To avoid conflicts during the import operation, make sure that any custom event receivers or feature receivers that modify site content on the destination site use the SPImportContext class. This class enables event handlers and feature activation code to detect whether they are running in the context of an import operation. In this manner, developers can implement code to avoid potential problems during the import phase of content deployment. For example, if a feature receiver contains custom code that adds a new item to a list, the developer must make sure that the feature receiver algorithm detects whether it is running in the context of a content deployment operation and — if it is — skip any data updates if the detected role is a destination site. During import, the new list item feature receiver will be activated on the destination site. If the feature receiver does not detect the site's role, it will add the new piece of content to the destination site. The import process will then try to import the same content from the source site. This can result in either an import error or duplicate content on the destination site. Developers who create feature receivers must be aware of this limitation and write appropriate code. For more information, see SPImportContext Class (http://go.microsoft.com/fwlink/p/?LinkId=223433) and Write content deployment aware Event Handlers and Feature Activation code in SP2010 (http://go.microsoft.com/fwlink/p/?LinkId=223432).
The SharePoint Server 2010 Content Publishing team thanks the following contributors to this article:
Ethan Gur-Esh, Microsoft Enterprise Content Management
Israel Vega, Jr., Microsoft Consulting Services
Josh Stickler, Microsoft Enterprise Content Management
Stefan Goβner, Microsoft SharePoint Escalation Services
Steve Walker, Microsoft SharePoint Customer Advisory Team