Content Deployment Issues

Question

We have been experiencing time out issue with content deployment after the Daylight Time changes on our servers and I wonder if any one has had the same problems.

The scheduled jobs export and on the import phase they get timed out.

Thanks

Answer 1

We have run into the same issue since the W2k3 server DST patch.  When starting a content deployment job, the job hangs in the preparing state.  An hour later, the job either times out, or gives us an error message of

	3/15/2007 11:10 AM	The changeToken refers to a time before the start of the current change log.
	3/15/2007 11:10 AM	The changeToken refers to a time before the start of the current change log. at Microsoft.SharePoint.Deployment.SPExport.ThrowInvalidChangeTokenError(DateTime minChangeTime, Int32 minChangeNumber) at Microsoft.SharePoint.Deployment.SPExport.GetIncrementalChanges() at Microsoft.SharePoint.Deployment.SPExport.CalculateObjectsToExport() at Microsoft.SharePoint.Deployment.SPExport.Run()
	3/15/2007 11:10 AM	Content deployment job 'Deploy Report Site' failed.The exception thrown was 'Microsoft.SharePoint.SPException' : 'The changeToken refers to a time before the start of the current change log.'

If anyone has any idea or has a resolution, can you please respond.

 

Thanks,

Dan

Answer 2

I am having this issue as well on multiple servers.  I removed the DST patch on my test server and it fixed the problem.  I re-applied the patch and it seems to be broken again.

Anyone out there know anything about this?

Rabbit

Answer 3

Found this from Microsoft KB:

http://support.microsoft.com/kb/932563/en-us

Answer 4

We were abl to resolve this by changing the server time to a non DTS zone, rebooting and then changing the server time back to the DTS time zone.

The only problem with this is that owstimer will go back to the earlier state (state after DTS install) is you reboot the server(s).

If you ever reboot your server, you have to repeat the work around.

 

Thanks

Answer 5

That worked!  Thanks for the tip Gatharia.

Does anyone have any idea if MS is working on an official fix for this -OR- will this issue go away once we roll past the old DST date which is coming up soon?

Rabbit

Answer 6

According to Microsoft the DST issue will not show after the old DTS times but in octomber expect that to come back if Micrsosoft has no OS patch. The crazy thing is that owstimer seems to have it's own clock other than the system clock. We had to enable verbose logging in sharepoint and read all logs to see what is happening. ( I heard that this time issue was a bug in windows 2000 but it is the same in windows 2003 too)

Answer 7

I was wondering about that myself.  It seems like the owstimer service doesn't get its time from the system clock.  Very strange.  It also looks like the fix you suggested worked yesterday but for some reason (and the server wasn't rebooted) Content Deployment is back to being broken again!

All this trouble because of stupid daylight saving time!!!

R

Answer 8

One more thing about the workaround is that this should be done on source and destination servers. If that is not so the export phase will work but the deployment will fail during the import phase. Also, if with of the serves is rebooted, deployments will still fail because owstimer will be out of phase again.

Answer 9

Ok, it looks like everyone else stopped having this issue when DLT came.  But I just started having it.  Im in Arizona so we dont do DLT savings, but since it started now all my jobs are getting this error.  Any ideas? 

Answer 10

I have same issues... strangest thing is that I ran content deployment to production farm when it was on testing (15 days ago), but after its relocation to production site I constantly receive "Time Out" error

Answer 11

I'am experiencing exactly the same problems on our MOSS2007 environment. We have already installed SP1 for wss and moss but nonetheless the problem still exists.

 

After we deployed a full content job (which succeded) we configured an incremental job. This job scheduld for once a week doesn't work and gives the same error as mentioned.

 

 

Answer 12

Having the same issues since Dec 11. I had a sucessful deploy from DEV farm to PROD farm on Nov 8. Next time I tried to deploy was Dec 11. Now there was a patch that came out 942763. I thought removing it would help. but it did not. Have been on and off the phone with MS since then and no solution. If anyone gets a fix feel free to post!

 

Answer 13

 

Well finally I managed to do a full and incremental content Job. I do not now exactly what did the trick but it somehow seemed that SP1 for wss 3.0 and SP1 Moss 2007 weren't finished installing. I did the following.

 

I rebooted our Production server

deleted the webapp for the website

Created a new webapp

Deployed the Site feature packedge

Created a new SiteCollection with the blank template

Performed a Full content Push from staging to live

Succesfull with warnings

Performed an incremental job

Failed Cause: The website on production wasn't checked out. Actually all content should first be published on staging before it can be pushed to live.

Performed a new incremental job

Failed again Cause: "FatalError: Member 'Versions' was not found.". It seemes that this last error is fixed by SP1, which in my opinion was already installed?!!!

 

I hadn't rebooted my Staging environment yet so I did.

Planned a new incremental job and drove off to a meeting. Once there I got a relieving message from the Staging server which stated that the incremental job was succesfull!

 

Now I still have some minor issues (Masterpage is different than staging? have to change it manually)..

 

I can only conclude that the Service Pack upgrade which I performed several weeks ago wasn't finished and that one final reboot was necessary for both servers. I remember getting several errors, before I restarted both servers, which all had hotfixes for it but they were all replaced by SP1 (wss and moss) and that I found it strange the errors still did occure?

 

Hope this helps other people on their way.

 

So far a happy Content Pusher .

Answer 14

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

Does anyone have a solution or can provide any assistance with this one?

I have contacted Microsoft twice about this but they simply have not replied to me.

I have an MSDN subscription, so I suppose I will have to raise a support request for this, however at this point in time I just want to get my incremental deployment working as it is very urgent.

Any help or advice would be much appreciated.

FYI. I am not in a daylight saving time zone, so I'm not sure how this has even occurred in the first place.

Last time this happened, I had to delete the target site collection and recreate and redeploy fresh - as this was the only way that I could get that working.

However, this is NOT an option this time as the target environment has heaps of content created in it, so I can't recreate the target environment any longer...

Thanks,

Tod.

Answer 15

I had same problems in my deployment from dev to production farm. In my case, I have deployment job that deploys functionalities and subsites to very important  web portal.  I run that job as needed. I encountered that when I don't run this job for more than 15 days, it then fails every time with abovementioned error "The changeToken refers to a time before the start of the current change log."
So, my workaround is that I modified job settings so that it will take "all content, including content that has been deployed before". Of course, I choose specified subsite to deploy, but all lists and libraries that are on root site were filled with old content, and new items created on production site (not deployed from dev) were abandoned, i.e. deleted. That worked in my case, but with this drawback.
I cannot guarantee this could help you, but you can try to create small subsite with one page on your dev and to deploy it to prod, just to "wake up" jour deployment job. Again, if you choose to deploy "all content" (i think it is lower radio button from the two on the bottom of job settings page) your content on production farm root site / will be replaced with content from dev.

HTH
Dragan

Answer 16

Hi Dragan,

 

You are indeed 100% correct.

 

The last time I did a deployment was the Nov 27th 2007.

 

It seems from my investigation that the Content Deployment is inexplicably tied to the 15 days rule.

 

I verified this using the following code:

 

Code Snippet

using System;

using System.Collections.Generic;

using System.Text;

 

using Microsoft.SharePoint;

 

namespace ConsoleApplication1

{

class Program

{

static void Main(string[] args)

{

SPSite site = new SPSite(http://localhost:80/foo);

SPChangeCollection collection = site.GetChanges();

SPChangeToken token = collection.LastChangeToken;

 

foreach (SPChange change in collection)

{

Console.WriteLine(change.ChangeType + " " + change.Time);

}

}

}

}

 

 

Which produced 778 lines of changes:

 

Code Snippet

Add 30/01/2008 1:18:49 AM
Rename 30/01/2008 1:19:04 AM
Delete 30/01/2008 1:20:00 AM
Rename 30/01/2008 1:20:03 AM
Add 30/01/2008 1:27:11 AM

...

Update 13/02/2008 2:00:19 AM
Update 13/02/2008 2:00:19 AM
Update 13/02/2008 2:00:27 AM
Update 13/02/2008 2:00:28 AM
Update 13/02/2008 2:00:28 AM

 

Which is 15 days worth.

 

[I note that the dates and times are completely wrong - however I think I must have a time zone setting wrong in SharePoint somewhere - however, I don't know where that is at the moment - it will be my next task to look into].

 

OK - So now I look at SPChangeCollection and see that it has a fix maximum value of 1000 results.

 

http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.spchangecollection.countlimit.aspx

 

I have 778, so I'm OK there.

 

Next I go into the guts of the SQL Server DBs - I want to work out here if the rest of the change history is there (and it's just the API that is ignoring it, or something else).

 

So I find this:

 

http://msdn2.microsoft.com/en-us/library/ms998692.aspx

 

And then I do the following to verify we really are looking at the same results:

 

SELECT     COUNT(*) AS Expr1
FROM         EventCache

 

RESULT 778

 

OK - So I know that we have the right table and my data matches up...

 

Hrmmm... So I find this...

 

http://msdn2.microsoft.com/en-us/library/bb861918.aspx

 

"By default, the change log retains 15 days worth of data. You can configure this in SharePoint using the Web Application General Settings page located on the Central Administration page.. A timer job runs daily to delete all expired change log entries."

 

Which I find is configured here:

 

Central Administration -> Application Management -> Web Application General Settings

 

You can see by looking there that the default 'Change Log' settings are that it is set to delete entries after 15 days.

 

So basically my supposition here is that the incremental publish is based upon the Change Log - and thus when you create a incremental publish job you need to make sure you publish schedule is more frequently than your setting on this screen or otherwise (as is in my case) the SharePoint timer job will eventually delete the logs for the period at which you did your last publish and then you will see the 'changeToken' error.

 

And at that point, your screwed and you can't ever do an incremental publish of that site - ever again... (which is what has happened in my case).

 

So now I have the problem - What do I do now???

 

I need to get all the changes I have made over into the publishing target server...! But the target server has had heaps of content added to it - and if I do a full publish now, it will probably break/remove all that content which is UNACCEPTABLE...

 

So now I'm at your mercy MSDNers... Any further help would be much appreciated

 

Cheers!

 

Tod Thomson.

Answer 17

Well you guys must have reading my thoughts. I was going over this yesterday and came with the same conclusions, and then I receive the replies on this thread, and see others have the same results.

 

One thing I have learned as well is that the GUI Content deployment feature really is an Export of data from the source and Import of data to the destination just like the command line tool STSADM.exe. ( I am sure you already know).  But if you run Export/Import via STSADM from the CMD line, it does not seem to rely on the Change Log table from the Config DB. It is more of a direct process of doing what you tell it. And there are switches to specify what to export and then what to import.

 

First we ran the export with defaults from the source farm:

• e.g -- stsadm.exe -o export -url "http://servername\sitename" -filename x:\exports\sitename\site.cmp
• We actually exported each site separately, to a separate site folder for organization.
• Now by default no security is exported, and for files and libraries only the last major version is exported. we weremore concerned about the design and webparts on DEV.
• The switch "-versions" with a value 1-4 can help with this if you need ot use.
• Run "STSADM -help export" from a cmd line to see the switches.

Next we ran the Import on the destination farm:

• Copied the export files to a folder on the destination server
• ran the import from the cmd
  • stsadm -o import -url "http://servername\sitename" -filename x:\imports\site\site.cmp -updateversions 3
  • Note: the url is your destination url
  • "-updateversion 3" is ignore the file if it exists on the destination
  • stswadm -help import for switches and explanations
• ran iisreset /noforce on the server
• tested sites.

Here are some things to watch for:

• The source and destination site templates must be the same or the import will fail
• the ID being used must have the correct access to the DB server.
  • Must be able to read/write from source and destination
  • We used the Farm admin ID when doing this.
• BE CAREFULL of your switches
• TEST TEST TEST TEST first.

Now sems like a pain if you have several sites, well yes it is. But it does work, at least for us and our situation.

 

Good Luck

 

Dave

 

 

Answer 18

Hi Dave,

 

Thanks for the info - it seems like that could be another option for me.

 

I have some further information.

 

I created some content in the target environment and did a full deployment of my changes (instead of incremental) and it seems to deploy the changes OK, without deleting the content in the target environment.

 

So cross fingers that I can do the same process from TEST -> PROD and I won't loose all my user created data in PROD (which is the whole point).

 

Clearly, I will full back up of PROD before I do anything.

 

I'll let you know how it all goes - in a nut shell, if you lose your logs (after say the default 15 days) just change your deployment job to "all content" and run again... you may find you end up OK.

 

Tod.

Answer 19

 

Changing the setting of the Job to in Central Administration->Operation->Content Deployent Paths and jobs ..

Check --- 'Deploy all content, including content that has been deployed before'

after that the job runs successfully

Answer 20

Tod,
what happened with content that has been deployed and then changed on destination site... is that replaced with old content on second "all content" deployment?
what happened on pages created inside deployed sites only on destination? is that deleted after second "all content" deployment?

Answer 21

Hi Dragan,

I can't answer those questions (yet) as I haven't done it (yet).

I'll let you know once I do it...

Bare in mind that my LOCAL DEV -> DEV -> TEST environments don't have any content in them, they are just "schema" type information (i.e. lists, site columns, content types, security groups), all content creation is on PROD only.

i.e. we are trying to use the publishing infrastructure to get a DEV -> TEST -> PROD (style) staged deployment systems architecture... I don't recommend it.

T.

Answer 22

> what happened with content that has been deployed and then changed on destination site... is that replaced with old content on second "all content" deployment?

Yes, I believe it will be... This is especially true for things that map to ASP.NET content (e.g. views).

This has the extended effect of leaving deleted views on the destination site. Which can become a pain...

> what happened on pages created inside deployed sites only on destination? is that deleted after second "all content" deployment?

I don't belive so. From my testing it just adds/updates but there are no deletes (deletes can only work with the diff deployment).

Anyone else having more information about the issues around these kinds of deployments, please let me know.

Answer 23

Nothing is deleted (if it was not pushed via Content deployment).

Also remember Content deployment is all based on Guid ( Page URL + List Guid + ID)

If same URL + ListGuid + ID are present they will be Sync.

(i.e If modified on source , they will be modified on target)

deleted on source , will be deleted on target.

(New item added on source , it will be added on destination)

 

But if Page URL + List Guid + ID don't match , you will get error in content deployment.

(This is the reason ,content deployment fails , if destination is not blank site, first time)

 

So answer to question, If you create anything new on destination (just make sure whatever  item you create will always a URL which doesn't exist on source server, if that ever happens (may be future) at that time content deployment will fail.

 

(e.g you can create a subsite on destination and if that is not source, you can use that subsite safely on destination without worrying about Content deployment making changes to this subsite, Just don't ever create subsite with same name on source. (if you do, it will get different Guid, and you will get error on Content deployment).

 

I hope it makes sense.

[These are my thoughts , not Microsoft offical position] 

Answer 24

I find it interesting that this post has not been updated in a year.  Hopefully you all found your solution.

I have some of these exact same problems and then some.  We use Windows Server 2008 and SharePoint 2007 and I still have these problems, so don't get your hopes up that a server upgrade, or that SP2 for MOSS will fix the problem.  Apparently this is still a problem after two years.

In our production environment we have a parent company in Europe that pushes the top level site, navigation, a few subsites, and security information to other sites across the world.
Here is what I have found:

1.  Content deployment in on the source server will time out after 10 minutes with no response.  There is no ability to adjust this time out period in the interface.  Full and Incremental content deployment often time out.  In one case our destination takes about 12 minutes to process an incremental update and the other site takes about 25 minutes.  The reports on the destination end up saying successful, but since it was not within the 10 minutes during which the source was polling, the status on source ends up in ‘Timed Out’.  MS, if you are listening then it would be nice if a user could adjust the time-out through the interface for incremental and full content deployment jobs separately.  We have four farms that we deploy content to, of which two time out and two are successful.  Even the incremental content deployments at the successful locations take 6-9 minutes to run the import.  The packaging of the cab file, the transfer, and the unpackaging of the cab file all take about two minutes.  The rest of the time is waiting for the import to run.  Our incremental import is only about a half a MB, so I don't understand why it takes 10-30 minutes to process an import.

2.  After a certain period of time incremental crawls do not work anymore, even if a full content deployment has ran.  A full content deployment will run but the incremental will still fail saying that the changeToken refers to a time before the start of the current change log.  I would expect these times to re-synch if I run a full content deployment.  We prefer to run incremental because of the problem in #3.  Also, fixing this issue by deleting the site at the destination and then running a full content deployment is not an option for us because a lot of sub-sites exist at the destination that do not exist at the source.  I see an stsadm command mentioned above that I will try but I still wish the interface would have some settings to get around this.

	5/8/2009 5:27 PM	The changeToken refers to a time before the start of the current change log.	/
	5/8/2009 5:27 PM	The changeToken refers to a time before the start of the current change log. at Microsoft.SharePoint.Deployment.SPExport.ThrowInvalidChangeTokenError(DateTime minChangeTime, Int32 minChangeNumber) at Microsoft.SharePoint.Deployment.SPExport.GetIncrementalChanges() at Microsoft.SharePoint.Deployment.SPExport.CalculateObjectsToExport() at Microsoft.SharePoint.Deployment.SPExport.Run()
	5/8/2009 5:27 PM	Content deployment job 'Job for Push to Kuching' failed.The exception thrown was 'Microsoft.SharePoint.SPException' : 'The changeToken refers to a time before the start of the current change log.'

3.   If a full content deployment runs, or if any change happens to the navigation, then any site that was hidden in the top navigation gets un-hidden (destination side).  We chose to go with incremental updates in our content deployment because of this problem, but now we have one site that cannot get incremental updates because of issue #2.  Even then, anytime the navigation changes we still have to re-hide sites and this is really annoying.  It would be nice if the navigation could be updated while still respecting the hidden sites on the destination.

4.  The reports on the destination do not show the correct start and end time.  Even if the regional settings are set with the correct time zone then the start and end times will not have the correct time.  It appears to be GMT in the start and end time.  The date created and the date modified on the job is correct though.  Maybe this is by design, but it makes people wonder if the start time being off by several hours is preventing the destination from processing the import portion of the job at the right time.  I no longer think that is the case, but I did at first.

I have opened a case with MS.  I'll post again if I ever get a solution from them.

Thanks,
-Eric

Answer 25

Hi Eric,

We recently published a troubleshooting article on TechNet that addresses your first two problems. See http://technet.microsoft.com/en-us/library/dd795107.aspx, specifically the sections on "Timeouts during content deployment," and "Error: The changeToken refers to a time before the start of the current change log." I would also recommend you read Stefan Goßner's blog post about content deployment best practices in which he discusses the problem with mixing full and incremental deployments (http://blogs.technet.com/stefan_gossner/pages/content-deployment-best-practices.aspx).

Hope this helps.
-Cern McAtee

Technical Writer, IT Pro
Microsoft Office SharePoint Server

Answer 26

Stefans article rocks I havent had the opportunity to review the technet article yet but I will now. Also, there is a tool that helps resolve the descendent issues The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 http://spdeploymentwizard.codeplex.com/ check it out it works and if you havent read Stefans Blog on Content Deployment usiing stsadm -o export/import its a must read....


-Ivan

---

Ivan Sanders http://linkedin.com/in/iasanders http://dimension-si.com/blog