SP2010: Errors in content deployment
This is a topic which comes up more then once when you’re working with the content deployment feature. For those of you unfamiliar with content deployment; it’s basically a process to import and export a site collection in an automated way, across farms if you like to.
But content deployment is a tricky process in which a number of things can go wrong. Most of the solution I’m going to mention are not new, but I could not find a blog which combines them all, so that’s wat I did.
Object already exists
A common problem are errors telling you that stuff already exists on the target site. I found it a best practice to always start with an empty site. When you manually create two sites in seperate farms and then try content deployment, these errors are pretty likely to occur.
When you want to start with an empty site in your target environment, start with an empty site, not one based on the “blank site” template, because that one isn’t empty at all. To start with a truly empty site, navigate to Create Site Collection in Central Administration. For the template, choose custom and then the “<choose template later>” option. Technically, this will create your site collection, but leave the RootWeb empty for later specification. When you open your site in the browser, the first thing it will do is ask you which template you want to use. The point here: don’t choose one! Leave it empty before trying content deployment.
You might read this and think “hmmm, I didn’t do that”. You delete your existing site and try again. Same error? Reason for that is that deleting isn’t actually deleting. When you delete your site from Central Administration, it get’s marked for deletion in the database, but isn’t actually deleted. Reading blogs you’ll find the tip to run the Gradual Site Deletion timer job for your web application, which should delete the site. Well guess what; it doesn’t! That’s because your site remain undeleted for the period of time you’ve set your recycle bin settings to. By default that’s 30 days. After that, the content will be marked for deletion and the timer job will delete your site.
To force deletion, you can use the Remove-SPDeletedSite Powershell command. To find out the ID of the site (which I prefer to the relative URL), you can check the AllSites and AllWebs database tables.
After running the command, execute the timer job again and you’ll notice the rows in the database are really gone.
Feature not found
Ok, so you’ve now got your empty site, but deployment still fails. It complains about missing features.
When you deploy accross multiple farms, you need to check if the same features (mostly in WSP files) have been deployed to all farms. Upon deployment, SharePoint will check if everything needed is available in the target environment and give you errors if that’s not the case.
When you’ve checked that, there’s also the case of application servers and front-end servers. Your farm might have been setup so that the web applications are only deployed to the front-end servers and not the applications servers. Upon deployment of a solution, SharePoint deploys the feature files only to the servers actually running the web applications where the solution is being deployed to. So those feature files might not exist on your application server.
So you should check if you’re running content deployment on a server which has the files needed. Check if the feature listed as missing is present in the FEATURES folder of the SharePoint hyve.
When the content deployment configuration doesn’t list a front-end as an option, it’s likely that your front-ends are not running the “Central Administration” service. Start that service on one of your front-ends and you’ll be able to configure it for content deployment. Or make sure the features are deployed to the application server as well, that’s your choice.
Got any other common issues with content deployment? Put them in the comments!
Leave a Comment