Question

The business had a wish to copy content from production to acceptation (publishing environment). So I created a content deployment job to do so, and ran it.

It failed with the following error:

Content deployment job 'PROD -> ACC' failed.The exception thrown was 'Microsoft.SharePoint.SPException' : 'Feature '32e8942e-f6d6-48ec-ab6a-a75bedd2816d' for list template '10000' is not installed in this farm. The operation could not be completed.'

The feature ID points to a custom feature which is in fact installed in both environments, exactly the same WSP. One thing to note is that on the server which hosts central administration, there are no webapplications deployed. Because of that, the web scoped features are also omitted on that server and thus not present. Because of that, I enabled the Central Administration service on one of the front-ends and edited the content deployment settings to use that server instead of the central admin one. Didn't fix it.

When I test the job, it tests OK, so it's really the import causing problems.

So now the question is; should this work at all? Or do I need to get the web applications on the central admin server so the features are present there as well? Sounds a bit odd.

Was it helpful?

Solution

The solution was more simple then I could imagine. On our application servers, the web roles have been turned off. So in IIS, the SharePoint web apps do not exist. Apparently, SharePoint also omits deployment of WSP files to servers on which those roles are not present. But the content deployment needs those files to read the feature definitions and stuff like that.

So to solve this, there are two options: 1) Start the Central Administration service on one of the front-ends. Now configure the content deployment engine to use the service on this machine (where the XML files are present). 2) Enable the web application service on one of the application servers. Configure the content deployment engine to use this server for jobs.

The result of both is the same; the content deployment jobs should be handled by a server on which the feature files are present.

OTHER TIPS

Content deployment can easily go wrong if all required "prerequesites" are not present. Here are a few running through my head :

  • Make sure the target environment is clean and has the same WSP deployed than the source environment
  • Make sure that you start on the target environment with a fresh content database (if it failed, chance are high that you'll have leftovers in your target content database that might bring issue with additional or re-create content deployment)
  • Make sure that your target site collection is empty (aka "pick template later")
  • Make sure that your code is content deployment aware (eg : do no create in receiver items in your list because these items will be copied by the content deployment and you'll have at best in that case duplicates entries)
  • Make sure that the content deployment is working "locally". You can set up a content deployment on a farm to deploy to itself (obviously to another web application / site collection).

But back to your question, do you have a working WFE in your target environment ? You need central administration on both farms because the content deployment is talking to their web services to do the operation but you'll also need at least one server with the web application role activated on it (can be the APP server hosting the central admin)

You could also do a stsadm -o export on the source environment and a stsadm -o import (or the similar command in PowerShell) on the target environment, the content deployment job is nearly doing this so that would help you to troubleshoot your issue.

Finally, make sure that your farms (both source and target) are as patched as possible (october 2012 CU ?), I've raised a few tickets to Microsoft (some of them being present in some CU).

Good luck, let us know how stuff are evolving.

Licensed under: CC-BY-SA with attribution
Not affiliated with sharepoint.stackexchange
scroll top