Ensuring Maximum Stability of Blackberry Enterprise Server

Blackberry Enterprise Server (BES) functionality is highly dependent upon the following:

1 - Exchange being alive
2 - The controlling domain controller (global catalog server) being alive
3 - BES being at the proper service pack level for the Exchange service pack level.

If either Exchange or the controlling domain controller is rebooted, my experience is that it is highly likely that BES will melt down. This could be immediate or over time. I've seen this to be every Blackberry fail and I've seen this be only one or a few fail. BES reboots tend to cure almost every problem. Since BES is more of a forwarder/synchronizer server, you generally don't have to be as focused on when is a good time to reboot BES.  Phones will still work during a BES reboot.   Email and calendar type requests will backup waiting for BES to forward them once it is back on-line.   If a user went to send an email from the blackberry at the exact time the BES server was down, they would get the red "x" message that it couldn't be sent.    If the user clicks resend once the BES server is back up, the previously failed message will then be sent out properly.  

If you are planning to apply an Exchange service pack, you should first check with Research in Motion on what the appropriate BES patch levels are to support that version of Exchange with that service pack.  There was an issue with a recent Exchange 2010 service pack 1 rollup version where Microsoft's first release did bad things to BES.  Microsoft pulled the service pack rollup.  The issue was fixed between Exchange and BES.  Microsoft then re-released it a short time later in its new, improved form that didn't cause BES to meltdown.

The most meaningful thing I have done to maximize BES reliability is to setup a scheduled task on the Exchange server and the controlling domain controller to run on Startup (aka reboot) that automatically, remotely reboots the BES server using the shutdown command each time either of those servers reboot. That seems to keep BES much happier.   The need to occassionally reboot BES separately from Exchange is one reason why I don't like to load BES onto the actual Exchange server.   Rebooting Exchange servers are generally much more painful for most folks to allow without proper planning.   Having BES separate means we can do what needs to be done to get those blackberrys back on-line as quickly as possible.

It is also important to realize the after a BES server reboot it takes about 10 minutes or so after the server is up for the BAS-AS.EXE service to ramp up before BES actually starts flowing email and calendar information again.  Therefore, be patient after a reboot before deciding BES still has problems.

Another tip is you can send an email to a blackberry user from you through Exchange with just <confirm> (with the brackets) in the subject line.  BES will send you a reply once the email got to the blackberry device.  If you see the confirmation, you know that you have fully restored communication from Exchange through the BES server to the actual blackberry.   Another way to see what BES actually thinks is going on is to look in the log file.  The log file will be in a folder such as C:Program FilesResearch In MotionBlackberry Enterprise ServerLogs.  Underneath that folder you will find subfolders based upon dates such as "20110923".   Open up the newest date folder.  In that folder you will find a file called something like BES1_MAGT_01_20110923_0001.txt.    Your log will start with your BES server name.  At the end should be the date  and then 0001, 0002, etc.  Find the most current file that looks like that and open it with Notepad.  Goto to the bottom of the file.  You should see what BES thinks it is doing or not doing.  Remember this is a static file so you will have to close it and re-open it to see changes to the actual file.   An example of my BES log file is below.

Notice we see this user's blackberry communicating back and forth to the BES server.   We also see messages showing that a message has been delivered to the device.

If you have rebooted the Blackberry Enterprise Server and waited for the service to have time to ramp up, and sent your <confirm> test emails without a response, and your log file doesn't say that everything is communicating, then it is time to escalate this to CSI to look at the rest of your Exchange/Blackberry configuration and see what is going on.  If you need assistance, contact CSI and we'll be happy to help.