Featured Post

Three Basic Ways of Dealing with Double-Booked Resources in the Sumatra cmdlet

There are three basic ways of automatically dealing with double-booked resources in the Sumatra cmdlet suDoubleBookedMeetings. You guys wo...

Monday, April 14, 2008

Save XP Petition

What does this have to do with calendaring?

Absolutely nothing.

But Windows Vista is "unsatisfactory" -- a phrase which here means "causes me to blow chunks."

InfoWorld started a petition to save XP -- which I signed as soon as I heard about it

Go there -- you know you must.

Thursday, April 10, 2008

Migration Best Practices

Our most recent migration client had what we consider to be one of the best communications strategies we've seen in a while -- they used this thing called a "web site."


We have seen similar things in the past -- what distinguished these folks was how well-planned and executed their entire user community communication strategy was.
Check out the example.

Wednesday, April 09, 2008

Google Calendars as SPAMbots

I could not believe it when it first happened last week -- but there, tucked in between the usual offers to increase body parts half the world does not have and the insane offers I get in Russian, was a Nigerian scam CALENDAR INVITATION!

And this morning there are now two others:



The huge problem with these of course is that they show up in my calendar (which obviously makes this an interesting variation for the spam-mongers). Russ's comment was classic: It must be SPAM because "Dearest Beloved One" could not be how anyone who knows you refers to you.

To make matters worse it looks as though they're originating out of Google Calendar:


Normally I would start thinking about ways of intercepting this client-side at my Outlook inbox -- but given that the script kiddies of the spamosphere have figured out how to harness Google Calendar for their ends, I'm hoping this one gets solved in Mountain View.

Anybody else noticing this?

Tuesday, April 08, 2008

Exchange Auto Accept Agent: Danger Danger!

We had a client report a weird experience Monday and we wanted to share it for the benefit of others.

They'd just migrated a few metric tons of calendar data into Exchange 2003 sp2.

The data looks fine, but after deleting a resource account that had been registered to the Auto Accept Agent (see the Deployment Guide) they discovered their server CPU usage pegged at 100% (not even a calendar migration usually does this!) and various other wrath-of-your-favorite-deity-type plagues on their Exchange server.

Turns out this is a well-known problem documented in the KnowledgeBase article An Exchange Server 2003 SP2 server becomes unresponsive after you delete a mailbox on which you registered the Auto Accept Agent event sink.

The best way to deal with the problem is to avoid it. (Patient: It hurts when I do this. Doctor: Well don't do that.)

But if you're already in the soup, fixing this problem if it happens to you involves using MfcMAPI. More than that you're going to need to know which registered resource was removed so you can make things right. Since there are no logs to guide you if this should suddenly happen, we recommend the Microsoft Exchange Team Blog article How do you know which mailboxes are registered with the Auto Accept Agent?

Keep track of your resources!