Advance Notice: Sumatra in SF Sept 30, Oct 1

Sumatra (well, Zyg) is going to be in San Francisco on September 30 and October 1,  Mainly he's there to go to the Opera, but since that always happens at night and his engaging wife will be working at Wells-Fargo, if any of our calendar-oriented acquaintances in the Bay Area are looking for some guidance, drop a line.

Propagating Changed SIP URIs to Existing Meetings

One of our favorite sites contacted us about a problem they're anticipating. Knee-deep in solving said problem we at Sumatra wonder if anyone else has the same issue.

They're changing a number of SMTP addresses and want to change the associated Lync SIPs to match.  Here's Microsoft's guidance on how to do that for Office 365.  And a different take on scripting a solution.  See Impact of Changing a User's SIP Address for a full discussion.

Changing the SIPs is not the problem, but the number of existing meetings with the old SIPs that are then left in your users' calendars IS a problem that requires updating.

So in this example of an existing calendar item, let's say riuliano became russ_iuliano, to keep end users from going bug-house you'd want to modify all the LiveMeeting URLs in existing calendar objects server-side and update them.

And this is the cue for Sumatra's ability to manipulate Exchange calendar data.

Does anyone else out there have the same problem?

More Weirdness in an Over-Loaded Google Calendar

While experimenting to see if I could delete calendar items from a calendar and thereby finally clear an over-loaded test account I got this message:

 "Oops"?  Cute.  Too bad I do not know any serious corporations that ask for cute.

The goal was to see if deleting items would get me below a threshold, or if the threshold was irreversible.

The weird thing is that once I got that message, previously-deleted objects began re-populating the calendar.  Calendar zombies had risen from the grave!

Clearly there's a cache of the deleted items.  I have no information on when, how often, or if it gets cleared in a single session.

There is also some interesting behavior with old items.  To see this, load 10-15 years worth of calendar data and then travel back to some month in the year 2000.  The following unobtrusive message will display while the data renders (and it seems to take a while):

So there's either some background mechanism shunting historical data into slower, longer-term storage, or the system is not really optimized for rendering arbitrary stretches of time.

Added on September 6, 2011:
A variation of the above: cannot load your data -- come back when it's more convenient for Google....