[DW747]

Hi All (sorry about the length of this post),

I am new here so I hope this is in the right place for this post. I am currently investigating a new problem we are experiencing and although I dont think the BES/BB is the root cause of the problem I want to really rule it out completely.

It would be greatly appreciated if anyone could explain exactly what happens to calendar appointments from the time it is created to the time it is accepted and how it interacts within the BES environment during this time.

The problem is as follows:

User 1 creates meeting sends to three users (all with BB's)
User 1 then changes the meeting and sends the update (note: this is before the others accepted the meeting in the first place)
User 2 then accepts the change and thus the meeting
User 1 makes a further change but now the following message appears:
"The item could not be saved because it has been changed by another person......"

We have now involved Microsoft and they are stumped, or at least they have not given us anything tangible. I intend testing on users without BB's but would like to be armed with some information from the community before I do.

BES is 4.1.4
Exchange is 2003 SP2
Client is O2K3 Pro SP3

Thanks in advance for any help!

[gibson_hg]

I would assume that if the user closes their calendar in Outlook or closes Outlook and then tries again it will work?

Here is how Calendar flow works:

1. User creates appointment in Outlook
2. Exchange notifies BES
3. BES accesses the mailbox using MAPI and CDO
4. Appointment is sent to the BB

It's the same from BB to Outlook pretty much:

1. User creates appointment on the BB
2. BES accesses the users mailbox using MAPI and CDO
3. Appointment is created in the users Calendar in Outlook

If the user only sees this message in Outlook it is because he is looking at it in Outlook and when it reaches the users BB it is then "updated" with a Ref ID or if accpeted by a user then the attendee list is updated. The current appointment being viewed in Outlook is updated but will not allow for accepting/declining/updating until it has been closed and reopened.

You can get around this by not using the Preview Pane in Outlook. Or just let the user know when it happens to close the appointment and try again.

If this is not the issue you are experiencing then explain with more detail.

[DW747]

Hi gibson_hg thanks so much for your reply, that makes everything a lot clearer for me.

In answer to your question yes, if you close the item and open it again after a few seconds it seems to be fine which led me to think that perhaps it has something to do with BES, potentially I suppose it is not entirely impossible for it to be local disk issue however since MS are stumped (and that was fairly easy to do) i wanted to explore other possibilities.

The way you describe how BES handles the Calendar appointments would then suggest that it is not entirely impossible for latency (between when BES takes the appointment and the user makes a change) to be the problem. In any event, since I am able to reproduce fairly regularly I am just going to have to disable a few BES accounts and try to re-create... Not sure what can of worms is bigger though...

Thanks again!

[gibson_hg]

Here is the process for what is occurring right now:

1. User A creates an appointment in Outlook

2. User B accepts the appointment

3. User A is still looking at the appointment prior to User B accepting it and tried to update it

4. User A gets the error message

What happens is that the original appointment is being viewed in Outlook and a change occurs to this appointment that the user does not see. When the user tries to update the appointment he gets a warning saying that it's been updated. Upon closing the appointment and trying it works, this because after closing and reopening he is now looking at the updated appointment.

This is normal behavour and I find it strange that Microsoft does not know about this seeing as I was on a conference call with MIcrisift reps about this in the past. It's funny to talk to people that don't know howtheir own software works.

This usually occurs in the BB world because when the appointment reaches a BB for the first time the BES tags it with a Reference ID on both the BB and Outlook. This inturn updates the appointment but not to the eye of the user. It's the same thing if someone accepts the meeting, the attendee list updates but may not reflect untilt the appointment is closed.

Recreating BES accounts will not fix this, there is no fix that I am aware of. It's typical behavour of Exchange/Outlook but now you have BES in the mix. Your users will just have to live with having to reopen the appointment, not a big deal.

It's not really a latency issue, it just depends on if a user has that particular appointment open prior to the change being made. That's when the issue happens, if the appointment was closed after sending the original request and then opened later to update it should work fine.

Hope this clarifies things more for you.

[DW747]

Just to update you, I have now been doing some extensive testing, but just a correction on the steps you set out above. Once User A has created and sent the appointment it closes down. So the appointment is not open when user B accepts. User A only updates once receiving the 1st acceptance.

In my testing one of the users has a BB account. In that scenario I was able to re-produce each time. I then disable redirection for that user on the BES and I am now no longer able to re-produce the problem. So this leaves me wondering about things like the CDO.dll etc.. do you think that is at all a possibility?

Thanks for your comprehensive answers, I think your tag is absolutely right!

[gibson_hg]

Just verify that cdo.dll is the same version on both the BES and the Exchange server. If the BES is lower then copy the newer cdo.dll to the system32 folder and register it. After registering the file you will want to restart the BlackBerry Dispatcher service. This will cause mail delays for a little while depending on how many users you have so you may want to hold off on that. If you have less then 100 users then you should be fine.

[DW747]

Thanks, I will have a look at CDO's and report back. We have about 1500 users so if I need to restart I will do it out of hours.

[DW747]

Ok, i can now report back. We have 10 mail servers, 9 of them are on the same CDO.dll as the main BES server. We have one development BES server and this has a different version to the Exchange.

With our deployment of O2K3Pro we installed the CDO components for outlook on the client, do you think the CDO.dll file on the client is relevant at all?

In any event I am going to bring all CDO.dll files up to the same version before doing anything else.

[Frank Castle]

I would also check the OS of all the BB's involved.

What is the workflow for this group of users, do they all manage their own calendar or do they have a delegate(s).

If they have a delegate - critical to check "send all meeting requests to my delegate not me" in Outlook. If not they can delete the meeting and over ride anything the delegate has booked / updated.

Also you didn't note but have you applied the MR for BES? Each has had wireless calendar tweaks.

[DW747]

Thanks for that.

Yes, we are generally talking about delegates doing requests however the problem was also re-created without delegates being involved. I will take your advice though and check the setting you suggested thanks.

We have not yet installed any of the MR's so will be doing that shortly. As far as making all CDO's uniform I am in discussion with our dev people to see what impact if any that has on their own code.

Thanks again for the advice!

[gibson_hg]

If the CDO.dll version on your BES does not match the Exchange server then when the BESAdmin attempts to access the mailbox you will get varied results. Sync might work and it might not, some users will be affected but not all. If CDO.dll is not the same as your Exchange then updating it on the BES will not matter to the rest of your environment.

The CDO.dll should be 6.5.7651.1 I think, whatever the version on the Exchange server is you need on the BES. It's a core requirement of the BES to function properly.

Let us know what you find.

[y2kcbr]

Originally Posted by jletendre

If they have a delegate - critical to check "send all meeting requests to my delegate not me" in Outlook. If not they can delete the meeting and over ride anything the delegate has booked / updated.

OMG thanks! This resolved a 3 month old call I had for [Insert Random Department Head Here] who's BB wasnt getting any appointments due to a delegate...

[Frank Castle]

Welcome

Outside of Blackberry / BES the rest of the day is spent resolving Outlook issues, mostly calendar related.

[DW747]

Ok folks,

I can now confirm that all CDO components are in check and correct. I can also now say with absolute certainty that when the BB redirection is turned off the issue will not appear... as soon as it is enabled again the problem comes back. I feel like I am assembling a band with the amount of people I now have on the case. MS/RIM/O2/You friendly folks.

For reference I have also updated our BES server which is 4.1.4 to the latest MR's, unfortunately the issue did not go away although a brand spanking new one appeared which is some C++ error when doing an "update check status" on the BES... the joy.

I will keep digging and update as soon as I get some tangible info from MS.. they have a large number of client logs to work through now too.

[Frank Castle]

By any chance are these reocurring meetings? Can you verify calendar is working and syncing both ways when you create a new meeting?

[DW747]

Originally Posted by jletendre

By any chance are these reocurring meetings? Can you verify calendar is working and syncing both ways when you create a new meeting?

Yep cal synch is working fine both ways and these are all new appointments! MS have now taken a big bunch of logs and ran off into a little hole somewhere.... one can only hope.

[DW747]

For anyone who suffers similar problems but not quite the same, you may find this link useful:

Description of the Outlook 2003 post-Service Pack 3 hotfix package: December 7, 2007

As far as my particular case is concerned... no real progress as yet, we have found some addins in the registry making it possible to re-produce the issue easily when turned on as apposed to off but having said that so does doing the same with BB. Anyway the case has escalated to the MS dev guys now who have sample code and will be taking a closer look at out the Outlook object model deals with these types of addins and perhaps even initiate an urgent product change...

[Highfall]

This issue was first seen in Outlook SP1 and SP2 with BB in the mix. The following 2 hotfixes took care of a majority of the Outlook/BES interaction issues with calendars. They are:

KB883915
KB929884

Unfortunately, it looks like they had SP3 in the testing phase when they came out and forgot to include the fix, so if you upgraded to SP3, it came back up with a vengence. Perhaps the fix that DW747 posted may take care of that with SP3. Will definately be testing!

We have applied all the latest CDO/MAPI fixes to the BES and Exchange, hotfix only open to Platinum users due to be a part of Exchange 2003 SP3, and the above patches, while holding to install Outlook SP3. That coupled with a registry tweak on the AA's PC to make sure deleted items that are deleted from the Exec side go to the Exec's deleted items and not the AA so that the BES processes things more accurately and the result was a majority of our issues went away with calendaring. We are down to 4 issues:

1) Entourage/Outlook/BES all talking to the same mailbox (Exec has a MAC and BB, AA has Outlook). This will never go away. Fight for a standard or to limit varying clients guys/gals. It is worth it if you are looking for accurate calendars. Mixed clients stink for calendaring due to no formal standard. Wish everyone could just get along...

2) The one caused by OWA that impacts Outlook and BB alike. Patches out there for it but forgot the numbers. Shows up in a few ways like ghost meetings only viewable in OWA, meetings that don't sync with the device but look ok otherwise.

3) Recurring meeting too long issue. EXCDO messages seen in Exchange App log. Don't let RIM or MS fool you on this or the other EXCDO errors on the Exchange box. These will result in calendar appointments possibly missing or inaccurate on the device or Outlook. CDOHelper is able to fix some, but not all of these on the device side.

4) Delegates and their Execs both getting the meeting and it sending a Tenative meeting as the delegate to the organizer. That is solved if we send all meetings just to the AA. May try to use the MailProcessDelay registry entry and will let you know results.

It is getting better since MS released SP2 and threw the BES world for a loop. I hope to see it improve...

See you at WES...

[DW747]

Thanks Highfall, some good advice in there. This issue is now 3 months old and we are no nearer to a solution by the looks of it. I do now have quite a good understanding of calendar issues and how it all hangs together as we are now being supported at the top tier of MS who work with the source code. I have learnt that the is error message is caused by a discrepancy in the PR_CHANGE_KEY which is a hidden property on a calendar item. In order to see this key you need a tool called MFCMAPI which you can then use to see all properties of items and then ultimately use to determine if there is a "ghost" process changing the calendar item in the background. We have now figured out that our items change as much as three times without anything being physically done to an item so we are now trying to track down the origin.

I will keep you all informed but thanks again to all for your input, it's all valuable all the time!

[SoUnCool]

thanks guys , you saved my day, I fixed my CIO's problem in 15 minutes, that others were working on for months , long live BBFORUMS