Best signature we've seen so far

Christopher Quinn in Wisconsin, one of our favorite calendar geeks, has one of the more helpful email signatures we've seen in a while, which we're posting here to spread the word.

These are the top behaviors to encourage to keep from creating broken meetings in Outlook/Exchange.

The 4 most important things you can do to prevent calendar related issues

1. Always send updates to all when making any change to a meeting


2. Always send cancellations to meetings being removed from a calendar


3. Always process meeting requests every time you open them


4. Make sure that requests are deleted from the inbox after replying

And for those of you who want the full story - check out the excellent article Outlook meeting requests: Essential do’s and don’ts

A new source for broken meetings in Outlook/Exchange

Just as we're getting certain we found and plugged one source of broken meetings, along comes another.

Namely, KB 954284 : Outlook 2007 does not send out meeting cancellations if you remove all invited attendees from a previously created appointment.

The interesting thing about this one is that it occurs in pure Outlook 2007 environments, as opposed to the more well-known 2003/2007 cases.

We're looking at it.

Oracle Beehive and Migrating from Meeting Maker

Over the last few years our inquires have been running something like 90 to 0 in favor of getting OUT of Oracle Calendar Server.

Imagine our surprise when this morning we had an inquiry of a site wanting to migrate from Meeting Maker INTO Oracle Beehive.

Editorial Update August 19, 2008: Looks like instead of Beehive (which we referred to internally as "Buzz Off" but we also heard called "Hornet's Nest") they're going to Zimbra. All in all a safer choice.

We jumped into figuring out how to do it (only too aware of how we will invariably discover underlying problems we did not anticipate).

Step 1: Export your MM server as a .DAT file, ship it to Sumatra, and let us convert it into an Access database (easy, we handle this now).

Step 2: Using Sumatra's zinsert tool, convert MM data into a series of related iCalendar files (easy, we handle this now).

Step 3: Using import_icalendar in Beehive, bring in the converted data from Step 2 (now this we have not tried in the real world and expect to find at least one or two problems when we do).

The command will look something like this:

beectl import_icalendar --file zyg@sumatra.com.ics

And of course it will be repeated N times where N is the number of users you have.

I'm not sure if this will properly handle resources and locations yet, but stay tuned.

Short answer to those of you wanting to get calendar data into Beehive: It looks good -- but we're going to team with you if you understand that right now we're considering it more of a "clinical trial" than a released solution.

We suspect we're going to have some problems with GUID format and Time Zone nomenclature, but the architecture of the method looks sound.

Also, please check out Gartner's Oracle Jumps Into the Collaboration Market (Again).

Now, for the problem of taking calendar data out of Beehive and putting it into Exchange -- our experience has been that won't be an issue for the next 12-18 months. But if it's an issue for anyone sooner than that just let us know -- we can certainly insert any calendar data into Exchange.

New Flag for Zinsert Zimbra Migration

Sometimes I feel a little like Ron Popeil (I have seen him speak in person and he was amazing) when I talk about new features.

So I'll just launch into that mode now.

Has this ever happened to you?

You have 1500+ users in Meeting Maker and you want to migrate them to Zimbra. So you export your Meeting Maker database with 1200 user IDs mapped to your new Zimbra email, figuring you're going to delete the other 300 low-volume / terminated / lost at sea users later on.

But Sumatra Development (those meanies who don't understand the pain it is to compress Meeting Maker data with the Admin utility) tell you you have to MAP all those users (or go through some Béla Károlyi-class gymnastics variations to remove the relevant data from the database) before their process will work.

Worry no more!

We added a switch "-skipnoemail" if you want to skip over users with either null or empty email addresses, they'll not create ICS files or appear in guest lists. So it saves time all around.

We're not done yet!

We uploaded it to the relevant FTP sites for anyone currently migrating or testing migration.

Call before midnight tonight!

Oracle Calendar migration clients do not need it since they can selectively set the user calendar data they extract.

Designates to Sharing Roles: Reading 'em in and Writing 'em out

So now you're saying: I have this Designate data out of my soon-to-be retired Oracle Calendar Server, what do I do with it now?

We'll tell you that -- but first you've got to wrap your mind around the fundamental conundrum of OCS Delegate to Zimbra sharing roles mapping: that OCS has WAY more options than Zimbra.

This can be potentially infuriating to end users (who have gotten used to the range of capability) and maddening to the folks in charge of migrating (who need to communicate this to those potentially irate and already confused end users).

We've kept it as simple as possible.

If Alice made Bob a Designate with any View rights at all in OCS, in Zimbra Alice would at least have given View sharing privileges to Bob. (This is not too controversial.)



For Modify Privileges it gets a little more intricate, but relies on a simple choice: Do you want to cast a wide net or a narrow one?



Let me expand on this. For all users when converting this data you have this option in OraCalReader:

Since in OCS Alice meant for Bob (say) to have at least some Modify rights, if you want to cast a wide net, select ANY. If you as a company want to strictly allow Modify rights only if full modify rights have already been allowed, select ALL.

So now this all goes into our intermediate database and to produce a list you can execute, go into the database, select Macros, and double-click on M_OutputZimbraProxies (we tend to use the term Proxy for Designate/Delegate/Sharing Role for historical reasons).

This results in an output file called ZMPROXY.BAT, which looks like this:

zmmailbox -z -m claudette@DOMAIN mfg -i /Calendar account adam@DOMAIN rwidx

zmmailbox -z -m claudette@DOMAIN mfg -i /Calendar account bela@DOMAIN r

zmmailbox -z -m location1@DOMAIN mfg -i /Calendar account claudette@DOMAIN rwidx

zmmailbox -z -m bela@DOMAIN mfg -i /Calendar account adam@DOMAIN rwidx

Which says Claudette gives Adam read/write access to her calendar, etc. etc. etc.

Of course you've got to take this to file to Zimbra and run it as your Zimbra admin. You also can edit it before you do so if you need to.

The same capability will work for Meeting Maker Proxy roles today (we read these directly from the raw Meeting Maker data).

If folks are interested in doing this for migrating Designate rights into Exchange we'll look at it -- it's a little more complex and will work only for Exchange 2007 sp1.

Extracting Oracle Calendar Designate Data

We went ahead and did it: We're extracting Oracle Calendar Server Designate data, feeding it into our intermediate database, and outputting it to automatically set up Sharing Roles in Zimbra (just because it was relatively easy and we have a motivated real-world test client down the street).

Microsoft Exchange users - we'll see (side note: you have to be migrating to Exchange 2007 sp1 -- we are not inserting Delegates into Exchange 2003 ever again).

So first issue: How to extract the data.

We use two batch files to create a file out of OCS that we can manipulate easily.

The first is called EXPORT-DES.BAT and looks like this:

call uar "S=Garcia/G=Jerry"

call uar "S=Liberace/G=Walter"

call uar "S=Lennon/G=John"

call uar "S=Amiumi/G=Puffy"

call uar "S=Page/G=Jimmy"

call uar "R=CR Mozart"

call uar "R=Shea Stadium"

All it is is a list of users and resources which are being passed to a second batch file UAR.BAT which does the hard work. Can this be further scripted? Sure -- but we're aiming for simplicity and clarity here so we'll leave further development as an exercise for the motivated migrator.

UAR.BAT is simply executing UNIACCESSRIGHTS on OCS and dropping everything into a file we can read.

UAR.BAT looks like this:

echo %1 >> des-ALL.txt

uniaccessrights -ls -grantor %1 -grantee "S=*" -n 1 -p PASSWORD >>des-ALL.txt

echo enduser >>des-ALL.txt

echo "" >>des-ALL.txt

This produces des-ALL.TXT which looks like this:

"S=Garcia/G=Jerry"
Grantee: S=Lennon/G=John/UID=John.Lennon/ID=257/NODE-ID=1

Designate Right: CONFIDENTIALEVENT=VIEWTIME/CONFIDENTIALTASK=MODIFY/NORMALEVENT=MODIFY/NORMALTASK=MODIFY/PERSONALEVENT=REPLY/PERSONALTASK=MODIFY/PUBLICEVENT=NONE/PUBLICTASK=MODIFYEvent Viewing Right: CONFIDENTIAL=ALL/NORMAL=ALL/PERSONAL=ALL

Grantee: S=Liberace/G=Walter/UID=Walter.Liberace/ID=260/NODE-ID=1Event

Viewing Right: CONFIDENTIAL=NONE/NORMAL=ALL/PERSONAL=TIME

Grantee: S=Page/G=Jimmy/UID=Jimmy.Page/ID=262/NODE-ID=1

Designate Right:CONFIDENTIALEVENT=MODIFY/CONFIDENTIALTASK=MODIFY/NORMALEVENT=MODIFY/NORMALTASK=MODIFY/PERSONALEVENT=MODIFY/PERSONALTASK=MODIFY/PUBLICEVENT=MODIFY/PUBLICTASK=MODIFY

Grantee: Everyone

Default Event Viewing Right: CONFIDENTIAL=ALL/NORMAL=ALL/PERSONAL=ALLDefault

Task Viewing Right: CONFIDENTIAL=ALL/NORMAL=ALL/PERSONAL=ALL

Default Scheduling Right: CANBOOKME=TRUE
enduser

""

"S=Liberace/G=Walter"
Grantee: Everyone

Default Event Viewing Right: CONFIDENTIAL=TIME/NORMAL=TIME/PERSONAL=TIME

Default Task Viewing Right: CONFIDENTIAL=NONE/NORMAL=NONE/PERSONAL=NONEDefault Scheduling Right: CANBOOKME=TRUE
enduser ""

If you think this looks like gobbly-gook you should see some of the other data formats we've had to read over the years.

How's this get put into the intermediate database?

Via the new options on OraCalReader.exe (which we will explain in the next few days).

Delegate, Designate, Proxy, Sharing Role, Whatever

The simplest things to describe are almost invariably the ones that go by dozens of different names as vendors either try to give you the impression they're differentiated or try to make it easier to comprehend their features.

So to try to make some sense of the way "Delegate" or "Proxy" (our two favorite ways of describing selectively giving view or edit rights on your calendar to someone else) among the calendars we most often see we put together this table.

The wild card in all of this is Oracle Calendar which has a lot of functionality in its own domain which (by definition) does not transfer exactly to less rich domains (like Microsoft Exchange).

Oracle Calendar Designates and Zimbra Sharing Roles

We got asked about moving Designate rights from Oracle Calendar Server into Zimbra, and came up with a simple solution that in our spirit of full-disclosure we figured we'd document.


Let's begin with the end in mind.



Zimbra has three Roles for sharing: None, Viewer, and Manager.

In sharing you can grant Read, or you can grant Read and Write, or you don't grant anything at all.

Oracle Calendar has many more and finer-grained options.

Let's look at one of our test OCS users Jerry Garcia.

His Designate John Lennon has options on both Reading (Viewing) and Writing (Designate) calendar items, also cross-referenceed against the security level of individual items (and keep in mind both Outlook and Zimbra have only two levels of security to individual items: Public and Private).

Walter Liberace has no Designate rights granted by Jerry Garcia,

but Walter Liberace does have Viewing rights.

Jimmy Page has full Designate rights.

So how on earth do you take something with a matrix of possibilities and distill it down to fit into a paradigm with two?

If you ran this command in OCS:

uniaccessrights -ls -grantor "S=Garcia/G=Jerry" -grantee "S=*" -n 1 -p PASSWORD >jerry_garcia.txt

You'd generate this output:

Grantee: S=Lennon/G=John/UID=John.Lennon/ID=257/NODE-ID=1Designate Right: CONFIDENTIALEVENT=VIEWTIME/CONFIDENTIALTASK=MODIFY/NORMALEVENT=MODIFY/NORMALTASK=MODIFY/PERSONALEVENT=REPLY/PERSONALTASK=MODIFY/PUBLICEVENT=NONE/PUBLICTASK=MODIFYEvent Viewing Right: CONFIDENTIAL=ALL/NORMAL=ALL/PERSONAL=ALL

Grantee: S=Liberace/G=Walter/UID=Walter.Liberace/ID=260/NODE-ID=1Event Viewing Right: CONFIDENTIAL=NONE/NORMAL=ALL/PERSONAL=TIME

Grantee: S=Page/G=Jimmy/UID=Jimmy.Page/ID=262/NODE-ID=1Designate Right: CONFIDENTIALEVENT=MODIFY/CONFIDENTIALTASK=MODIFY/NORMALEVENT=MODIFY/NORMALTASK=MODIFY/PERSONALEVENT=MODIFY/PERSONALTASK=MODIFY/PUBLICEVENT=MODIFY/PUBLICTASK=MODIFY

Grantee: EveryoneDefault Event Viewing Right: CONFIDENTIAL=ALL/NORMAL=ALL/PERSONAL=ALLDefault Task Viewing Right: CONFIDENTIAL=ALL/NORMAL=ALL/PERSONAL=ALLDefault Scheduling Right: CANBOOKME=TRUE

Remember -- our end result needs to be binary (if you're there at all you're in View Role or Manage Role), so our decision making process needs to be equally black and white.

Our two basic rules:

If you're giving an OCS user any Viewing rights at all then in Zimbra you'd at least giving them Viewer rights (not too controversial).

The next step: if you've given them Modify rights on anything in OCS then they get upped to Manager level in Zimbra.

Final step: If your users are making you set this up for them they can go in post deployment and switch them around.

How's this sound to everyone?

Stay tuned for how we implement taking this data out of OCS and putting it into something you can use in Zimbra.

Broken Meeting Data and Exchange 2007

Let's say you're in Exchange 2007 and still using Outlook 2003 (not that we ourselves do this or have any clients with this kind of environment, but we hear tell it's still done). So you create a meeting and invite a managed resource. Like this:

Let's say that later on your users do things like deleting resources from meetings and not sending updates. Sort of like this:

Is this avoided by using Outlook 2007? Yes. But 1.) This happens now and 2.) If you upgraded to 2007 from 2003 before you mandated Outlook 2007 to correct this you probably still have the results of this activity floating around your calendars.

The result is what we've been calling Broken Meetings (you'll hear us sometimes call them "orphan" or "zombie" meetings) -- cruft that's making your resources harder to manage by taking up space they shouldn't be.

This wouldn't be a big problem if you could

1. Identify them


2. Remove them

So glad you asked what we were doing about it. Since we've gotten really used to creating well-formed calendar data in Exchange we started reversing the process to find data that isn't well-formed.

The result is this early version of code based on our existing insertion tools:

Check out the FindBrokenMtgs and DelBrokenMtgs buttons. I also need to mention that anyone who's fallen into the various Permissions black holes in E2K7 will immediately (and correctly!) intuit that setting this utility up to dig out all this data can be challenging.

Keep in mind we created a Broken meeting in Room 222 above, so let's feed that in and see what we find:

Looking for Broken Meetings we find the one that we know is waiting to be found.

Next step of course is to remove it.

The process obviously gets a lot more complicated when you add recurring meetings and recurring meeting exceptions to the mix (and we've already dealt with that).

Also the process is closely related to the "Terminated User" problem of how to clear out meetings from former employees (and you'll see oblique references to this on some of the buttons above).

We'd really like to hear feedback on how useful capability like this would be and the best way to present it to an Exchange Admin.