Terminated with extreme prejudice

You know the scenario -- people in your organization are coming and going all the time. When they come in you have a handle on it. When they go, well, that's a different story.

In particular, Exchange has a nasty habit of letting them leave the building but linger on in broken meetings.

We've been working on the problem and we got asked about it yesterday, so I figured it was a good time for a running commentary.

Let's create a user called Elvis Morrison.

Elvis enters the company sets up a few meetings and, in the way of all flesh, is downsized or leaves for greener pastures. When he leaves this is what his calendar looks like:

We can delete Elvis from Active Directory in a few seconds:

But if we just delete him then his meetings will linger (with no way to cancel them). So in the Conference Room 222 calendar, Elvis is still very much alive!

He's also still in end user calendars.

Now, if we wanted to cancel all of Elvis's meetings BEFORE we deleted him from Active Directory, that would be easy. Just run our tool and click Test2: Report/CancelMtgs

You get options like

Let's say we want to cancel them.

And let everyone know why.

And it tells us what's going on.

BUT let's say users have been being deleted for a while or we deleted Elvis before removing his meetings. We can STILL clean out the resources (we can do the users, too, but let's focus on the rooms and resources).

Let's say we're looking to clear out the cruft from Conference Room 222.

Put in the Room ID and click
It will find all instances of Elvis's recurring meetings in it (as well as any other broken meetings, but I happen to know the only ones in there just now belong to Elvis)

And it creates a separate report

To get rid of them (you can edit the report to remove the ones you want to keep) click


Going into the calendar for Room 222 means it now looks like this, cleaned of the broken meetings Elvis organized.

The more astute among you will recognize there are some additional subtleties to this, but I'll save those for another blog posting.

Editorial addition (Sept 14, 2008)

The "Export Mailbox" cmdlet will archive all Elvis's data to a PST, but it does NOT cancel his meetings. See this discussion.

Meeting Maker to Mirapoint

We got contacted a few months ago by a college looking to migrate their Meeting Maker into Mirapoint.

Not that we got a lot of answers from the folks at Mirapoint, but based on the open sources we could read (something called Mirapoint Administration Protocol Reference), we think it goes like this:

1. Export your MM database t0 a DAT file and ship it to us for conversion
2. We convert it and give it to you with our tool zinsert that produces iCalendar format files
3. Run zinsert to convert all your MM data into ICS files for each user
4. Use the Mirapoint Calendar UPSYNC Subcommand to load the ICS data into each individual calendar file.

Migrate calendar data from Exchange 2003 to iCalendar via the M: drive

We did a little bit on this a while ago and never saw the need to take it much further, but we figured we'd sketch it here in case anybody else wanted to take this as a launch point.

Suppose you want to migrate your calendar data to Zimbra (or some other place that takes in iCalendar format) from Exchange 2000/2003 under your direct control? Note: For Exchange 2007 you are out of luck with this method (no access to the M: drive).

So instead, expose the M: drive. One of our previous posts tells you how.

You'll be able to drill down to the Calendar folder and see all your appointments and meetings as .EML files. Believe it or not embedded in these EMLs is all the ICS data you need to insert into Zimbra (I'm not promising you're not going to have to modify it, but it's there).

So let's look at one of them.

Received: by trout.sumatra.local id <01C894A4.D2E612E0@trout.sumatra.local>; Wed, 2 Apr 2008 05:35:01 -0400 Content-class: urn:content-classes:appointment Subject: private noon Date: Wed, 2 Apr 2008 05:35:01 -0400 Message-ID: <F47225046904E34AAA50D7CFB96277FC03AED5@trout.sumatra.local> X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894A4.D2E612E0" X-MS-TNEF-Correlator: Thread-Topic: private noon Thread-Index: AciUpNLoQOwqLSklRJaoHMVqqUnkhQ== Sensitivity: Private x-mimeole: Produced By Microsoft Exchange V6.5 From: "zyg furmaniuk" <zyg@sumatra.local> This is a multi-part message in MIME format. ------_=_NextPart_001_01C894A4.D2E612E0Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: binary ------_=_NextPart_001_01C894A4.D2E612E0Content-class: urn:content-classes:appointmentContent-Type: text/calendar; method=REQUEST; charset="utf-8"Content-Transfer-Encoding: 8bit BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:(GMT-05.00) Eastern Time (US & Canada) X-MICROSOFT-CDO-TZID:10 BEGIN:STANDARDDTSTART:16010101T020000TZOFFSETFROM:-0400TZOFFSETTO:-0500RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SUEND:STANDARDBEGIN:DAYLIGHTDTSTART:16010101T020000TZOFFSETFROM:-0500TZOFFSETTO:-0400RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SUEND:DAYLIGHTEND:VTIMEZONEBEGIN:VEVENTDTSTAMP:20080414T173637ZDTSTART;TZID="(GMT-05.00) Eastern Time (US & Canada)":20080402T120000 SUMMARY:private noon UID:040000008200E00074C5B7101A82E00800000000E072D44B8394C801000000000000000 0100000002D6C78C6FF3E504D8F29FB17733C0F74 ORGANIZER;CN="zyg furmaniuk":MAILTO:zyg@sumatra.local LOCATION: DTEND;TZID="(GMT-05.00) Eastern Time (US & Canada)":20080402T130000 SEQUENCE:0 PRIORITY:5 CLASS:Private CREATED:20080402T093448Z LAST-MODIFIED:20080402T093501Z STATUS:TENTATIVE TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:-1 X-MICROSOFT-CDO-APPT-SEQUENCE:0 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20080402T093501Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT05H00M00S END:VALARM END:VEVENT END:VCALENDAR ------_=_NextPart_001_01C894A4.D2E612E0--

So you remove everything that is not iCalendar (i.e., the email header and that small footer following the END:VCALENDAR) and swap out your email address or domain if necessary. I didn't in the example that follows and it didn't come in properly.

Upload to Zimbra using something like curl, and your before and after shots look like this:

Keep in mind, this will happen one meeting or activity at a time.

Have we rigorously tested every aspect of this? HECK NO! But this gave us enough to go on that we knew if we needed to modify something (like possibly recurrence patterns, exceptions, or maybe the GUID format) that we'd able to figure it out. Again, this is meant to suggest a more general methodology for moving calendar data out of Exchange 2000/2003.

Of course you can do pretty much the same thing with your email as well. We tested that and got attachments to come over. BUT, we learned to add an additional tag X-Zimbra-Received as per this article.

For a masterful discussion of using the M: drive in Exchange for a migration see: Migrating from POP3/SMTP servers using the M Drive

Why migrate server-side rather than client-side?

We spent part of this week looking at how to convert Meeting Maker data into iCalendar data to import into Outlook via Import on the client side. If this is your first time reading this blog please understand that analysis is a little bit like waking up one morning to find that the Kaiser won the First World War.

So why would we look at this? Because sometimes folks come back to us and ask for additional history for some users, and for just a few it's a lot easier to accomplish client-side rather than server-side.

Our usual average server-side migration rate is 750 objects per minute (whether using EWS on E2K7 or CDO on E2K3).

Our method was to use our off-the-shelf technology to convert Oracle Calendar and Meeting Maker into iCalendar for Zimbra insertions. With few modifications we were able to convert to a format Outlook would read directly.

Client-side the average insertion rate is between 200 and 300 objects per minute. Translation: client-side you get one-half to one-third the speed of server-side.

Just where the heck is all this Delegate information stored, anyway?

In this political season (in the USA at any rate), sometimes you need to "grabificate the bull by the horns and milkify that steer for all that he's worth." (No Dubya did not actually say this but work with me here, we're on a roll.)

So WHERE you might ask does all of this DELEGATE information actually live in Exchange?

The short answer is ALL OVER THE PLACE.

Here is the quick reference list:

1. Folder Security Descriptors
2. Active Directory
3. The (infamous) NON_IPM_SUBTREE
4. Server-side rules (for the special case of forwarding meeting invitations)

So to modify Delegate programmatically you need to take care of ALL of these.

Folder Security Descriptors

For Exchange 2000 and 2003, see Modifying Store Permissions in Exchange 2000 and 2003

For Exchange 2007 you use the Management Shell.

Every object (and a folder is an object with other objects potentially inside it) in the Exchange database has a security descriptor that determines who can access it. One of the main sources of confusion in all this is that from WebDAV Exchange can SEEM like it's a filesystem (remember the (in)famous M: drive?) but it never acts like one in any API. PFDAVAdmin does a great job at modifying access permissions for both Exchange 2003 and 2007.

Active Directory

Send-As permissions are kept in AD. The field publicdelegates contains the list of URLs of all users with access to the mailbox. Active Directory does a BIG favor here by maintaining backlinks in other users' publicDelegatesBL.

So by checking any user's publicDelegatesBL property, you can find out for whom they are a delegate. This was put to creative use in Listing Which Exchange Users Have or Are Delegates and Finding delegates in Active Directory (sic).

The perceptive among you will realize that if you are a delegate to someone and they have subsequently been removed from Active Directory you might still have some kind of zombie connection to them. Such is often indeed the case.

NON_IPM_SUBTREE

The file NON_IPM_SUBTREE/Freebusy Data/LocalFreebusy.EML which not surprisingly contains Free-Busy data (but be careful trying to read it) also contains three MAPI properties which define Delegates.

• x6844101F PR_DELEGATES_DISPLAY_NAMES
• x68451102 PR_DELEGATES_ENTRYIDS
• x686B1003 PR_DELEGATES_SEE_PRIVATE

Private items have PR_SENSITIVITY =2, Public items have PR_SENSITIVITY = 0. Confidential items have PR_SENSITIVITY =3, but Outlook does not do anything with Confidential items and the Exchange server does nothing to enforce Private items leaving this to the client (ever read me write that this was all designed and implemented by some committee somewhere?). So those of you looking to migrate this capability from Oracle Calendar Server where there is a client side distinction between Private and Confidential, you can migrate it, but it will do you no good.

BTW, Google has picked up on how useful it is to document MAPI tags.

Modifying the AD values has NO EFFECT on the values in the NON_IPM_SUBTREE. You have to take care of that separately. The incomparable Glen Scales blogged on how to in Accessing the NON_IPM_Subtree folders in Exchange Web Services .

Server-Side Rule

Like all SSRs this is in the INBOX for the user doing the forwarding (which means the client does not need to be running for it to be invoked, which is exactly what you want from an end-user perspective).

• x65EB001F PR_RULE_MSG_PROVIDER which should be "Schedule+ EMS Interface"

By way of comparison, PR_RULE_MSG_PROVIDER is

• "RuleOrganizer" for normal Outlook rules
• "Schedule+ EMS Interface" for delegation rule
• "MSFT:TDX OOF Rules" for OOF Wizard rule
• "MSFT:TDX Rules" for Public Folder rule
• "MSFT:MR" for Public Folder moderation rule

For managing rules in E2K7, check out http://msexchangeteam.com/archive/2008/04/14/448687.aspx and Glen has also already blogged on the topic.

I am hugely indebted to the work Ximian did in reverse-engineering all of this before it was absorbed by Novell.

PFDAVAdmin and Calendar Delegate Permissions

Update on August 28, 2011: I noticed the popularity of this posting has risen A LOT lately.  If you are in Exchnage 2010, ignore this and read our more recent post Exchange 2010 Calendar Permissions Using PowerShell.


In every generation a utility comes along which can address some of nastier sturm und drang of the harried calendar administrator trying to set up Delegate permissions. In ours it is PFDAVAdmin.

Now those of you who have been faithful followers of the vagaries of migrating Proxy or Designate information into Exchange/Outlook Delegate information will be a little surprised by what comes next: this method looks like it works, it looks like it works for both Exchange 2003 and 2007, and it looks like it takes way less time than any of our previous methods. AND it's all built around the off-the-shelf PFDAVAdmin.

So Step 1. is to Install PFDAVAdmin

It comes with its own documentation but there are also some good online examples and debugging:

http://www.msexchange.org/articles/PFDavAdmin-tool-Part2.html

http://technet.microsoft.com/en-us/library/bb508858(EXCHG.65).aspx

http://mostlyexchange.blogspot.com/2008/01/pfdavadmin-exchange-2007-and-v11-net.html

To run this in Exchange 2003 do not forget to use a service account with appropriate permissions:
http://support.microsoft.com/default.aspx?scid=kb;en-us;821897

For Exchange 2007 your usual migration service account should suffice.

Step 2.) Run the appropriate Database Query (from Sumatra) to generate an output text file. If you are already in the middle of testing your database migration you can ask us to take you through the query. Your output file will look like this:

# ************************************************************************ # Created for PFDAVAdmin 2.8 # Friday, August 29, 2008 3:47:25 PM # ************************************************************************ # # This export format is only usable with PFDAVAdmin 2.0 and later. # # ************************************************************************ SETACL Mailboxes\riuliano\Freebusy Data VM\zyg Reviewer NT AUTHORITY\ANONYMOUS LOGON None NO SETACL Mailboxes\riuliano\Top of Information Store\Calendar VM\zyg Reviewer NT AUTHORITY\ANONYMOUS LOGON None NO SETACL Mailboxes\zyg\Freebusy Data VM\riuliano Reviewer NT AUTHORITY\ANONYMOUS LOGON None NO SETACL Mailboxes\zyg\Top of Information Store\Calendar VM\riuliano Reviewer NT AUTHORITY\ANONYMOUS LOGON None NO

Here riuliano makes zyg on domain VM his Reviewer (which corresponds to a Read-Only Proxy) and vice-versa. International users may have to modify this to translate "Calendar" as appropriate (i.e., Calendario, Calendrier, Kalender, Calendário). I do not know if PFDAVAdmin will work with 2-byte character sets.

Step 3
Open PFDAVADMIN. Connect to your Exchange server (you will need adequate Permissions to do this). Select Tools-Import and point to the output file above.

Step 4
PFDAVAdmin will set up all appropriate permissions to share calendars as per your Meeting Maker options.

The log file for PFDAVAdmin will contain any problems (which in our experience with this have usually involved permissions).

Delegates / Proxy Migration in Exchange 2007 sp1

One thing we notice is that folks sometimes want to have their Proxies (Meeting Maker term) or Designates (Oracle Calendar Server term) migrated into Exchange 2007 as Delegates (Outlook term).

For Exchange 2007 before sp1 you were out of luck. For Exchange 2003 you only need to use CDO 1.21 with documented memory leaks. Those of you for whom we have migrated Proxies know this is why the process to migrate proxies takes almost as long as the process to migrate your calendar data. And annoyingly CDO 1.21 is not supported at all in .NET code.

For E2K7 sp1, Microsoft documentation gives you the impression this is possible using only Exchange Web Services. DeVa expands on this a bit in Adding delegates in Exchange Web Services (sp1).

However, our direct experience with a recent client migration to E2K7 sp1 and Glen (whom we cannot praise too much) confirm that setting permissions via Exchange Web Services is insufficient. You also need to set permissions on the Schedule+ NON_IPM_SUBTREE.

Wait you say -- this is 2008 and I just saw the word "Schedule+" appear in print, like it was... 1992 or something. Is this possible?

Rest assured, it is mos def.

In fact at least one user has reported a problem and documented a solution in in this data structure during a migrating from Exchange 2003 to Exchange 2007. Microsoft seems to have picked up on this in KB 945602.

For those of you who want a fuller story on how Delegates relate to the Free/Busy folder, thank Ximian for their work in reverse-engineering and publishing the results (which they did for E2K3).

So the end result here: be really careful writing scripts to set Delegates for calendar functions in Exchange 2007 and make sure you take into account the NON_IPM_SUBTREE in addition to the documented EWS code.

And, this being Exchange, there are additional complications because .... well.... because Exchange is clearly built by committee. So if you have BOTH Outlook 2003 and Outlook 2007, and use Delegate (and I'll bet the answer is "yes" all around), you need to check out KB 924470. While you're at it -- these also give you some idea how funky basic Delegate functioning is in E2K7: KB 950794, KB 918797, KB 932207, and KB 942418.

Does it work or not? This is so convoluted we're not sure. If any of you have feedback let us know.

Shared Calendars in Exchange 2007 sp1

Let's say you used a group calendar in Meeting Maker or Oracle and wanted to migrated that into Exchange. The idea being that any user in a group could post and view calendar data (like vacations or help desk schedules, events, that kind of thing).

Prior to E2K7 sp1 your only option was to migrate it into a user calendar or resource calendar and then make share it.

In a minimally-documented feature you can actually migrate the calendar data to a Shared Mailbox.

But wait you say -- you've been through the Mailbox Wizard, and there ain't no "Shared Mailbox" in it:

That's because you can only create it in the Exchange Management Shell.

So to create a shared mailbox for the former Market Department Group calendar, you might use the following

[PS] c:\New-Mailbox -alias DeptCal -name "Marketing Department Calendar" -database "Mailbox Database" -org Users -shared -UserPrincipalName DeptCal@YOURDOMAIN.com

THEN it will show up in the Exchange Management Console!

What do you do with it now?
Well, not much.... yet.
This is a disabled account. We need to add user access to it, and this brings us into the dreaded world of Permissions.
First, create a security group (via Active Directory Users and Computers) in your domain called "Marketing Department Security Group" and add the users you want to access the calendar. And in our friend the Management Shell, grant that group full mailbox permissions:
[PS] c:\Add-MailboxPermission DeptCal -User:'Marketing Department Security Group' -AccessRights:FullAccess
We're not done yet. You will need to add "Send-As" permissions to the group as well. Those of you doing migrations are really used to this.
[PS] c:\Add-ADPermission "Marketing Department Calendar" -User:'Marketing Department Security Group' -ExtendedRights:Send-As -AccessRights:ReadProperty, WriteProperty -Properties:'Personal Information'
Users in the Group now have full rights to that shared calendar.
So in OWA just pass the DeptCal email address and use your own credentials to log in (please do not send me posts about my Certificate Error, it's a test server for gosh sakes).


SO in Meeting Maker if you have had a group calendar, map and migrate it into a USER calendar and then CHANGE it post-migration to a shared calendar using the "Type" command.
e.g.,
[PS] c:\Set-Mailbox DeptCal -Type:Shared
and set up your Security Groups.
Why not just create a Shared mailbox in Exchange and migrate into that? The account is Disabled -- we won't be able to re-create data in it with full fidelity. Create it as a User and then change it to Shared and you'll be happier with the results.

Need some Exchange Calendar applications or utilities developed for your enterprise-sized organization? Contact us.

UNDO Capability field-proven

You know, it had to happen.


We've been talking about how we have our own UNDO capability and that it hasn't needed to be used in the field since a Dutch MM 6.0 server mistakenly got inserted with an East Coast USA time zone.


Well, owing to an unfortunate bug we had to remove an entire insertion of a few thousand users a couple of weeks ago.


Good news: the UNDO worked fine. And we ran UNDO in parallel and the data was out in way less time than it took to put in.


Better news: their insertion re-ran this weekend without a hitch.


Bad news: Like the recent Incredible Hulk movie we need to re-set the "days since last incident" counter.

Funambol and Migration into Exchange

We got an inquiry about Funambol and how after migration data we inserted wasn't being sync'ed by Funambol but calendar items created directly in Outlook were. After we looked up what Funambol was (usually we see folks use ActiveSync) and the client did some rooting around on their own, we had a reason.

Here's what happens.

You know our UNDO process?

In going into Exchange 2007 we insert the keyword "mmconv102659080256Z" into the Mileage field of an Exchange calendar object.

Why did we choose the Mileage field? Because it's easy to surface when using Exchange Web Services. So in the event we need to do an UNDO we can search through every mailbox and remove only the data we inserted. Very convenient, and a very good safety net.

BUT Funambol is looking at that field and analyzing it to make sure it's actually a Mileage (i.e., a numeric string). So looking at an alphanumeric string is causing it confusion.

Two possible solutions:

1. Post migration: Just remove the Sumatra tags. Of course, do not do this until AFTER you've validated the data.
2. Pre-migration: Choose a different tag that's purely numeric (e.g., "99999999999")

Either one will get you there.

We also insert data into the Billing field (for the technically inclined, they're the GUIDs of the calendar objects so we're sure we're acting on the correct objects when migrating).

We also know of at least one other application that uses the Mileage field for internal purposes - so keep an eye out.

Validating 5000+ Users?

If you're doing a migration into Exchange 2003 or 2007 with more than 5000 users (and this showed up in this case with a migration of over 10,000), and you're using the same database regularly, use the Access "Compact and Repair" option between insertion runs.

The client doing this noticed a marked degradation in Validating user accounts after 5000 users. Investigating we determined a few code fixes that speed the process, but also that the best thing you can do is Compact and Repair the database.

Cool method for cleaning test Exchange databases

We really like it that we deal with smart people.

Case in point: Adam Smith at Yale who created a script called ‘clean-mailbox-database-sumatra.ps1’ that finds the databases on 'your-server' and dismounts them. It then finds and removes all *.edb files in e:\mailbox and then mounts the databases.

clean-mailbox-database-sumatra.ps1:
________________________________________________________________________
#Find all mailbox databases on your-server and dismount them
Get-MailboxDatabase -server your-server Dismount-Database -Confirm:$False

#Find all of the .EDB files and remove them
Get-ChildItem -Path e:\mailbox -Recurse -Include *.edb Remove-Item

#start all mailbox databases
Get-MailboxDatabase -server your-server Mount-Database
________________________________________________________________________

This would not be something to do on your production system (unless you REALLY wanted to clean it), but for a test lab dedicated to a calendar migration it's faster and easier than our selective Undo.

Many thanks, Adam!

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.