Calendar debugging question

I have posted this at crackberry, as I think this is mainly a BB issue, but hoping someone here can help too.

We are having periodic issues with calendar entries being properly processed between Notes and a Blackberry Bold that has moved beyond annoying, and is becoming a problem for one of our execs.

This person lives on her blackberry, and the calendar. If something is not on the calendar, she will forgot she has scheduled or accepted a meeting, even if she did it just 10 minutes before. She has missed some rather important meetings because an entry is not being displayed on one of the systems.

She will accept a meeting invite, mostly a reschedule, cancelation or a re-invite to a meeting she previously declined. And it will be added to the only one of her calendars (Notes or Blackberry) – and not always from the system she accepted the meeting from.

Whenever we can get her bb from her to test it, we cannot replicate the problem in any fashion using new meeting requests. So, at this point, I am split on possibilities – user error (she types on the bb faster than a teenager can text) or problems with the specific meeting documents.

Unless we can verify that it is the documents, it will be unlikely she will accept the idea that all future meetings will need to be deleted and re-created. The same with user errors, how can we prove it is something she is doing?

Right now, both our Domino and BPS server are set to normal debug levels – and we are seeing no errors. What I would like to be able to see in detail is WHEN she opened and accepted/declined a meeting, from WHICH device (Notes/bb) and if there is any issues with the meeting documents. If she is getting errors only when she processes meetings on the bb, how is she doing it? Is this level of logging possible, and if so how do I turn it on?

Any other ideas?

Other users have had an issue or two with a meeting not replicating from the phone back to notes, but these have been rare per user, and easily dismissible as a fluke.

A few details which may or may not be playing a part in this

Our environment:

Domino 8.5.1 FP2

BPS 4.1.4.17

BB Bold 9630

BB Curves 8520

BB Policy is the default policy settings

  • Most, but not all, of the errors are occurring from rescheduled reoccurring meetings. In some cases she is the chair, in others not.

  • The reoccurring meetings are scheduled 1 year out

  • The exec in question is on Notes 8.5, using the Mail85Standard template

  • The person she has the most problems with calendar issues is on Notes 7, using the iNotes6 template

  • Both mail files are on the Domino 8.5.1 server.

  • The exec has several location documents in Notes to change her Internet email address on outbound emails. The portion that specifies her Notes mail locations and details are the same in all locations.

  • Would this come into play in processing meetings? If so, wouldn’t we see a lot of dead mail?

Subject: Found sequence that causes the error, is this Notes or Blackberry

  1. If a bb user is removed from a meeting as an invitee, the calendar entry on the bb is removed even if the cancel notice is ever opened.

If the person is then re-added as an invitee and she receives a new meeting invite and accepts it, the calendar entry is displayed on the notes calendar but never returns to the blackberry.

If the cancel notice is opened on the bb, it is not processed at all in Notes. The original meeting is left on the Notes calendar.

  1. If a person declines a meeting invite because the time does not work, the person never receives any future reschedules of that meeting. We have this setting defaulted to always receive future updates in Notes.

Subject: Some thoughts

Matt,I will bring these forward to see if they are known issues with RIM - they sound familiar offhand but some colleagues are more likely to match them.

As far as how to tell if RIM or Domino is modifying the meetings, the best and easiest way is probably to look at $CSTrack and RIMCSTrack items on the meetings. If they do not show in your calendar view, you can probably find the entries in the calendar list views and check from there. Typically these sort of problems are due to modifications from blackberry (even if the user itself never modified the meeting it can still send changes back to Domino).

Thanks

Nate

Subject: What does this tell us?

I want one of our developers to create a view that we can look at all the calendar entries, along with these fields per entry.

What exactly will these fields be telling us?

I have opened a request ticket with RIM, and they, as any software company, are “wondering aloud” if this is a Notes issue. With these fields give me any information I can take to them?

Thanks

Unrelated - I was looking to see what the future of BPS on Domino is (BPS for Exchange has been replaced by BESX) and I stumbled across a few posts that said RIM & IBM get along as well as Apple & Adobe and that is why BESX for Domino has not been released? This is the first I’ve heard of this. Any truth behind those accusations?

Subject: RE: What these fields tell us

I can tell you that my team works very closely with RIM, as we are in regular contact with them on development, support, and testing levels as well as with executives. Both IBM and RIM are working to prevent, diagnosis, and close any issues. Your issue will be discussed in that forum unless we find an existing match first.

As far as what these fields tell us, they are intended to provide a history of who modified the meeting and for what purpose (processing an acceptance, creating an exception, etc). $CSTrack tracks changes made by Notes/Domino and RIMCSTrack tracks changes originating from the blackberry device or server.