Symptom

A content deployment job between servers with different update levels may 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 both to content deployment jobs run using the Central Administration Web site, as well as using the Stsadm export and import operations.

Cause

Content deployment is only supported if the Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 update levels are identical on both the source and destination servers, or if the update level on the destination server is higher than the update level on the source server.

Resolution

Ensure that all servers in the farms have had all the current Office SharePoint Server 2007 and Windows SharePoint Services 3.0 hotfixes installed.

Symptom

A content deployment job will fail if a required language pack is missing from the destination site collection.

Cause

Language packs used in the source site collection must also be installed on the destination site collection.

Resolution

Install the required language packs on the destination site collection, and rerun the content deployment job.

Symptom

The content deployment job will fail as soon as it tries to upload a .cab file that exceeds 29 MB. The following entries will be shown in the application event log of the export (source) server:

Event ID: 5323 Source: Content Deployment Description: Failed to transfer files to destination server for content deployment job 'test 1'. Exception was 'System.Net.WebException: The remote server returned an error: (404) Not Found. Event ID: 4958 Source: Content Deployment Description: Publishing: Content deployment job failed. Error: 'System.Net.WebException: The remote server returned an error: (404) Not Found. Event ID: 6398 Source: Windows Sharepoint Services Description: The Excecute method of job definition Microsoft.Sharepoint.Publishing.Administration.ContentDeploymentJobDefination threw an exception. The remote server returned an error (404) Not Found.

In addition, you will find entries similar to the following in the Unified Logging Service (ULS) log on the export server:

OWSTIMER.EXE (0x0778) 0x079C CMS Content Deployment 0 Unexpected ContentDeploymentJob.DoServerToServer: Remote connection failed while uploading files for source-Job 'Test' with exception 'The remote server returned an error: (404) Not Found.'

To verify that the problem is the upload size of the .cab file, you must check the IIS log on the import (destination) server to see if the response is a 404.13 error similar to the following:

2008-09-01 08:55:08 10.10.10.2 POST /_admin/Content+Deployment/DeploymentUpload.aspx filename=%22ExportedFiles13.cab%22&remoteJobId=%11456fa7ed-ddcdedcdd-9aae-a1adsf5re1db%22 1976 - 10.10.10.3 - 404 13 0 62

Cause

Content deployment first exports all content to the file system as XML and binary files, and then packages these files into .cab files. These files are then uploaded by using HttpPost 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 MB; however, IIS 7 has a preconfigured upload limit of 29 MB. Office SharePoint Server 2007 does not split single exported files into multiple .cab files. Therefore, if a Office SharePoint Server 2007 site contains single documents that cannot be compressed to less than 10 MB, and the resulting .cab file size exceeds the IIS 7 default upload limit of 29 MB, the content deployment job will fail.

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/?LinkId=149968).

Resolution

Modify the web.config file of the Central Administration Web site, and add an entry similar to the following:

<system.webServer>
    <security>
        <requestFiltering>
            <requestLimits maxAllowedContentLength="52428800"/>
         </requestFiltering>
    </security>
</system.webServer>

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, 52428800 equals 50 MB. You should adjust this value to the specific needs of your deployment environment. When you are finished, rerun the content deployment job.

Symptom

When using the Stsadm export operation or when a content deployment job fails during the export phase, the following error message will be returned in the command window or in the event log: "Failed to create package file. Unknown compression type in a cabinet folder."

Cause

This problem is almost always caused by insufficient disk space on the source server.

Resolution

Monitor the disk space during the export and compression phase, and ensure that sufficient disk space is available on the source server to perform this operation.

Symptom

The content deployment import process cannot handle duplicate column names between site collections and sites. This will result in an error message similar to the following:

A duplicate name "MyCustomField" was found.

   at Microsoft.SharePoint.SPFieldCollection.AddFieldToWeb(String strXml, Boolean checkDisplayName)

   at Microsoft.SharePoint.SPFieldCollection.AddFieldAsXmlInternal(String schemaXml, Boolean addToDefaultView, SPAddFieldOptions op)

   at Microsoft.SharePoint.Deployment.FieldTemplateSerializer.CreateField(SPWeb web, SerializationInfoHelper infoHelper)

   at Microsoft.SharePoint.Deployment.FieldTemplateSerializer.SetObjectData(Object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector)

   at Microsoft.SharePoint.Deployment.XmlFormatter.ParseObject(Type objectType, Boolean isChildObject)

   at Microsoft.SharePoint.Deployment.XmlFormatter.DeserializeObject(Type objectType, Boolean isChildObject, DeploymentObject envelope)

   at Microsoft.SharePoint.Deployment.XmlFormatter.Deserialize(Stream serializationStream)

   at Microsoft.SharePoint.Deployment.ObjectSerializer.Deserialize(Stream serializationStream)

   at Microsoft.SharePoint.Deployment.ImportObjectManager.ProcessObject(XmlReader xmlReader)

   at Microsoft.SharePoint.Deployment.SPImport.DeserializeObjects()

   at Microsoft.SharePoint.Deployment.SPImport.Run()

Cause

If you create a new column named "MyCustomColumn" in a subsite of a site collection, and then you create a column with the same name in the root site of the site collection, when you return to the subsite, there will now be two columns listed with the same name. Such a configuration will cause content deployment jobs to fail.

Resolution

Ensure that column names are unique. If necessary, delete the duplicate column, and then recreate it with a new name in either the subsite or the root site. When you are finished, rerun the content deployment job.

Symptom

In the event that an item on the destination server has the same URL but a different GUID as an item that is being imported, the content deployment job will fail, and the Content Deployment Report will return an error similar to the following:

The Web site address "/A" is already in use." or "The specified name is already in use. A document cannot have the same name as another document or folder in this document library or folder.

Cause

Items in the content deployment job that are scheduled for import should either not exist on the destination server, or should be older versions of the items that are currently being deployed. If the content deployment job finds an item with the same URL as an item being imported, it checks the GUID of the item to verify that it is the same item as the one being imported. If the GUID is the same, import will create a new version, provided versioning has been enabled on the destination server, or it will replace the item on the destination site. If the GUID is different, it returns an error message, and the content deployment job will fail.

Resolution

Ensure that no content is added to the destination server that is identical to content that exists on the source server. In general, you should not permit any authoring activity to be done on the destination server at all.

Symptom

The content deployment job fails with an error message similar to "The form submission cannot be processed because it exceeded the maximum length allowed by the Web administrator. Please resubmit the form with less data."

Cause

The Web application 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 deployment will fail.

Note:
Although the content deployment job will still succeed, parts of the site may not have been deployed, so be sure to review the content deployment report for warnings or non-fatal errors, even if the status of the job is Succeeded. For information about how to view the content deployment report, see View a content deployment job report.

Resolution

Ensure that the maximum upload size of the Web application on the destination server is at least as big 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 Web application general settings.

If the content deployment job failed, simply rerun the deployment job. If the job completes with the status Succeeded, but the report contains warnings or errors, do one of the following:

• Do a full deployment into an empty destination database.

  -or-

• Modify the items that were not deployed to ensure that the next incremental deployment job will pick them up again the next time it runs.

Symptom

Sometimes a document on the source server is marked as being virus-infected when this is not actually the case. The Content Deployment Report may contain an error message similar to the following:

Exception from HRESULT: 0x80041050 at Microsoft.SharePoint.Library.SPRequest.GetFileAsByteArray(String bstrUrl, String bstrWebRelativeUrl, Boolean bHonorLevel, Byte iLevel, OpenBinaryFlags grfob) at Microsoft.SharePoint.Deployment.FileSerializer.SaveFile(SerializationInfo info, ExportObjectManager objectManager, ExportDataFileManager fileManager, SPExportSettings settings, SPWeb parentWeb, Boolean isGhosted, String setupPath, String setupPathUser, Byte setupPathVersion, String webRelativeFileUrl, Int32 size, Byte level)

Cause

If something goes wrong with the virus scanning phase during the upload—such as the signature files were in the process of being updated while the document was uploaded—it can cause the uploaded files to be incorrectly marked as being virus-infected.

Note:
Items marked as being virus-infected cannot be exported.

Resolution

To determine whether or not the file is actually infected, you will need to look at the error message for the specific error code 0x80041050. This means that the item is virus-infected. If the item is virus-infected, either delete the infected item, or attempt to clean it using your virus scan application. If the item is not virus-infected, restart the content deployment job.

Symptom

In some cases, using the Stsadm import operation to import content into an empty site collection causes the import operation to fail at different points during the import. When this happens, the ULS log will contain errors similar to the following:

10/20/2008 12:47:26.59 STSADM.EXE (0x78BC) 0x4FF4 Windows SharePoint Services Database 6f8g Unexpected Unexpected query execution failure, error code 1205. Additional error information from SQL Server is included below. "Transaction (Process ID 123) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction." Query text (if available): "..."

Cause

Such behavior is usually an indication that asynchronous actions have interacted with the import operation, causing a deadlock on the computer that is running SQL Server. If you have custom event receivers in a site collection that perform actions similar to authoring events, such as creating new items, or moving items from one location to another, the firing of these event receivers may cause a deadlock on the computer that is running SQL Server.

Note:
This happens when using the Stsadm import operation. It can also happen when content deployment is used from the Central Administration Web site, if event receivers have been enabled using the Stsadm editcontentdeploymentpath operation with the enableeventreceivers parameter is set to Yes.

Isolating this issue can be difficult, because SQL Server tries to stop one of the deadlocking queries as soon as possible, while the child process (in this case Stsadm.exe, and potentially a second process, such as Owstimer.exe or a third-party import tool) continues to run until it finally fails, due to the fact that the query was not successful.

It is possible to isolate the issue in a test environment by attaching a debugger to the computer running SQL Server and setting a breakpoint right before the deadlock query is stopped. This will cause the deadlock to persist, and enable you to create a memory dump of Stsadm.exe and the other involved processes.

Resolution

To resolve the issue, you must do one of the following:

• Disable the event receivers in the features on the destination server when performing the import.

  -or-

• Create a custom import application that uses the content deployment and migration API, and sets the SuppressAfterEvents property to true. For information about importing items, see Deep Dive into the SharePoint Content Deployment and Migration API - Part 3 (http://go.microsoft.com/fwlink/?LinkId=149969).

Symptom

If you have a large content deployment job running with several gigabytes of content, the decompression phase can take longer than the default time of 600 seconds (10 minutes), which will result in a timeout.

Cause

During the import process, the export server that hosts the content deployment job definition polls the import server at regular intervals to get the status of the import operation at each phase of the process. These intervals are based on a timeout value that defines the maximum amount of time allowed between changes to the status report. During the actual import, the report changes frequently; however, some phases of the import process take more time than others. If the amount of time a particular phase takes exceeds the remote timeout value, then a timeout is reported back to the export server.

Note:
If you see such a timeout status in the content deployment job, it does not mean that the import has failed. It just means that no status update has arrived in the configured amount of time.

Use the following procedure to determine whether or not the deployment has succeeded or failed.

To determine the status of a content deployment job

Resolution

To avoid these timeout messages, you can adjust the RemoteTimeout property on the exporting server. The following code sample enables you to configure the RemoteTimeout property value to one hour.

using System;
using Microsoft.SharePoint.Publishing.Administration;

namespace CustomContentDeployment.Tools
{
    class AdjustContentDeploymentDeploymentSettings
    {
        static void Main(string[] args)
        {
            ContentDeploymentConfiguration config =
ContentDeploymentConfiguration.GetInstance();
            config.RemoteTimeout = 3600;
            config.Update();
        }
    }
}

For information about using the RemoteTimeout property, see ContentDeploymentConfiguration.RemoteTimeout Property (Microsoft.SharePoint.Publishing.Administration) (http://go.microsoft.com/fwlink/?LinkId=149970).

Symptom

An incremental content deployment job fails with the error message "The changeToken refers to a time before the start of the current change log."

Cause

The time span between the current job and the last incremental deployment job is too long. Office SharePoint Server stores the change token of the last successful incremental deployment inside the properties of the incremental content deployment job. When a new incremental deployment is run, Office SharePoint Server 2007 compares the change token in these settings with the entries in the change log.

By default, the change log is configured to keep a record of any changes for 15 days. If the time span between two incremental deployment jobs exceeds this time span—for example, if it has been 20 days since the last content deployment job was run—then the change log will not contain entries from before the last change token. As a result, the incremental deployment will not start in order to prevent only parts of the required content from being deployed.

Note:

You might also receive this error if the source database has been overwritten with a backup copy. When a database is restored using the Stsadm restore operation, or by using a SQL Server backup and the Stsadm addcontentdb operation, the change log is cleared. In this case, incremental deployment will not work, and you must do a full deployment into an empty destination database in order to synchronize the content.

Resolution

Increase the time span for which the change log entries should be preserved, using the following procedure:

To change the time span for preserving change log entries

The Office SharePoint Server 2007 Content Publishing team thanks Stefan Goßner, Escalation Engineer for SharePoint Technologies, for contributing to this article. His blog can be found here (http://go.microsoft.com/fwlink/?LinkId=150013).