aevans's blog

One of our Danish partners, and Novell Sysop, Tommy Mikkelsen sent me a link to a site over the weekend.  It spoke of a Danish effort to consolidate calendars.  It is a long standing effort to allow public sector workers to quickly share calendar information.  The estimates are that it could save up to $10 million per year if every one of Denmark's public sector workers saved just one hour over the year when scheduling meetings.  This puts a real figure on the amount of time and money we all spend when trying to schedule meetings across company boundaries.  I experienced this pain recently trying to set up meetings with three of our partners who where coming into town (actually, it was our admin who experienced all the pain).  What this project does is link calendars in Exchange, Notes and GroupWise into a single central site.  It uses iCal and SOAP to integrate the calendars.

Tommy wrote the GroupWise connector for the project (he's a smart cookie - I have used some of his other projects in other roles).  He didn't mention it but I am assuming that he used the GroupWise 7 SOAP interface.  Now, my Danish is a little rusty so I can't tell you what the project sites say but the source is available out there.

This cross boundary calendaring is a major feature of GroupWise Bonsai, which really validates the goals of the project.  Bonsai will allow users to subscribe to external iCal calendars so that they can view that calendar alongside their own in the client.  Users will also be able to publish their own personal calendars using the Calendar Publishing Host.  The Calendar Publishing Host creates an HTML version of the users' calendar and publishes it to a website that your company hosts.  It also provides an iCal interface to the same data so that external users can subscribe to it. Finally, Bonsai will allow your users to publish their own Free/Busy information, as well as busy search any external users that publish their own Free/Busy information.

One of our Danish partners, and Novell Sysop, Tommy Mikkelsen sent Alex Evans a link to a site recently. It spoke of a Danish effort to consolidate calendars. It is a long standing effort to allow public sector workers to quickly share calendar information.

We all flew back from San Diego last night after GWAVACon finished.  It was a great event, highlighted by Ron's keynote.  GWAVA did an exceptional job and it ran very smoothly.  Richard Bliss gave a great keynote all about owning words.  The 2 NTS guys that we took along were buried with questions the whole time and we had a nice dinner with our customer, Dan, on the last night.

Anyway, this blog entry is about GroupWise CRM integrations.  I will have more to say in this space over the coming months as I am co-presenting with Omni-TS on this subject at Brainshare (if my wife doesn't give birth in the middle that is).  We have been asking around in our channel on what the biggest integration needs are for GroupWise, and the pretty overwhelming response was CRM.   Well, we reckon that has changed, and I can't even say 'of late' - more of this when I get to LinkPoint 360.

Omni have a Riva CRM solution that integrates Salesforce.com, Microsoft CRM and SugarCRM.  Aldo showed it to me at GWAVACon - pretty nice I have to say.  It can either be a desktop sync, or server side, and it's cross platform. It's based on an underlying GW SOAP engine, so adding a new CRM is going to be pretty quick - based on a need more than anything else.  I think he plans to add more CRMs as well as more features as time goes on.  They are in beta right now but keep watching his site for news.

Next - VoiceRD has a SugarCRM integration, as well as some PBX, Asterisk things going on.  It's pretty slick too.  I am struggling to get to the site at this point, but I know they are still around as I talk to them all the time.  It is also based on an underlying GW SOAP engine so will be pretty versatile.

The one that blew us away was LinkPoint 360 from the point of view that none of us had heard of them before.  They had a booth at GWAVACon and they were a new presenter in the GW space, though they have been providing GW/CRM integrations for YEARS!  They integrate though the client C3PO and Object API interfaces, into the 8 biggest CRMs.  When I spoke to them they reckoned that they could add almost any other CRM integration within 3-4 of coding.

So, if you are a GW customer with CRM needs then you really have a lot of choices with some deep integrations into your CRM.  Keep watching this blog as I hope to have some other news really quite soon.

Here we go again. This year some of the Australia territories decided to change the end of their DST periods by one week.  We are currently planning on how we tackle this.  We have 2 basic choices and some variations on the theme - do the same as we did for the US or the same as we did for New Zealand.  To summarize the options that we are looking at:

Option 1

For the recent New Zealand DST changes we worked with OMNI to get a blanket license for their Riva product and a custom build DST module.  This module attached to each mailbox and inserted a search folder with a fixed set of criteria.  Basically it searched for all SENT appointments in the mailbox that fell inside of those extra weeks of DST.  The user could then go to this folder and selectively resend those appointments that needed resending.

There are a couple of modifications that we can make to the query:

Option 2

Same as #1 except it will show both SENT and RECEIVED appointments and users are given instructions to only move the ones they SENT and notify the other senders to resend theirs

Option 3

Same as #1 except if you know that all workstations were patched on the same day that you can give this date as an extra parameter and the search folder will only display appointments SENT or RECEIVED before that date.  This has an additional benefit - as other senders resend their appointments they 'disappear' from the search results.

The downsides of all 3 of these options are the same.

1.  Users need to check ALL the appointments to see if they are accurate

2.  As a sender resends their appointments the search folder will either double up on the sent items, or will not show the newly sent item (for #3)

If we chose one of these options then we will likely do it in GWCheck instead of licensing Omni's RIVA again.  We have enough lead time and a release vehicle in SP3.

Option 4

We do another version of GWCheck, like we did for the US change.  This GWCheck can look at the Timezone definition on any appointment, sent or received.  If the Timezone definition is incorrect then the GWCheck will intelligently move the appointment to the correct time and place a hidden flag on the item.  If the timezone information is missing or correct then the appointment is not moved.  The details escape me on this last point, but those that were not moved had a different hidden flag applied - the part I can't remember was if it was just those that had missing timezone information, or all.

It then created 2 search folders that searched on the hidden flags - one you show users what was moved, and one to show them what was not, so that they could selectively resend them.

The Timezone information is placed on any appointment created with the latest Windows client (6.5.6 and newer I seem to remember), the latest Linux/Mac clients (7.0.2?), WebAccess (possibly also 7.0.2, but it may be 7.0.3) and SOAP clients (7.0.3?).  The prior exceptions, though we should be doing it globally now, was on posted appointments.  So, if your users are using the latest windows client then we can probably intelligently move 80-90% of appointments, if they are working like the rest of us do - so they only need to review 10-20% of their total.

So after having explained all of that I have spoken to a number of customers in Australia and the overwhelming feedback was  to go with one of the first 3 options and not attempt to move any appointments.  The reasons given were that it was less confusing for the users to not have appointments moved for them so that they could be sure that they had checked them all themselves.  It was also felt that most users won't yet have appointments in the problem period and Microsoft released the workstation updates in a patch in December - we are defendant on this patch for the DST calculations.  As this was done quite early if that patch was applied there will be very few problematic appointments.

So my question to the rest of you is if this seems like some reasonable assumptions and if this is the way to go?

I saw this tip on the NGWList from Bob Jonkman. In the past, when I have wanted to decode a Base64 encoded part of a Mime message I have used websites like OpinionatedGeek but I saw a tip from Bob that makes life much easier, and it's able to do a lot more than just decode the text portion of a Mime.  If you save out the Mime.822 with an extension of .b64 you can open it in Winzip to see the content.

So, for example, I had a mail in my mailbox that had a Base64 coded attachment - the attachment was actually a .png.  I saved the Mime and cut out everything from it except the Base64 encoded part, and the begin and end Mime boundaries.  I saved it as mime.b64 and opened it in WinZip - it displays the file in the WinZip interface and I can open it from there.  Pretty cool - I certainly used to have to decode base64 message parts quite often when I was in support.

Earlier this week I blogged on GWAVACon San Diego.  For those of you that didn't already know it's in San Diego at the end of this month (27th to 29th Jan, with a bonus day on the 26th).  What's very exciting is that Ron Hovsepian is delivering the closing keynote, following on from John Dragoon's keynote last year.  Actually, I have no idea how we top this next year, but in the meantime we'll just ride the high.  Ron will be talking about our continued commitment to GroupWise, OES and Teaming+Conferencing.  For the full brief look here.  Latest numbers from Richard Bliss put attendance at a little below 500, so this event is going to be HUGE.  Why don't you be a part of it and see what's going on in the Workgroup Business Unit world.