Common Problem with Content Deployment: mixing incremental and full deployment

A common error I often see is that customers are mixing incremental and full deployment when deploying a site collection. E.g. use incremental deployment every day and full deployment once a week – just to be sure (maybe because they do not trust incremental?)

The problem is that incremental and full deployment do not deploy the same type of content. So the data on source and destination might no longer be the same.

Why can this happen? The reason is that only incremental deployment exports deleted items which is required to ensure that the items also get deleted on the target server.

Consider the following scenario:

  1. Site A has been created
  2. Site A gets deployed to the target server
  3. Site A is deleted
  4. a full deployment is done
  5. further actions
  6. an incremental deployment is done

With step 4 the deleted site will not be exported. The incremental deployment in step 6 will only deploy changes done between step 4 and 6. That means that after step 6 site A still exists on the target server!

You might not even notice this if you are not actively monitoring if the content on source and on target is in sync. Only if content with the same name gets recreated later you will notice it as you will get errors similar to the following:

  • “The Web site address “/A” is already in use.” or
  • “The specified name is already in use. A document cannot have the same name as another document or folder in this document library or folder.”

That affects all type of objects (e.g. sites, pages, lists).

To ensure that the target and the source site collection are in sync it is mandatory to use full deployment only once: when doing the initial deployment from source to target. Afterwards you should only use incremental deployment and not add additional full deployment steps. That also means you should avoid situations where content deployment fails to do an incremental due to the fact that the timespan between incremental deployments exceeds the configured retention of the change log (see here for detail).

On the other hand that also means: whenever you see a need to do a full deployment you should do this full deployment into an empty site collection rather than the earlier created site collection that already received content from earlier deployments.

12 Comments


  1. Top News Stories Office 2007 Faces Competition Where it May Count the Most: Pricing (InfoWorld) I was

    Reply

  2. stefan thanks for providing this knowledge. But only using incremental deplyment is not realistic.  There are numerous issues that occur with an incremental deployment that can only be fixed with a full deployment. Couldnt this problem be avoided by preceeding a full deployment right before a full deployment. That way one can avoid the synching issue.

    Reply

  3. Hi Carlos,

    I assume you mean an incremental right before a full, right?

    The issue is: if incremental succeeded you have all the content in the db and a full will not change anything.

    In case that incremental failed you will have exactly the situation listed above which needs to be avoided.

    In addition: it would only "work" in case that no updates have happend between incremental and full deployment.

    But as outlined before: if incremental succeeded and no updates have happend – why shoudl you do another full deployment as the content is already update to date?

    So if you have a problem with incremental you should fix this issue rather than doing a full deployment to hide the issue.

    Cheers,

    Stefan

    Reply

  4. Hey Stefan,

    Sorry, yes I did mean an incremental before a full.  And your right the scenario I posed still causes the problem you described above.  

    So are you suggesting that if an incremental deployment fails, and cant be resolved, that the best course of action should be to clear the site collection (deleting the db) and perform another full deployment?

    Reply

  5. Hi Carlos,

    before using the full again you should try to analyze why the incremental failed. If it (e.g.) failed on export it could be a concurrancy issue (e.g. an authoring action interacting with export). Here you should just try the incremental again. Usually it succeeds now.

    If it is on import you could try a retry as well although the chances that it works now is smaller.

    Only if you cannot resolve the issue and don’t have the time to open a support case with Microsoft to analyze why the incremental fails you would have to go the step with a new empty target site collection and the downtime that means to your system.

    Cheers,

    Stefan

    Reply

  6. I think the best solution is to try to avoid using content deployment altogether. Avoid having an "authoring" server.

    We have been struggling with our site for almost a year now, and CD is still extremely broken. Incremental deployments fail at least once a day, and occasionally (approx once a month) fail so consistently that we are left with no option but to do a full deployment to get the content across. This, of course, can cause even more problems down the track. The end result? As Stefan mentioned, you occasionally have to blow away the entire site collection and do a full deployment into that. Not a great option for an Internet site like ours…

    We won’t be using MOSS content deployment on our next Internet site. It’s just not worth the trouble.

    Reply

  7. Hi Stefan,

    I understand your original post very well; it’s something that should be stamped on the MOSS box, out of which all the OOTB CD functionality arises. But even after several readings there’s still 1 point that seems clearly inconsistent:

    "To ensure that the target and the source site collection are in sync it is mandatory to use full deployment only once…etc" and thereafter only use incremental deployment.

    Yet:

    "that also means: whenever you see a need to do a full deployment you should do this full deployment into an empty site collection …etc".

    Why would subssequent full deployment be ‘needed’ at all?

    More to the point: Why does OOTB CD at all allow full content deployment into a non-empty site collection to create the error in the first place?

    Reply

  8. Hi John,

    you are right: it should not be necessary.

    But due to the complexity of content deployment it can happen that an incremental deployment fails while a full deployment works.

    Some customers use this to resolve such issues.

    Why the implemented method allows to do this and does not restrict this is more a philosophical question…

    Cheers,

    Stefan

    Reply

  9. Hi again Stefan,

    Many thanks for the reply above. These posts here, and not least your consolidated CD best practice, are invaluable.

    I have a follow-up on the above regarding incremental deployment at the site collection level:

    Would an incremental CD at the root site collection level include the addition of a new site (and its contents) to the site collection?

    To me the answer would have been a foregone conclusion: ‘yes’. But perhaps not it seems.

    many thanks

    Reply

  10. Hi John,

    if you did not explicitly restrict the sites that get deployed then it will deploy all the new subsites as well.

    Cheers,

    Stefan

    Reply

  11. I have more than 50 sites in site collection. there is incremental job for each site. If any incremental job fails due to change log period expired. how again run that job.

    Plese help me.

    Reply

  12. Hi Shardul,

    when the problem occurs there is only one way to recover: delete the target site collection, create a new empty one and do a full deployment. Afterwards incremental will work again.

    Cheers,

    Stefan

    Reply

Leave a Reply to Stefan Goßner Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.