Recently we observed an issue with Domino Rooms that we migrated to Exchange/Office 365.  In short, appointments contained within cannot be cancelled or re-scheduled and always remain as zombie reservations (unless manually cleaned up).

Coexistence

This is addition to coexistence issues experienced with Rooms.  You have to set Microsoft Rich Text to disabled for the Remote Domain (TNEFEnabled=$False) when emailing Rooms and you have to have an exact match on the Room internet address for it to be processed correctly in Domino.  However, my colleague at a large banking client also experienced issues with Rooms that sent acceptances not being updated in the Outlook calendar item tracking, but much worse, the conflicts and overbooking settings were pretty much ignored.  So if one person books a single instance on a Wednesday at 9am for 1 hour, and a second person books the same Room for f days Mon-Fri in the same week at 9am, the second meeting was, prima face, accepted in Outlook.  On closer inspection the Wednesday booking was STILL held by person one!

Moral of the story, don’t be in Coexistence for too long – migrate as fast as possible.

You can also direct users to book the Room directly in Notes…

Background

In Lotus Notes when you book a Room, it is the Domino Server Add-In Task RnRMGR that manages the interaction between your Calendar and the Resource Reservations Booking System.  In Domino, Rooms are not separate entities in separate Calendar Files like your own Mailfile.  They are actually all bundled up into a central Resource Database.  This Resource Database contains a collection of Rooms, Resources (like projectors etc).  I have even seen Pool Cars in here available for booking – and why not.  This Resource Database also maintains the Site that Rooms/Resources are attached too, like say Building One.  It is common for there to be multiple Resource Databases in a large organisation per country, per region, per city and so on.  All are logical separation and often for delegated administration.

The Room record contains information around booking times and days, capacity, owners, approvers and so on.

In the Domino directory, and to the end user they appear individually of course so when you book one you can pick it from the picker like any other object.

The Domino Directory and the Resource Database need to stay in sync for things like Name, Internet Address, and Capacity.  Again, the RNRMGR and AdminP process manage all of this for you.

Migrations

Rooms are usually the very last thing migrated after users and Mail-In Databases.  You need to be sure no one is left behind on Notes and still using it.

When we migrate a Room, we don’t do the whole Resource Database in one go – there could be 100 rooms / resources inside!.  So, we extract the Room Calendar info out to a standalone Mailfile that has only Calendar information.  That is what is migrated to Exchange/Office 365.  Sounds good right?  Well sort of.

There is a complex set of interactions for Calendaring that includes the relationships between the Chairperson, the Participants and the Resource Database.  As I said this is all managed by the Domino Server Add-In task RnRMGR.  However, because the information is split between the users and the resource database, the Migration tools don’t actually have access to all the information it needs to maintain the correct relationships between the Chairperson and Participants, Rescheduled information and so on.  There is a lot of parent/child document behaviour and there are a lot of fields (attributes0 on a Calendar item that work harmoniously (mostly) with the Notes Client and Domino Server.

Now, because this information is missing only the basics get over to the Room and are no longer tied back to the Chairperson.

The Issue

Cancellations

When a Chairperson cancels a migrated meeting that contains a Room, it is NOT processed by the Exchange / Office 365 booking service.  Whilst the cancellation is received by the participants, and obviously disappears off the Chairperson calendar.

The result is now an orphaned Room booking, and no-one else can book that slot!

Reschedules

When a Chairperson cancels a reschedules a meeting that contains a Room, it is NOT processed by the Exchange / Office 365 booking service.  Whilst the reschedule is received by the participants, and obviously disappears off the Chairperson calendar.

The result is now an orphaned Room booking, and no-one else can book that slot!

Rebooking

When is this an issue?  Well as I said no one else can book that slot, however the chances are that if you work in a large organisation when you go to book a Room at that time and it’s unavailable, you just search for another until you get one.  Or, if there are no Rooms available at that time you just choose another timeslot for a Room that is available.

How did we find this out?

Well, we recently had a client that were living in a merger/acquisition scenario working across companies for a lengthy period of time where one was on Notes and the Other on Exchange.  They had used a “poor man’s” version of Coexistence that was simply not Rich Coexistence at all.  Their advice to their users was “don’t bother rescheduling ever, just always cancel and recreate, otherwise all your meetings will be messed up” – This is of course true for recurring meetings but not necessarily for single meetings.  Anyway, that was their mantra.

Once they had begun migrations, that mindset was carried over to Exchange (until they were completely finished).  So, users that were on Notes cancelled meetings they were going to reschedule and immediately recreated them, only to find that the Room they thought would now be available – wasn’t! It was unlikely anyone had jumped in and stolen the slot form under their nose.  Investigation led us to find this unfortunate bug of Room migrations.

Other Clients

Why has this come to light now and never been raised by other clients? In hindsight, it is unlikely that other clients had noticed this as they were not adopting the cancel and re-create strategy.  I suspect that any reschedules they did would have been correctly processed by users and Rooms for the new slot.

The phantom Rooms, in my experience, are pretty quickly snapped up by opportunist Meeting goers anyway!

Options

Not many, and not all good

Do nothing

Do nothing, users will possibly/probably not notice and will just book another time or Room

Comms:

Send users clear information of expected behaviour and known issues

Gatekeeper

Configure the Room that ALL reservations have to pass through an APPROVER.  Disable auto-processing and have a gate keeper manage all deletions and re-schedules

Transport Rule and Mailtips

Create Transport Rule and Mailtip to notify users of the known issue