I have been lucky enough to be using the BlackBerry Enterprise Server 5.0 software for the past few months. It introduces several new improvements to the architecture of the BlackBerry domain, the most sought after being support for out of the box high availability. It was code named Argon, a stable gas, due to its promised reliability and solid performance. Below are some thoughts and findings that I made during my use of the software within my test environment. Screenshots are available towards the bottom.
A big thanks to Lee Williams from Gen-i for giving me the time and resources to familiarize myself with BES 5.0, enabling me to complete this article.
If you have any questions please let me know in the comments and I will get back to you promptly.
1. New Improvements and Features
The first change you will notice is the introduction BlackBerry Administration service. It replaces BlackBerry manager and is completely web based. It takes a while to get used to for every day tasks. It can feel a little cramped when attempting to select multiple users who don’t share the same group, IT policy, software configuration or otherwise. Yet after working with the interface for some time you do get used to it.
There is an API available for developers to write plugins for the BlackBerry Administration Service, so it will be relatively easy to introduce new functionality into the environment.
One of the best improvements in BES 5.0 is the more granular level of control admins have for role based administrator user accounts. You can add users to these groups, apply multiple groups to roles, and have multiple roles apply to a single user. Additionally, you can prevent certain users or groups from performing any changes on other certain users or groups. For example, in a 24×7 helpdesk scenario, you may not want to let the CEO’s account be accessed by anyone other than a few select users.
Users can also belong to multiple IT policies. This is quite cool, however, the order of IT policies are applied in a hierarchal, consecutive order. IT policies are not combined.
A feature that is well and truly overdue is the ability to whitelist applications. Finally! Default permissions can also be set for unknown applications. Additionally, the BlackBerry Administration Service downloads nightly builds of the device.xml file straight from RIM, so you don’t need to worry about updating to the latest version. Oh, one more cool addition to application deployment is adding your alx/cod files to the appropriate directory, you don’t need to prepare them for deployment by running the loader.exe /index command. This is now done automatically by the BlackBerry Administration Service, as it monitors the appropriate folders.
For those of you with high load SQL environments, you can now limit concurrent tasks by throttling transactions across the BlackBerry domain, not just per BES. This would be helpful when changing a setting within an IT policy applied to thousands of users, to limit the huge increase of I/O on your database.
Another extremely cool introduction is the Enterprise Transporter. This is used to move users between BlackBerry domains. Basically, you use this as a bridge between two BESMgmt databases that you authenticate against. Works with 4.0 SP7 and 4.1 SP6. In my lab environment, I used this and it was fairly simple to figure out, and I didn’t really have any problems. However, I definitely recommend careful consideration and planning when implementing this in a production environment – at the very least, a pilot program is a must.
2. High Availability
High availability has been available for BES Admins for some time now, through various third parties such as Neverfail and Doubletake. With BES 5.0, high availability can be enabled out of the box, for free. There is no additional cost per BlackBerry server.
There is an excellent document available called the BlackBerry Enterprise Server Planning Guide. This document goes into depth about the different features of High Availability. It’s a great read and provides some thorough insight into how the technology works. I have summarised the high availability options for the more common options here.
BlackBerry Enterprise Server
HA within BES has been designed so that even if the primary server fails, there is minimum downtime for end user’s message and data flow. High availability works by installing two BlackBerry Enterprise Server instances on two different computers.
The Secondary BlackBerry Enterprise Server tries to periodically connect to the Primary BlackBerry Enterprise server to perform health checks. These health checks are highly customisable (see the planning document for more information). If the Secondary BlackBerry Enterprise Server finds that a threshold is not met, it will try to raise its status to take over messaging duties.
Please note that for smaller environments, it is absolutely fine for you to install all of the below components on two separate boxes. You do not need to split out each service to it’s own separate box. You can also customise multiple broken out services on a single box (this is good and overdue).
BlackBerry Administration Service
The two main ways you can achieve high availability on your BlackBerry Administration Service – using a hardware network load balancer, or simply using DNS round robin.
Actually, a colleague of mine pointed out to me that HA for this component may be a little overkill for some organisations. During setup, you are asked to enter the high availability DNS pool name. But there’s nothing stopping you from using a different one for each installation, and give people two links to use and say “If this doesn’t work, use this one instead”. Most helpdesk staff should be able to handle this.
BlackBerry Attachment Service
This is not like your ordinary HA scenario, because the attachment service has some nice built in load balancing as well. This gets a little confusing so try and bear with me.
You can configure one or more pools, each with a primary group consisting of two or more Attachment server instances, and an optional secondary group with two or more Attachment server instances, for each BlackBerry Enterprise Server.
So, instead of having one attachment service doing all the work and another just sitting by waiting for it to fail, you can split this out by creating a pool. Within this pool, there is primary group, consisting of two or more attachment service instances.
You can leave it at this if you like – there is no requirement to add anything else. However, you have the option of creating another Secondary group with two or more attachment service instances in it as well.
You can set each instance to process only specific types of attachments. If an attachment cannot be processed in the primary group, it is passed to the secondary group.
BlackBerry Configuration Database
Can be achieved using database mirroring with SQL 2005 SP2. If the principal database fails, the BlackBerry Enterprise Server attempts to connect to the mirrored instance.
High Availability can be achieved for the following additional services.
* BlackBerry Collaboration Service
* BlackBerry MDS Connection Service
* BlackBerry MDS Integration Service
* BlackBerry Monitoring (manual only)
* BlackBerry Router
Please see the BlackBerry Enterprise Server Planning Guide for more information on these services.
(This article was republished with the permission of the author, Brendan Zivcic)