SharePoint 2007 and DST Change

Wednesday, 12 March 2008 13:29 by RanjanBanerji

So we all experienced the DST change this past weekend.  Though the government has made DST last longer the basic concept remains the same.  One day in spring the time jumps forward by an hour and then one day in fall it jumps back an hour.  Computer systems have been handling this event for decades.  Even systems that were built ages ago that could not handle the Y2K issue could handle the DST change.

Ah! but not anymore.  SharePoint 2007 has some really cool built-in features (please note the sarcasm).  When the DST change occurs SharePoint is completely clueless of what happened.  We had a few content deployment jobs scheduled to run every minutes.  These jobs took an average of about 5 minutes to run.  After this weekend these jobs started taking an average of about 1 hour and 5 minutes to run.  It was too much of a coincidence for all jobs to start taking an extra hour just after the DST change.

After some analysis I figured I might as well restart the Windows SharePoint Timer Service.  Well that fixed the problem.  Well not really.  What will happen this fall when the DST time switches back?  So I was convinced I made a mistake in building our servers.  I must have missed some patch or hotfix.  Nope, that was not the case.  I came across Microsoft's knowledge base article 938663 which then convinced me that what I was observing is a feature not a bug :-).  The article says:

"The Windows SharePoint Timer service does not update its internal time when Microsoft Windows makes the transition from standard time to DST or from DST to standard time. Therefore, after you apply this hotfix, you must restart the Windows SharePoint Timer service after each transition from standard time to DST and after each transition from DST to standard time. If you do not restart the Windows SharePoint Timer service, timer jobs that you schedule may be delayed. Or, they may fail."

So, let me get this right.  You apply a hotfix then twice a year you go to each SharePoint server and restart it's timer service.  Absolutely amazing.  Obviously a better solution would be to write a script or service to do this for you if you are running multiple large farms.  One more reason some people call SharePoint a development platform ;-)

Tags:   ,
Categories:   SharePoint
Actions:   E-mail | Permalink | Comments (8) | Comment RSSRSS comment feed

SharePoint Content Deployment - Target Database Grows too Large

Wednesday, 5 March 2008 00:11 by RanjanBanerji

In my previous post I talked about setting up content deployment jobs in such a manner so that if you had to aggregate some jobs you would not trigger a full deployment.  You may ask why is a full deployment a problem?  Well I see two problems right away:

  1. If you created smaller jobs to avoid a single large job, then after aggregating your smaller jobs you trigger a full deployment, you just lost your attempt to avoid a large content deployment job.
  2. When a full deployment occurs the destination database grows to be larger than the source.

Say what?  What was that point number 2?  The destination database grows larger than the source?  How can that be?  Shouldn't the destination be the same size or smaller than the source?

Apparently not.  Imagine if you have a source application with a single document and just one version of it.  When you do a Content Deployment from this application to a destination application the destination will also have the one document as version 1.  Now if you do a full deployment (the option that says: Deploy all content, including content that has been deployed before of this job again) you will still have the one document and its one version at the source application but your target application will have the one document and two versions.  Hence the larger database size.

When this issue was put in front of Microsoft the response we got was turn off versioning at the target system.  Well there are two problems with that approach:

  1. There is no single switch that will turn of versions in every list and library.  So you have to write a script using the SharePoint object Model to do so.
  2. A full content deployment overwrites your version settings and turns them back on if the source database has versions turned on.


So what is one to do?  Well, after the first full deployment you need to:

  1. Write a script that will turn off versions on all lists and libraries in your target application.
  2. Never do a full deployment to this application


Now you can control the growth of the target application database.  One would think SharePoint offered some of these features right out of the box.  But if that happened then how would some people classify SharePoint as a development platform.  LOL


Categories:   SharePoint
Actions:   E-mail | Permalink | Comments (1) | Comment RSSRSS comment feed