MOSS – Common Issue – Incremental deployment fails with "The changeToken refers to a time before the start of the current change log."

I have seens this problem a couple of times in the past: sometimes when running incremental content deployment the deployment job fails with the following error message

The changeToken refers to a time before the start of the current change log.

To make a long story short: to resolve the problem you should do a full deployment into an empty database. It is not recommended to run full deployment into the previously used database as the full deployment will not perform delete operations of items that have been deleted in the source database but still exist in the destination database. It will also not reliably work if items have been moved on the source database to other places after the last successful incremental deployment has been used.

Why does this problem occur? This can happen mainly for three different reasons:

A) The timespan since the last incremental deployment job is too long

MOSS stores the change token of the last successful incremental deployment inside the properties of the incremental content deployment job. When a new incremental deployment is run it compares the change token in theses settings with the entries in the change log.

Per default the change log is configured to keep changes for 15 days. If the timespan between two incremental deployment job exceeds this timespan then the change log does not contain entries from before the change token and incremental deployment will not start to prevent deploying only parts of the required content.

A solution for this would be to increase the timespan the change log should be preserved. This can done using the following steps:

Central Administration - Application Management - Web Application General Settings - (choose the desired website) - Change Log

B) The source database has been overwritten with a backup

When a database is restored through STSADM -o restore or using SQL backup and STSADM -o addcontentdb the change log is cleared.

Incremental deployment will not work in this case and you have to do a full deployment to synchronize the content with the destination database.

C) No changes have happend on the source server for a long time

As mentioned in A) the change log will be used to determine the items that need to be deployed. Per default changes are preserved for 15 days in the change log. So if no changes have been done for 15 days the change log will become empty.

Two possible solutions exist: 

  1. Increase the timespan the change log should be preserved. This can done using the following steps:
    Central Administration - Application Management - Web Application General Settings - (choose the desired website) - Change Log

  2. Ensure that at least one item is modified within the configured timespan

D) The source database has been merged with a different site collection

After merging two content databases using stsadm -o mergecontentdbs the EventCache table will be empty. This is similar to problem B) listed above.

Incremental deployment will not work in this case and you have to do a full deployment to synchronize the content with the destination database.

Comments (20)

  1. Maha Elkoshairi says:


    We are facing the same problem, but neither of the above conditions apply. We were running an incremental deployment on a daily basis, with some sections, such as the main page, on an hourly publishing schedule. Suddenly the jobs began generating the above message. We tried full deployment of all site branches, and then ran an incremental job to no avail.

    Is there no other way than publshing to an empty database? There is usually some down time involved and this is something I want to avoid.

  2. Hi Maha,

    if you can live with the fact that delete actions performed on the source server will not be applied to the destination you can also just recreate the incremental deployment job. It will then perform a full deployment on first run and incremental afterwards.

    As mentioned: delete actions you have done on the source server which have not yet been deployed to the destination will not be done then.



  3. Maha Elkoshairi says:

    Thanks Stefan, we did try what you suggested but in the end had to resort to recreating an application and publishing to it. One other thing that puzzles me though, alhtough the scheduled jobs run at the correct local time (we have correctly set the regional settings on our application), they are actually recorded as having occured 9 hours earlier! So for example, in the Manage deployment jobs screen, the column that shows when the job was last run is always 9 hours behind, although it ran at the correctly set time. Is there anyway to correct this? Could it have had something to do with the problem we experienced? We are in Cairo by the way, at +2GMT, which is the time set in our regional settings.

    Thanks for any info!


  4. Hi Maha,

    please open a support case with Microsoft to get the time zone problem analyzed.



  5. Anonymous says:

    [ Part 1 – Part 2 – Part 3 – Part 4 – Part 5 – Part 6 ] Requirements for a successful content deployment

  6. Sylvain says:

    We just ran into this problem and want to change the settings of 15 days.

    If 15 days was set by default by MS there was probably a good reason for it. So what would be the impact (on deployment) of changing the settings for a longer period (30 days)? And does it need to be set to the same value at both source and destination ?


  7. There is no specific reason for the 15 days. If you increase this value the number of items in the EventCache table will increase. So more database space will be required.



  8. For incremental deployment only the Change Log on the source server is relevant. So you only need to increase it here.

  9. Anonymous says:

    A common error I often see is that customers are mixing incremental and full deployment when deploying

  10. Anonymous says:

    In the past I have released several blogs about the various problems that can occur with Content Deployment.

  11. Anonymous says:

    Una de las razones mas comunes por las cuales da este error se debe ha que esta desactualizado el “Token

  12. Chris Mc says:

    Just came up with another way this error could be caused (what made me find this blog today in the first place.)

    We have 3 jobs deploy the same publishing template website to 3 destination farms. an internal farm for testing, a production farm and an HA farm.

    I had the error today because our content manager had deployed last week to the 2 production site farms and neglected to deploy to the Dev farm. So when I went to deploy today and tested deployment to the Dev farm the test failed with this message. But tests to both of the production farms succeeded.

    After changing the dev farm incremental job to Full and deploying the site, I was again able to do incremental deployments to all 3 farms.

  13. Hi Chris,

    this is actually a flavor of A)



  14. Ernst Joss says:

    Hi Stefan

    We have the problem stated in C) for several SiteCollection inside one webapplication, as these are some small satellite sites with no big changes. The main SiteCollection is changed every day and so there is no problem occurring for this one.

    Can you say what will happen if I just say to never purge the change log for this webapplication:

    – Will it grow endless?

    – Is there a critical value for performance reason that should not be gone beyond?

  15. Hi Ernst,

    yes it will grow endless.

    For sure it is not good to have an endless change log but I don’t have any numbers about performance impact.



  16. Greg Lambert says:

    Hi Stefan,

    We deploy from the Authoring MOSS 2007 box to the Production MOSS 2007 box. If the Production box fails and we restore the Production Box from a 30 day old backup, will the Incremental Content Deployment still function normally, as long as we are within the time limit of the Change Log?

    Or will we need to delete the old site collection, create an empty site collection, and then perform a full deployment.

    Thank you,


  17. Hi Greg,

    not if you have done a previous import into this site collection after the backup was taken.

    The source system does not know that the target has been restored – so it will not redeploy the items missing in the restore.



  18. shardul says:

    hello, I am having site with many variation. for some variation we have created the incremental job which we have scheduled daily. Also we are modifying content regulary. still after change log period, all jobs got failed saying 'change token error'. what may be reason for this?  

    Any help is appreaciated.

Skip to main content