Thursday, October 30, 2008
In general we find that Microsoft Transporter Suite is ... lacking (I'm trying to be polite here). But I know it is tough to ignore because it's from Microsoft and your boss knows it's free. Try it yourself and look through the fora before you commit to using this.
Glen did a great article on EML migration into Exchange 2007 using Exchange Web Services. If you're comfortable scripting this will get you through the hard part of inserting email into Exchange 2007.
We think you should also look into using imap2exchange which you can download at http://tp.its.yale.edu/confluence/display/EXCH/imap2exchange+Conversion+Utility. We worked on their calendar migration over the summer and the crew at Yale impressed us as a sharp bunch of folks. Please keep in mind these complements come without any grudging or reticence from a Harvard graduate.
Tuesday, October 28, 2008
Now we'd like to ask some hard questions about the preferred way to migrate data INTO Mirapoint from (say) Meeting Maker or Oracle Calendar Server.
Let's take a look at a typical meeting invitation on the Guest's side. "zygf" invites "russi" to a meeting and Mirapoint puts it on russi's calendar. So far so good. From within the calendar russi now has some options (also so far so good)
He "Accepts" and the meeting remains in his calendar (I do not notice any color or state change here -- does anyone know if this is normal?).
What happens if russi DECLINES the meeting?
The short answer (and it's kind of a weird one) is that it STAYS in his calendar!
The response IS updated on the Meeting Organizer's calendar:
This brings us to our conundrum: Declining a meeting will automatically remove it from a Meeting Maker calendar, and declining will change color state on an Oracle Calendar.
So the question: Is the right thing to do to try to replicate the legacy calendar or to insert data in the New World Order of the Mirapoint system the organization is migrating into? If we delete declines meeting then users do not have the option of going back and re-accepting them. But if we KEEP the declines in the calendar we run the risk of user confusion during the crucial post-migration period.
Since we've decided we're lousy at making decisions for other people we figured we'd ask and then listen to the responses.
Other issues in the Mirapoint user interface:
- There are no Optional Guests or CC / BCC for meetings
- There is no "Weekend move" functionality so we would need to nail meetings / appointments to the specific date of the month
- The "By week of month" option is in the interface limited to one instance (e.g., the SECOND Tuesday of the month) but on inserting a properly formatted VCS file we can create a "Clean Refrigerator" appointment on the FIRST and THIRD Friday of the month. Only problem arises when the owner tries to modify the series as opposed to separate instances.
- No “Last day of the month” capability – e.g., in Meeting Maker I can have a meeting “the Nth day from the end of the month” – usually it’s the Last day – but Mirapoint has odd behavior if I try scheduling a monthly meeting on the 31st – it leaves it completely OUT of months with 30 or fewer days. This is just plain goofy.
- Master exceptions: via EXDATE. This might cause problems with Outlook as a client to Mirapoint. It did in early Zimbra migrations – we need to investigate some more.
- Resources: Looks like Mirapoint has just a single category “Resources” as opposed to the MM distinction of “Location” and “Resources”
- Final note: I have to give Mirapoint kudos for their interface for calendar sharing. It's very simple and very clear (something most other vendors have not figured out how to do yet):
Thursday, October 23, 2008
Their online demo bears a really close resemblance to OWA. This part I do not get: If you want to choose to not be part of the Microsoft Global Co-Prosperity Sphere, why on earth do you want the interface to be exactly the same? It's like not wanting to watch Seinfeld itself, only a high school acting troupe doing the exact same gags and plots. If that's what you want in front of you the original is much better.
However, short answer is NO. Mainly their mechanism to put in data is via PSTs (using ExMerge), with some scripts to migrate contacts via CSV. We don't produce PSTs (it is a real pain and we do not get much call for it). We can go into Exchange via CDO and EWS, and we can produce ICS, but none of the mechanisms we see in their Wiki will let us put in calendar data with the fidelity we are known for.
Wednesday, October 22, 2008
You even have options to EXPORT them (from which you can also take them into Outlook).
Tuesday, October 21, 2008
That one room hosted 2,450 individual instances of meetings (i.e., we count each recurring instance).
Figuring that there are 260 work days in a year, this means on average there are 9 meetings a day in that conference room (which sounds pretty close to full capacity, though there are occurrences on weekends).
What was also interesting was that there were 288 broken meetings in it (clogging the availability), or on average 1 broken meeting per work day.
Now given that this is from ONE conference room are we drawing big conclusions from it? No.
We were really astounded to see it anywhere near 1 per work day, though.
Friday, October 10, 2008
In "New" Outlook I see this (we had no doubt our friends in New Zealand were correct about this, but we love the phrase "trust but verify"):
We did manage to extract the contact data and what we had to do was make it all REALLY EXPLICIT. Note that I also used two different versions of Outlook (2002 vs. 2003) just to keep the locations straight.
To start in OCFO select File-Import and Export:
You're exporting to a file
In fact a PST
And all we want right now is the Contacts:
Pick a location where you can save it (I picked next to the standard Outlook.PST file, because the size difference 48 vs 64 KB between the two is interesting).
Now on the Exchange side, you can run the process in reverse, or you can use Data File Management
Add a new PST, Point to your contacts.pst file,
And the end result is that you've got your contacts over:
So for the really curious calendar person: What the heck is going on here?
Let's take a look at the file structure of OCFO. Almost all the files under the /Outlook/Oracle Connector... directory are pretty small, except for the one I found called "mdb" which being within the same order of magnitude as the PST files we found makes it a good candidate for the location where OCFO data gets stored.
In fact there are several of these throughout this directory structure. Those of you who ever had the pleasure of working in 1980's era dBase will feel deja-vu. I started doing correlations between GUIDs for the contacts in Outlook/OCFO and the data here using a binary viewer, but that got to be a hassle very quickly. Russ looked at running SOAP requests for contact data using the OCS API, which he rapidly decided was "obscure and painful."
We know the contact data is in there (somewhere), but the method we sketch above has the advantages of being simple, fast, and actionable without coding.