Emails turning to unread when primary cluster server is down (Domino 4.0 SP1 HF1)
Ever since we implemented 4.0 on a test IT server, I have seen some people's BB unread marks go from none to the hundred's overnight. From examining the logs, I discovered that the unread marks sync for these people was occuring during the same time window when our primary Domino mail server was down for the nightly maintenance reboot (~4:00AM - 4:15AM). Since the unread marks sync only happens occasionally, only a few users would be affected each night, not all of them.
I figured it was because the Domino clustering was broken, so I waited for the SP1 HF1 to fix that, which I thought would fix the "unread marks reappearing on primary cluster server down" issue. Well, it hasn't.
Turns out that we don't have unread marks synchronizing between cluster replicas on the Domino side, so I went through everyone on the 4.0 BES and set this database property to "enabled".
Thought this would fix it, however I just got another call about this happening! Any ideas on this from any other Domino BES admins out there? This is driving me crazy and I can't go into production without figuring this out!
Did you also make the change under the "Advanced" tab in the section under "Replicate Options"..?
Here are the settings, are there any I am missing? (See attached jpeg screenshots)
Replicate Unread Marks: Clustered Servers Only
Are you running a mixed environment? Are there users on the R5 mail template and some on the R6 mail template?
The R5 template has the cache local to the client...therefore F9 is key is integral. For the R6, the cache is on the server side and hence unread marks are updated on the server side. I'm assuming you also made the change under the "Design" tab where it says "Do not mark modified documents as unread"...
Just remember cluster replication over-rides any selective replication that you may setup (first pic). The second pic seems ok....
We are all at the R6.02CF1 mailfile design, all on R6 servers. I have not made the "Design" tab change where it says "Do not mark modified documents as unread", can you explain what this means and why it needs to be enabled? I never got a good grasp on it from reading the help. Thanks!
Just chiming in that we're having the same problem too, but only with 3-4 users out of around 110 or so. (knock on wood)
Primary Domino server = AS/400, secondary = Windows 2003.
Although I do most of the BES stuff, I have little to do with the Domino side, so I'll see if I can get our Domino admin into this forum...
The following links may prove more beneficial then my explainations......here goes
we have exact the same issue on Domino 6.5.4 (clustered). replicate unread marks is enabled and usually the read/unread status is updated correctly. It only goes wrong when one of the 2 mailservers does down for work/full backup. We reported this to RIM, here is the answer:
This issue has been investigated by our Software Development Team and they
have now created SDR68366 to further investigate and resolve this issue.
The following update was received:
In speaking with Lotus, they indicate for the most part it should work with
the data available in their technotes, however, for us to fully address it,
we would need to use a new APIcall that is not available until 6.5.3. That
would mean for us to be able to use it, the BlackBerry Enterprise Server
would need code changes as well as run on a 6.5.3 or later server. They have also indicated that the BlackBerry Enterprise Server updates the
unread table, rather than the activity log.
Currently the fix for this SDR is scheduled to be fixed in
Release 4.1.1. of the Domino BlackBerry Enterprise Server. As yet we have
no definite time frame for when 4.1.1 will be released. Hopefully we are
looking towards early / mid 2006.
I was the original poster. We modified all our mail databases so that unread marks are replicated to all replicas, but that doesn't immediately fix the issue because OLD messages are not synced, only NEW messages after the change. As times goes on this became less and less of an issue and it all works great now. I don't think you need to wait for the fix above from RIM because we don't have it and it is all OK.
Same problem here 5 or 6 users out of 160 - never got round to finding out what the problem was but now all this has come up will give it a read
|All times are GMT -5. The time now is 12:29 PM.|
Powered by vBulletin® Version 3.6.12
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.