all site content copyright © chris rue. all rights reserved. any reproduction, re-use or summarization of any kind without prior written consent is prohibited.
March 2, 2007

scratching your nose with a sledgehammer


that’s what the dst patches from ms feel like.

here’s what a small sampling of my customers have said about the way dst updates & info were released from microsoft…

what were they thinking?

were they thinking?

who in their right mind would release this kind of stuff?

haven’t they known about this for a couple of years?

what were they doing for 2 years?

are they insane?

sure, we could all just throw off on politicians & their half-baked ideas that always seem to manifest as capricious changes to stuff like dst.

but that still doesn’t change the fact that ms has totally & utterly acted like an ostrich with its head in the sand regarding dst.

according to some folks, exchange is mothership’s flagship product.

i’d argue that redmonds’ real flagship products are white papers, faqs & patches, but i digress.

either way, hearing ms talk about the centrality of exchange 2007 makes the cockamamie level of support for dst changes on previous versions all the more confusing. if i wanted to sell customers my newest version, the very last thing i’d do would be to leave them hanging out to dry with the current version they are running. all that will do is make them start looking for alternatives.

here’s what i’d argue is the real-world experience of most companies. if there is any patch management going on, it looks like this:

  • server(s) set for either notify only or don’t update
  • workstations set for automatically update

since ms flagged the dst updates as critical, those workstations got the patch automagically, as soon as it was released a couple of weeks or so ago, right?

so loooooong before exchange had been updated at the back-end server level, in all likelihood the end clients had started laying in appointments that were correctly based.

then along comes the admin, to load the patches on the server & rebase the calendars.

since the end-user patch process wasn’t correctly timed…

& this update, above all others, is hideously time sensitive…

when either rebasing tool is run, the resultant mix of basing that occurred after the client side patches were loaded means the changes that get applied to calendars are the rough equivalent of what happens to a watermelon that gets loaded into the iconic sledgeomatic.


add to this the fact that rebasing, no matter what tool you use, is a one-shot deal.

so no matter what the outcome, you’re stuck with it.

that’s pitiful.

so, from the robot horde at the funlab…

good luck kiddos.

we’re all gonna need it.

|| posted by chris under funlab, mothership, thumbs down, time || comments (0) || ||

no comments »

rss feed for comments on this post. | trackback:

leave a comment

XHTML ( You can use these tags): <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> .