[Ice]

I have read that the BES 4 sends out ABP's, I don't know if I have my BES 4 misconfigured or what,but I am not receiving any APB's. I would like to throughly test before moving the Bes4 to a production invironment.

Could someone please explain when and how the APB's are triggered?

Thanks in advance

[DownByLaw123]

I believe that you have to trigger this yourself. CLick on send APB message. You will then see a subject header and message body. YOU type the message and it sends that message to every BB device attached to that BES. For example, you could send an APB saying, "doing maintenance on the Blackberry server tonite, Blackberry's will not receive any new mail from 10PM to midnight", etc... Feel free to correct me if I'm wrong...

[Ice]

From what I have read. After some of the admins upgraded the BES to ver 4, the users started to receive these in the middle of the night. These were not sent manually. There appears to be some bus in BES 4 that sets this off.

I've had my bes 4 running for about 4 days now and have not received anhy of these ABP's.

[jwcanada]

It is true that you can send an APB message to a user from the BES but this is not the issue that everyone talks about. The issue seems to be that random APB msgs go to user at random times....sometimes 50-100 msgs to the same user at the same time. I have found a few things hold true in our environment that can cause this: (We are using BES 4.0.0.18 in production with Domino 6.5.1 and Windows Server 2003)

1) The user's mail file is possibly corrupt...do a fixup on the mail file.
2) When your backups are running (usually in the middle of the night) it could be that this crosses paths with the BES server...if the backup is backing up a certain part of the BES server or mail file of the user and the BES is trying to access that info it could trigger these msgs.

These are the 2 "real" logical things that we have come up with that could be causing these APB's. I am sure others could shed more light on this.

Regardless please call RIM and voice your opinion....the more pressure they are getting on this the more likely they will come out with a hotfix sooner.

[dev]

In my case I installed a BESN4.0 w/HF1&2, on domino 6.5.3. The base OS is W2K3.
It ran well for several days, then APB alerts were sent out around 1:00AM->2:00AM to several users (3 at the time) on the BES. This time coincided with the usual domino tasks that run at that time. They would total aroound 50->70 alerts to each user.
Other instances when they occured, were when the MAGT service was unable to "open" a users mailbox. This is the "scanning for new mail" process that is unable to determne if the user has new messages for redirection.
Unfortunately that can't be filtered (locally or globally), since they are sent to the users' handheld via the PIN#. I've tried (as well as others) the "old" registry fix --DisableFailedNotify=1-- which worked in BESN2.2, but not in this version BESN4.0.
If you haven't seen any at this time then you can consider yourself lucky. But try checking the MAGT, DISP, ROUT and ALRT logs (set log level to at least 3 or higher) for any evidence of this behaviour.

[Ice]

I spoke with RIM tech support about this issue to get some clairifaction on this matter.

RIM supports says the ABP are triggered when there are changes to the mail template file, or durring a database pruning. They reconize this has a problem and have promised to fix in SP2, which does not have a release date.

RIM is no different than any other software compnay, rather than having an inhouse quality assurance program, we the customers have been assigned this role we have become their quality assurance department. The only difference is rather then they paying us, we are paying them.

I think I will take the advise of one of the other admins
(if it anit broke don't try and %&@# with it)
and not upgrade our production BES until later this fall. Hopefully by then they will have the bugs worked out. The executives are always pushing for the latest and greatest, which puts us admins in the line of fire.