[Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6 - Part 7]
Avoiding common problem
This can be one of the most frequently updated chapters of this article series as "common problems" can change over time. In addition I can only talk about common problems I have seen so far. But let get started.
Problem 1: Mixing deployments with and without retaining object identity
First of all: if possible you should avoid this! Importing with different settings for this property into the same database can lead to serious problems during future deployment and such databases will become hard to maintain.
Be aware that this also means that you should not use STSADM -o import against a database that should be used as the destination of a content deployment job!
STSADM -o import will not retain the object identity while content deployment does.
So why is there a problem when mixing imports with different RetainObjectIdentity settings?
The reason is that with RetainObjectIdentity enabled the imported object will have to be created with the same name and the same guid at the same location in the destination database as it was in the source database. If the item already exists it will be updated. If not it will be created.
Problems occur if there is an item with the same name but a different Guid in the destination database. This can happen if someone has authored on the destination server and created items with the same name but or if he imported content from the source server WITHOUT RetainObjectIdentity setting set to true.
In case that items with the same name but different GUID are allowed for the affected item you will end up with two items with the same name on the destination server. This will be the case (e.g.) for usual ListItems.
In case that items with the same name but different GUID are not allowed for the affected item the import will run into an exception similar to the one below and stop:
Failed to create the 'Pages' library. OriginalException: There can only be one instance of this list type in a web.
Failed to create the 'Pages' library. OriginalException: There can only be one instance of this list type in a web.
=> In order to avoid this problem you have to guarantee that content added to the destination database will not have any name/guid conflicts with the source database - even if new content is added to the source database in the future!
Problem 2: Running multiple imports without retaining object identity for updates of the same content
When doing an export and import without retaining the object identity on the destination server you can end up with duplicate items in lists as each import tries to create the same list item again with a different GUID. The import is not able to decide whether you would like to overwrite an existing item with the same name or if you would like to have multiple list items with the same name. Without retaining the object identity you will end up with multiple list items with potentially the same content. To force overwrite of list items you have to retain the object identity.
That means you cannot use STSADM -o export/import as a replacement for content deployment! If you need to do deploy content to a remote destination server without connectivity you need to write a custom tool that has retain object identity enabled rather than using STSADM -o import based on the code samples provided in Part 3 of this article series.
=> STSADM -o export and import should only be used if the content being imported does not already exist in the destination database and if the database will not be used as the destination database for content deployment (see Problem 1 above).
Problem 3: delete an item from the source site that belonged to the site definition and recreate it
This is a different flavor of the problem discussed as Problem 1.
During provisioning of a site items defined in the site definition template are added to the site. Problems can occur when changes are made to the provisioned items. Especially if the provisioned items are deleted and replaced with items with the same name. That approach will work well on a single server installation. But it will cause problems when using content deployment.
The reason is that during content deployment the site will be provisioned on the destination server using the site definition template. And this will also cause all items defined in this template to be created. When content deployment now tries to import the updated or replaced items there will be a conflict. You will end up with an exception similar to the one in Problem 1.
=> You should never modify or delete one of the items created through the site definition in your site. If the site definition does not suite your needs you should create a custom site definition that fits to your needs and use this instead to avoid the need to customize some of the provisioned items.
Problem 4: deploy from destination back to source
This is something that theoretically can be done but only if the source hasn't changed since it was last deployed to the destination. Otherwise the same issues as in Problem 1 can occur.
Also be aware that it will not be an incremental deployment - means you cannot just deploy the changes since you deployed from source to destination. The reason is that the timestamp information about what to deploy is stored with the deployment job. As this information only exists on the source system the first deployment from destination back to source will deploy everything! So the result would be the same as deploying into an empty site collection on the soruce system. And actually deploying into an empty site collection would be better to avoid problems in case that changes have been done on the source system.
Problem 5: deploy partial content without exporting the parent items
When deploying with retaining the object identity (as you can do with content deployment in the central admin) it is not possible to reparent items. Deployment with retaining the object identity requires that the identity of the object is the same on the destination server and the identity is defined by Id, Name and by the Url.
So the parent of each deployed object has to exist on the destination server in order to successfully import the package on the destination server. We have seen that customers are trying to export a specific subtree of the site without exporting the parents. E.g. only a specific variation label without the variation root.
If the parent of the exported objects does not exist on the importing site then the item cannot be imported and the deployment will fail.
=> Ensure that all parents of all content being exported exists on the destination server. => Or create a custom export tool that does not retain object identity and changes the parent during import as discussed in Part 3 but be aware about the limitations discussed as Problem 2.
Problem 6: deploy partial content with references outside the selected scope
This is similar to Problem 5 except that we assume that the parent objects of the selected object exists in the destination database. In this situation you might assume that no problems should occur. That is not correct. When exporting items in a subtree per default all referenced objects (like images or documents) will be exported as well. Even if these objects are outside the selected scope. In this situation the export package will contain objects which might not have a parent in the destination database.
If the parent of this image or document does not exist on the importing site then the item cannot be imported and the deployment will fail.
=> Ensure that authors do not use resources from other parts of the site collection which is not being exported.=> Or create a custom export tool that uses the ExcludeDependencies to exclude objects outside the selected export scope. See Part 2 for more details.
In my sharepoint solution there are master page, layouts, content types and fields. Some fields are lookup fields. I create them in the feature activation event handler after creating their lists. Generally, the process works on deployment to blank site collection, but it creates my layouts/master pages in content DB, meaning with status "customized". To avoid this, i activate my feature on destination site before deployment, which creates lists and lookup fields in destination site collection. After this the deployment fails with error "The specified name is already in use".
What is the best solution for my scenario?
DO you know if it is possible to import a site that uses Team site in MOSS 2007 into a Team site on WSS 3.0?
We had a test MOSS 2007 setup and our budget does not allow us to use this server. So I was tasked with setting up WSS 3.0 and migrating certain sites from test MOSS into the WSS 3.0 architecture.
I ran export from stsadm.exe command line and it creates 9 files regardless of what file extension I use. Import into WSS 3.0 does not work.
I also tried backup/restore from STSADM, import/export from SharePoint designer.
This last venture I tried I got a SharePoint Services Version error.
Everything I have tried has failed.
Do you know of any resources I could check to help if it is possible?
this should work if your site only uses features which are also available on your WSS site. It will fail as soon as you have used any non WSS features.
I wasn't the owner of the site so I don't know the internal webparts used. I was told it was strictly Team Site.
I'll keep plugging along & see what I can come up with.
As a last resort, I was thinking of trying to re-create the site heirarchy in WSS 3.0 and possibly importing/exporting the content only.
Time cosuming, but may work for my needs.
you are not allowed to activate your features before as this will create items with identical names but different guids.
Unfortunatelly the deployment API unghosts items as you mentioned it. There is no good solution for this beside to manually re-ghost the items after deployment.
I'm happy to announce that development/testing of the next version of the SharePoint Content Deployment
Unfortunately I did not read your article before I fully exported and imported my site using the stsadm -o export/import command. I understand now that his may have caused issues retaining object identity. Now, when I use the content deployment feature to deploy full and incremental updates, I get the following failure message:
Content deployment job 'Full Content Deployment' failed.The exception thrown was 'System.ArgumentException' : 'This constraint cannot be enabled as not all values have corresponding parent values.'
If I delete the site collection from the destination server and run a full content deployment, will I still experience issues with conflicting parent values?
you cannot use this database as destination as this will cause lots of problems. This specific one sounds like one of the problems you can experience. But you will understand that only testing will show if the problem is gone as I don't know your database content.
Are there any releases exlusively in the content deployment API area recently?
the answer is yes. The latest WSS and MOSS hotfixes contain some Post-SP1 content deployment fixes. You can request the latest hotfixes through Microsoft Support Services.
Moving a page interactively is easy using Copy, but in code... ...you have to figure out and match the
So my tool, the SharePoint Content Deployment Wizard has been available for some time now and I've
we would like to move a sitecollection without the content but we always the entire site with all content. Is this a known behaviour?
Does the API (SPDeploymentObjectType.Site) support moving the root web of a sitecollection without any Descendants?
you would need to use SPDeploymentObjectType.Web for this.
thanks for the hint. We followed your suggestion.
Our First try was to add the site object as export object to the export object collection but with the type SPDeploymentObjectType.Web instead of the type SPDeploymentObjectType.Site. That caused the following error during export: “The object with Id xxxxxx that was configured as part of the Export Settings no longer exists.”
So our next try was to add the root web object to the export object collection instead of the site object. This brought the result we were looking for: moving the root web and its lists/libraries without items but we have seen an issue with a library called “Forms”.
Steps we did:
- Create an "empty" destination sitecollection with stsadm
- Export the root web using Objecttype Web (Exclude dependecies=True, Retain GUIDs, IncludeDescendants=None)
- Import the cmp of the root web (successfull)
- Export all list and libraries without descendants
- Import the cmp with all lists/libraries (not successfull). Result was an Error Message: "The specified name is already in use.”
We figured out that after the first import the Forms Library was created at the destination site collection. We assume that this is related to the MS Enterprise Feature which has been activated during the first import (as expected because the source site collection has it activated too). The second import contains the Forms Template library of the source site collection which has a different GUID than the one created at the destination site collection. We guess that causes the error.
Are we right with our assumption? If yes what would be the best way to address this?
Some other questions related to this:
- Which content related directly to the site collection won’t be replicated when using the root web object instead of the site object as export object? And if there is a difference, is there a way to replicate this delta without descendants of the site collection by using the PRIME API?
- We have an issue when adding several lists/libraries with different IncludeDescendants settings to the export object collection. By only adding one list with IncludeDescendants=All the PRIME API also deployed the items of added lists with IncludeDescendants=None. When we only add lists with IncludeDescendants=None it works and no list items are deployed. Is this a known behaviour? Is there a way to get mixed collections work?