locked
Content Deployment Error RRS feed

  • Question

  • Hi, we have content deployment setup and working smoothly from Authoring to QA to Staging. From Staging to Production we are getting the error below whether we do a full or incremental deployment. It always breaks at the same point ZZ1_Black.css - it is the first OOTB css in the Style Library. Any insight on how to fix this is greatly appreciated.

    [3/29/2010 2:54:41 PM]: Progress: Importing ListItem /Style Library?id=54.
    [3/29/2010 2:54:43 PM]: FatalError: Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))
       at Microsoft.SharePoint.Library.SPRequest.GetFileAndFolderProperties(String bstrUrl, String bstrStartUrl, ListDocsFlags ListDocsFlags, Boolean bThrowException, Int32& phrStatus, Object& pvarFiles, Object& pvarDirs, UInt32& pdwNumberOfFiles, UInt32& pdwNumberOfDirs)
       at Microsoft.SharePoint.SPWeb.GetFileOrFolderProperties(String strUrl, ListDocsFlags listDocsFlags, Boolean throwException)
       at Microsoft.SharePoint.SPFile.PropertiesCore(Boolean throwException)
       at Microsoft.SharePoint.SPFile.get_Properties()
       at Microsoft.SharePoint.SPFile.get_Level()
       at Microsoft.SharePoint.Deployment.FileSerializer.CheckInFile(SPFile file, Guid fileId, String fileUrl, SPUser editor, SPImportSettings settings)
       at Microsoft.SharePoint.Deployment.ListItemSerializer.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()
    Wednesday, March 31, 2010 3:55 PM

Answers

  • Hi Lu Zou,

    We had all the settings correct. That's basic to content deployment setup. We were already successful from Authoring to QA to Staging=(same domain as PROD).

    I finally resolved the problem. The generic error message usually refers to a corrupt file, xml, or access denied. It was a combination of both a corrupt file (zz1_black.css) and permissions inside SharePoint. During the first full content deployment (to an empty site), MOSS did not activate all the publishing features in the sites specifically those created by the publishing feature - Style Library, Site Collection Images. Somehow, even if the permissions in these libraries were showing as inherited from parent, it was not really functioning as such. This is not the first time I came across permissions inheritance issues with SharePoint. That's another topic - just remember that when you suddenly get "error access denied" look at the library permissions first. The Style Library files were corrupted and since the SharePoint database points to those files, we could not get past them. This is how we implemented the resolution:

    • gave SPAdmin account (content deployment account) explicit full control permission to the style library folder in the PROD server
    • Deleted all zz_xxxx files in the style library folder and replaced them with a copy from the source (Staging)
    • edited permissions for all publishing feature created libraries. Broke inheritance and reinherited
    • made SPAdmin account a site collection admin of the target site (checked that SPAdmin had full control over all publising feature created libraries)
    • Used the Content Deployment Wizard to export the libraries from source with dependencies and imported to the target (APPEND mode) retaining object identity . This in effect modified the sharepoint database record referring to these libraries and their items.
    • Ran an incremental job for one site from source to target. Took about 2 hours as the job started to create a change token. (First incremental job is usually a Full job)
    • Once successfull and a change token was in place, all other incremental jobs for the rest of the sites in the collection went fast and smooth. Incremental jobs now average 2 minutes.

    We now have a running OOTB content deployment from Authoring to QA to (different domain) Staging to Prod. It's a beauty when it works. The trick is making it work the first time.

    RacsoL

    • Marked as answer by Lu Zou-MSFT Sunday, April 11, 2010 6:08 AM
    Wednesday, April 7, 2010 1:41 PM

All replies

  • Hi Racsol,

    Please check the following settings first:

    1.       Configured the domain account as moss service account.

    2.       Disable the Antivirus on both import and export MOSS Farms

    3.       Check both import and export server and have enough available disk space to store the jobs, and they must be running an administration Web application for the farm.

    4.       Enable “accept content deployment jobs” in content deployment settings.

    If these settings are all right, did you find error message in event viewer?

    Lu Zou

     

     

     

    Wednesday, April 7, 2010 11:54 AM
  • Hi Lu Zou,

    We had all the settings correct. That's basic to content deployment setup. We were already successful from Authoring to QA to Staging=(same domain as PROD).

    I finally resolved the problem. The generic error message usually refers to a corrupt file, xml, or access denied. It was a combination of both a corrupt file (zz1_black.css) and permissions inside SharePoint. During the first full content deployment (to an empty site), MOSS did not activate all the publishing features in the sites specifically those created by the publishing feature - Style Library, Site Collection Images. Somehow, even if the permissions in these libraries were showing as inherited from parent, it was not really functioning as such. This is not the first time I came across permissions inheritance issues with SharePoint. That's another topic - just remember that when you suddenly get "error access denied" look at the library permissions first. The Style Library files were corrupted and since the SharePoint database points to those files, we could not get past them. This is how we implemented the resolution:

    • gave SPAdmin account (content deployment account) explicit full control permission to the style library folder in the PROD server
    • Deleted all zz_xxxx files in the style library folder and replaced them with a copy from the source (Staging)
    • edited permissions for all publishing feature created libraries. Broke inheritance and reinherited
    • made SPAdmin account a site collection admin of the target site (checked that SPAdmin had full control over all publising feature created libraries)
    • Used the Content Deployment Wizard to export the libraries from source with dependencies and imported to the target (APPEND mode) retaining object identity . This in effect modified the sharepoint database record referring to these libraries and their items.
    • Ran an incremental job for one site from source to target. Took about 2 hours as the job started to create a change token. (First incremental job is usually a Full job)
    • Once successfull and a change token was in place, all other incremental jobs for the rest of the sites in the collection went fast and smooth. Incremental jobs now average 2 minutes.

    We now have a running OOTB content deployment from Authoring to QA to (different domain) Staging to Prod. It's a beauty when it works. The trick is making it work the first time.

    RacsoL

    • Marked as answer by Lu Zou-MSFT Sunday, April 11, 2010 6:08 AM
    Wednesday, April 7, 2010 1:41 PM