This AM(X) is based upon the ' Neverfail for BlackBerry Enterprise Server - Application Module - Feature List ' product with one or two significant differences, which are described below.
Currently all Neverfail for BlackBerry solutions provide fast switchover/failover times for all deployments. However, when Neverfail for BlackBerry Enterprise Server is deployed in some Enterprise size sites, delays in message delivery may occur for some users. This is primarily due to the architectural design of the BES solution:
- When the BlackBerry Enterprise Server starts up, several services start that scan all BlackBerry enabled user mailboxes for new mail messages.
- Up to Blackberry Enterprise Server 4.0 Sp3 and 4.1, only a single thread was responsible for initializing all mailboxes.
- As of BlackBerry Server versions 4.0 SP4 and 4.1 SP1, RIM introduced a multi-threaded model to reduce scanning times but there are several factors, which can influence this, particularly in Enterprise scale deployments.
- For further information please consult BlackBerry Technical Solution Center Doc ID: KB04789: 'Restarting the BlackBerry Enterprise Server services may cause delays in message delivery'.
Neverfail for BlackBerry Enterprise Server has been successfully deployed without experiencing these issues at sites hosting in excess of 600 users. However, as the number of supported users approaches 1000 users, some systems have been known to take up to 45 minutes to scan all the mailboxes. Until a user's mailbox has been scanned, they will not receive email to their handheld device. Although this problem has been known to occur with or without the presence of Neverfail for BlackBerry Enterprise Server, this version of the AM(X) addresses this specific issue.
- Do not configure Management IP addresses on the server
- Do not use with a local SQL server
Applicable to BlackBerry Enterprise Server Versions
This Neverfail solution is only applicable to the following deployments of BlackBerry Enterprise Server for Microsoft Exchange or Lotus Domino.
BlackBerry Enterprise Server:
- Greater than or equal to 4.0 SP4 (4.0.4)
- Greater than or equal to 4.1 SP1 (4.1.1)
Service Packs or Versions prior to these versions must be upgraded to these as a minimum in order to take advantage of the multi-threading.
Recommendation for Lotus Domino Deployments
If Lotus Domino is not configured to use Transaction Logging it will perform consistency checks after recovering from a crash. The consistency check will prevent BlackBerry Enterprise Server from accessing the user mailboxes and delay message delivery further. Please refer to Knowledgebase article #1312 - 'Transactional Logs For Lotus Domino Are Not Protected By Default - A File Filter Can Be Added' for advice on how to configure Domino Transaction Logging and the appropriate file filters.
Standard Implementation of Neverfail for BlackBerry Enterprise Solution
All versions of Neverfail for BlackBerry Enterprise Server are implemented in the following way. For further details, please consult Knowledgebase article #642 - 'Neverfail for BlackBerry Enterprise Server - Application Module - Feature List'.
- Sets all services to manual on both servers.
- Replicate BlackBerry log files.
- Starts all protected services as the active server starts up.
- Stops all protected services during a switchover/failover to the passive server.
- Starts all protected services on the new active server during a switchover/failover; this introduces the message delivery delay.
- The server_CMNG_01_date.txt log records the initialization of the users.
- This log is generated by the BlackBerry Synchronization Service.
- The state of individual devices is stored in the configuration database.
- Remote databases will not be affected.
- Proposed 'No Message Delay' implementation presented to RIM's technical team.
'No Message Delay' Implementation
- Leaves the BlackBerry Controller, Dispatcher, and Synchronization Services as 'Automatic' on both servers.
- No longer replicates the BlackBerry support log files; because these are in use on the passive server.
- Passive Server is still hidden from the Network.
- The Controller, Dispatcher, and Synchronization Services are not stopped during a switchover or failover.
- Service starts are no longer sent to the Controller, Dispatcher, and Synchronization Services as part of the switchover or failover process when the newly active server starts up; this is done to avoid mailbox scanning.
Note: This solution will not reduce messaging delay caused by Lotus Domino databases if a consistency check occurs after a failover. Switchover and auto-switchover times are not affected.
Note: Users reporting problems after a switchover/failover event should be advised to perform reconciliation.
Exception: Please note this solution does not currently apply to deployments where the configuration database is local. This is due to the service dependencies that are created between BlackBerry Enterprise Server services and SQL Server services. These dependencies do not exist when the database is on a remote server. A future version of this AMX could be provided that extends support to cover local database deployments but is not available at this time. Installing this module with a local database would result in SQL Services starting on the passive server, resulting in apply exceptions.
RIM's plans for their Argon release of BlackBerry Enterprise Server sounds promising for our solution because it is in keeping with our proposal:
Argon running on a Cluster will involve leaving the services running on the passive cluster node.
Neverfail for BlackBerry Enterprise Server 2007-05-23 32 bit