Common Calendar Format: What's the Big Idea?

One thing that's become really obvious to us is that while there's a good Internet specification for individual calendar events, which allows you to efficiently pass calendar information around the Internet. But this breaks down at the company level: there is really no good way of moving an entire server of scheduling information from one platform to another.

Surprisingly, there are just three solutions: syching each user's calendar with PDAs, massively emailing iCal events, and exporting and importing individual calendars. All of these have the same several drawbacks:

1. You lose Guest Lists
2. You lose recurrence patterns
3. You lose Guest Responses
4. This really does not sit well with end users who have to live through it, re-entering information they have previously entered
5. It is fraught with difficulty, lack of management, and massive logistical drawbacks
6. Usually conference rooms and resources are an afterthought, though any confusion in their allocation causes more pain quicker than any single user's calendar except the CEO's

Working on legacy Meeting Maker (http://www.meetingmaker.com) data as we've moved it into Microsoft Exchange (http://www.microsoft.com/exchange) and more recently IBM's Lotus Notes (http://www.lotus.com), Sumatra developed the notion of a Common Calendar Format (CCF) to facilitate movement of entire calendar servers between different groupware platforms.

The idea is simple and like iCal aims to abstract out on the information that is always needed, but from the standpoint of the entire collection of users rather than just the standalone user.

Let's define a few terms:

The source is the originating system, usually one past its freshness date, which the end user wishes to obsolete in favor of a newer system.

The target is the desired end point. Usually Microsoft Exchange or Lotus Notes / Domino.

Data is extracted from the source and inserted into the target.

Usually between the extraction and the insertion there is the need to map user ids between the source and target systems.

The mediator of all ofthis is a single relational database which contains the calendar data from the source system, as well as the user ID mapping between the source and target systems.

This approach has several advantages:

1. It allows us to write one application per source system to do the extraction and one application per target system to do the insertion.
2. It retains more of the information in the server than is otherwise possible
3. It centralizes the entire process so it can be handled by the MIS team
4. It compresses the necessary time-frame so that this data can be inserted (usually) over the course of a weekend
5. An intermediate stage allows more fine control over management of data. The migration team can selectively archive past calendar data, or optimize for speed of insertion of current data.

As you have seen, we have source readers for Meeting Maker and (under development) GroupWise, and insertion code for Microsoft Exchange and Lotus Notes (via a development partner). Others are under development as we get demand from customers.

New GroupWise to Exchange Migration Test

The new version of the GroupWise extraction code is available at http://www.sumatra.com/sgwtest.htm.

Basic information:

This is a test of extracting GroupWise calendar info. It dumps minimal info for now, we're mostly concerned with just getting reliable access to it.

What you get:
---------------------------------------------
SGWTest.exe the application, run this
GWTapp.dll this dll you need
GWTapp.dbg the debug version, use it if we say so
pw.txt sample password file pwset.txt sample password file setting a pw
ReadMe.txt this info

SGWTest is run from the command line (also known as the DOS prompt). The information and any error messages are sent to standard out, that means you should run SGWTest like this to get a file of output to sendto us:

SGWTest ...options... > your_output.txt

You *MUST* be logged in to Netware as an administrator to run SGWTest.(i.e. you should be able to run ConsoleOne and create GroupWise users). If you are not logged in prpoperly you'll probably get this ugly error: Access Violation (error 0xC0000005)

The program takes various flags & options, they are detailed in the usage section below. But the best thing is to follow the examples given depending on your scenario.

Authentication Methods
There are several options for accessing user accounts, these are listed below in order of desirability, which method you use depends on yourparticular situation.

1. Trusted Application
The best way to use SGWTest is as a trusted application. This will onlywork in GroupWise 6.5. This does not require you to know any user passwords (except your own Admin password) nor does it change any passwords.

To install SGWTest as a trusted app run the following:
SGWTest -tinstall

This will write a key to the file "key.dat"
Then dump user calendar info by running:
SGWTest -pt

which should find the key file in the working directory
SGWTest -pt key.dat

where you supply the key file name or path.

To remove SGWTest as a trusted application, use ConsoleOne or run:
SGWTest -tremove
or SGWTest -tremove key.dat

You do need the key file to remove the app with -tremove.
Remember to keep the key file safely backed-up.
------------------------------------------------------------------------

2. Password file

If you have versions of GroupWise before 6.5, you need to use a password file.

This file will supply the passwords and user IDs for all users.

The password file is a comma separated (CSV) file, the syntax of eachline is:
,[,]

Where is the (GroupWise) login, is the password and is an optional field either 0 or 1. 1 means set the user'spassword to .

For example:
Bob,secretCarol,pussnbootsTed,vienna69Alice,"doesn't live here"

To use a password file and *NOT* change (set) any passwords, run:
SGWTest -pf pw.txt

(or whatever your file is named). This will ignore any fields.

If you don't know the user passwords you can use the password file to reset all or any user's passwords. For example, you could use the file:
Bob,Bob45,1Carol,Carol23,1Ted,Ted69,1Alice,Alice38,1

And tell everyone e.g. "Your new password is your login with your ageappended", then run:
SGWTest -pfs pwset.txt

The -pfs option is like -pf but *DOES* allow setting the password.

There are example password files in pw.txt and pwset.txt

NOTE: If no password is available for a user, or the wrong password is supplied, you'll get an error like this:
Error dumping user: COM Error: x80004005

Sorry, there's probably some way to check for this and get a better message, but it's not yet obvious. GroupWise API does not supply very good error return values.

NOTE: It seems that we have seen cases where the password is set,but you still get the error dumping out the first time. Upon a second run of the program the new password does allow dumping the data. If this happens to you please tell us.

3. Password supplied

If everyone has the same password, you can run:
SGWTest -pw thepassword

Or you can reset everyone's password and use a new password with:
SGWTest -ps newpassword

This is probably the simplest method (except the Trusted Application) if all users are no longer on GrouWise. But be careful with this.

Usage

The syntax of all the command line flags:

SGWTestUsage: sgwtest -tinstall [keyfile] -tremove [keyfile] (-pt [keyfile] -pf -pfs -pw -ps ) [-nu] [-nc] -help -?

Must be logged into Netware before running

-tinstall Install trusted app, write key to keyfile (default key.dat)
-tremove Remove trusted app

Default operation is extract data, specify one of these authentication methods:
-pt Use trusted app for authentication, key in keyfile (default key.dat)
-pf Use password file
-pfs Use password file and set passwords
-pw Use supplied password for all accounts
-ps Set all passwords to supplied value

Extract options: -nu No user details, just user list (default is to extract all details)
-nc No calendars (default is extract calendars)

-help, -? Print this usage