1

I have a SharePoint 2007 farm (w/ SP2, June cumulative update) hosting an Internet site and am seeing the nightly content deployment incremental job that moves content from our staging environment to production fail with the error below. When this happens the only way we know to resolve it is to manually run a full deployment. However the issue seems to come back again in a few days. Any advice on how to isolate the root cause of this problem and correct it?

A duplicate name "9f2cdd1e-e4a5-433c-b4eb-f2baf9a46f0f" was found. at Microsoft.SharePoint.SPFieldCollection.AddFieldAsXmlInternal(String schemaXml, Boolean addToDefaultView, SPAddFieldOptions op) at Microsoft.SharePoint.Deployment.ListSerializer.CreateOrUpdateField(SPList list, String fieldName, XmlNode fieldNode) at Microsoft.SharePoint.Deployment.ListSerializer.UpdateListFields(SPList list, Dictionary`2 listMetaData) at Microsoft.SharePoint.Deployment.ListSerializer.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()

Ryan
  • 101
  • 1
  • 1
  • 9

3 Answers3

1

You are getting a collision between what has been deployed and the new content. Cannot identify what your problem is, but here are some possibilities:

  • You are deploying something that is previously been deployed
  • Same content in two packages, crash when second package is deployed
  • Same Guid for two different content items with same name
  • Same name for two different content items with same guid
  • Guid of a content item changed between depolyments
  • Name of a content item changed between deployments

How do you deploy to your stage environment? Does the the error occur when you change which machine is used to build the solution?

Shiraz Bhaiji
  • 2,219
  • 8
  • 34
  • 47
  • Thanks Shiraz, to answer your question, we use the built-in content deployment to deploy from an Authoring server to a Staging server and then to Production. The Staging environment is just a temporary holding location (read-only) for the content until the scheduled time for it to be promoted on to Production. – Ryan Sep 10 '09 at 22:17
  • Also, we only see this error when the content moves from Staging to Production. Never do we see it when it first moves from Authoring to Staging. – Ryan Sep 10 '09 at 22:18
1

Ryan,

I agree with Shiraz's basic premise; the stack trace certainly seems to indicate that you're getting a collision with an existing object. Some additional thoughts:

  1. You indicated that your staging environment is read-only. Is your production environment read-only?

  2. Is there any chance that someone or some process is altering an existing item/object in the production environment ... or introducing a change (e.g., rolling back to a previous version, changing publishing dates, etc.) I've seen this happen and produce the scenario you're encountering.

To rule out unintentional production changes: if your production site collection isn't in read-only mode, is it possible for you to place it in such a state? If not, can you enable site collection auditing to see if changes are being introduced in unintentional ways?

Based on the details of your stack trace, it looks like your import operation is failing with the addition or modification of some list data -- could be a standard list item, or it could be publishing page related (since publishing pages are really just specialized list items themselves).

You indicated that a full deploy is needed to resolve the incremental failures. You probably already know this, but a full deploy doesn't necessarily get you "out of the woods" for good. With a full deploy, you're overwriting change token information that is needed by incremental deploys in order to know what should be updated, changed, and deleted. Many iterations of mixed incremental and full deploys can lead to some very weird artifacts, particularly if objects are being deleted prior to content deployment.

One last tidbit: have you attempted to run a problematic content deployment from the command line (via STSADM.exe)? Doing so gives you additional visibility into the process, as well as additional messages that may be of assistance in troubleshooting.

I hope this helps!

0

Thanks Sean and Shiraz for your help. I have implemented a workaround that seems to work which is simply having my Authoring environment publish directly to Production. So far I haven't seen anymore errors. Perhaps the double-hop was causing a change somewhere in the process.

Ryan
  • 101
  • 1
  • 1
  • 9