Enterprise Messaging Notes

Recent efforts here to troubleshoot a unique issue with a user's Blackberry calendar edits made on the device, has flushed out a rather useful field in the mail file that will allow you to track changes to calendar and scheduling involving the BES and device, called "RIMCSTRACK".  This field seems to contain information on the past 3 changes to any calendar entry involving the device, and pending some specific feedback from IBM on exactly how that field is populated, and how the data in it is rotated (if it is), it can help greatly in associating what may have happened to a given calendar entry, when, and from where it may have been updated (device or server).  The field also contains an identifier, called "refid", that can be used to match the events in the mail file, to the BES messaging agent data contained in the "MAGT" log files, to reconstruct timelines and to determine where things may have gone awry.

 

In a manner of speaking, once a calendar edit involving the handheld/BES has been "committed" to the mail file on the domino, this field then appears in the mail file, and it shows the date, time and direction of when this edit occurred, so in our case, edits that never seem to make it to the mail file from the device for some unknown reason (the problem we are chasing with RIM and IBM), can be either confirmed or refuted as committed on the domino side, by examining the contents of this field.  (If the calendar entry has never involved BB/BES etc, this field is not present for that calendar doc).   It can be used in a view as well, and by adding this field to the "all calendar entries docs" view, (and adding that custom view to a user's mail file with an issue) can provide a nice quick troubleshooting mechanism to identify which calendar docs involved the Blackberry, and to determine what may have happened, as well as providing an export capability to use to match to the BES logs using the refid key.   This data will also show slow sync's, state database record creations, and other elements that may mean more to a person more familiar (than I) with the BES realm.

 

The example below shows that field's makeup, as well as the tracking of multiple changes to a test calendar document that I made from my device, while trying to reproduce the problem.  It appears that the "sending update" event is the BES sending the calendar entry down to the device, (server to client), and the other 3 "received update from device" are updates made from the device.  Upon export, this data is all appended together, (21/12/2009 20:02:54 refid-821122648: Sending update,21/12/2009 20:05:30 refid-821122648: Received update from device,21/12/2009 20:08:12 refid-821122648: Received update from device) without a consistent delimiter, so it takes a bit of work to parse out the data to one value per subfield of the entries (rimcstrack_date1, rimcstrack_time1, refid1,actiontaken1, etc)  for readability and matching the refid to BES logs, but once broken out it and easier to read (or match) it can start to tell a story about the timeline of changes, and from which direction they happened.

 

Field Name: RIMCSTrack

Data Type: Text List

Data Length: 253 bytes

Seq Num: 6

Dup Item ID: 0

Field Flags: SUMMARY

 

"21/12/2009 20:02:54 refid-821122648: Sending update"

"21/12/2009 20:05:30 refid-821122648: Received update from device"

"21/12/2009 20:08:12 refid-821122648: Received update from device"

"21/12/2009 20:10:51 refid-821122648: Received update from device"

 

It has allowed us to determine if a calendar doc edited on the Blackberry was ever committed to the Domino (by looking at this field alone and comparing timelines to the times when updates failed), and by joining this to the BES messaging agent logs (which also use the same refid key), we can identify all the activity relative to the attempted edit on that specific day, that may or may not have made it to the user's mail file, and get some inkling as to why this may have occurred based on the errors in the BES logs.

 

What we found appears to be an abnormal sequence of "rejected" device-side calendar updates in the BES logs, that for some reason (RIM is evaluating and trying to reproduce a possible bug) were never apparently committed to Domino, some of which were rejected for "conflicts", and others that were strangely rejected because "update not valid, newer update already received", despite no updates occurring from any direction for months prior in some cases.  We continue to work with IBM and RIM to understand this issue better, and to understand exactly how this field behaves on the Domino side, and hopefully get some kind of fix.

 

Hope this may help you if you find yourself troubleshooting odd issues with calendar entries and the BES/BB, it has certainly helped us in the past couple weeks.  The interaction between BES and Domino can fall into the fingerpointing realm between the 2 vendors, and this field seems to have helped lay things out in a manner which should help us, and the vendors, reconstruct what may have happened.

 

 

 

 

 

 

Looking to correspond with anyone who has had experience with the Kazeon legal case management tool running against a Domino messaging environment.  EMC recently purchased Kazeon, which was previously privately held.  Although not an archive solution, Kazeon's niche is to assist the legal teams with the onerous task of search and extraction aspects of legal case management, to offset the sizable workload involved with the Federal Rules for Civil Procedure.  It can handle at least email, pc files, file shares and sharepoint data sources.  We're looking to do an eval of the product including a sizing/pricing exercise and possibly a proof of concept test, and the email interaction aspect is key, given the lions share of ediscovery involves email.

Curious to know how this works in a proactive ("index now extract later") mode or reactive mode ("index and extract data case by case") while running against production Domino mail environment, and any other tips, hints or gotcha's anyone would be willing to share about this.   Happy to discuss here, offline from here, via phone, anything you may be comfortable with.

Thanks in advance.

Curious to know if anyone has any experience and feedback on the newer Notes Multilingual User Interface (MUI), and can share any tips, tricks or gotchas on that. We are exploring the use mainly for use with Windows 7 where such a capability exists on the o/s.

Thanks in advance for anything you may be able to share.

Dan