BlackBerry Enterprise Server 4.0

Research In Motion's (RIM's) ubiquitous BlackBerry services, devices, and applications are a popular means of accessing enterprise data, particularly email and Internet resources (though the product line has evolved to allow access to intranet resources and databases). The recent introduction of BlackBerry Enterprise Server (BES) 4.0 increases the solution's power and makes it easy to understand why the BlackBerry is such a perpetual favorite. If you're considering an upgrade (or a new deployment), you'll be interested in the changes in server architecture and the interesting new capabilities that BES 4.0 brings to the table.

Infrastructure
Over the years, RIM has significantly changed how BES provides services. BES 2.x could support between 500 and 800 BlackBerry handhelds per server and used one service to redirect mail data between those handhelds and an Exchange Server. BES 3.5 increased the product's hosting power to 2000 mailboxes per physical BES server by installing as many as four virtual BES server instances, each with its own Server Routing Protocol—SRP—Additional Service Key (i.e., license key). BES 4.0 still supports 2000 mailboxes per server but moves back to a single-configuration/single-key model.

BES 4.0 is made up of nine components, implemented as eight services and a series of Agent processes spawned by those services (as Figure 1 shows). Another significant change in the architecture involves the storage location for BES configuration and operational data. Let's take a look at how BES puts these pieces together.

BlackBerry Dispatcher Service. Known as the Redirector Service in earlier BES incarnations, the BlackBerry Dispatcher Service performs data encryption, decryption, compression, and decompression functions for all data that the BES sends or receives. The Dispatcher Service spawns one or more Agent processes, which perform the Messaging API (MAPI) operations necessary to communicate with users' Exchange mailboxes. When an Agent receives a command to display an attached document, it uses an attachment connector to pass the request to the BlackBerry Attachment Service.

BlackBerry Attachment Service. The BlackBerry Attachment Service is responsible for opening and converting attachments' contents to a format that can be read on BlackBerry handhelds. The service generally converts attachments (e.g., Microsoft Word documents, ASCII files) to plaintext, but the service is device-aware and so will include content such as special fonts and graphics if the receiving handheld can display them. RIM refers to the Attachment Service as a remote component because you don't have to load it on the same server as the Dispatcher Service (although you can do so). Indeed, any but small deployments (i.e., 200 or less users) should load the Attachment Service on a separate server. The BlackBerry solution uses MAPI to access Exchange, and MAPI is a memory hog. Attachment conversion can also be memory intensive, so you'll generally get better overall performance by placing the Dispatcher Service and Attachment Service on different hardware. In my experience, most users only occasionally view attachments on the BlackBerry, so I usually start by putting the Attachment Service on the same Microsoft SQL Server system that hosts the BES management database (which I'll discuss when I explain the BES storage changes). If the SQL Server database and the Attachment Service become too competitive over the use of system resources—as measured by slow response and CPU at 75 percent or more most of the time—you can easily move the Attachment Service to a new platform.

BlackBerry Mobile Data Service. The BlackBerry Mobile Data Service (MDS) provides access to data on the corporate intranet or the Internet. When a user wants to access a Web site via a handheld device, the MDS acts as a browser proxy, accessing the site on the handheld's behalf. Like the Attachment Service, the MDS is device-aware and will transmit information in a display format that's relevant to the requesting device. On Java-enabled devices, the MDS will also transmit JavaScript 1.3­compatible code included in Web pages; this capability supports Web forms that use Java to run presubmission information checking. I've found that this BES 4.0 feature lets me access many (though not all) Web sites that I couldn't before the upgrade.

BlackBerry Policy Service. The new BlackBerry Policy Service ensures that software and settings are properly deployed to handhelds. For example, suppose you define a BlackBerry policy that requires an 8-character password and a maximum 20-minute inactivity timeout. The Policy Service transmits those settings to the handhelds and keeps track of which handhelds have received and implemented the policy. The service is also responsible for sending administrative commands—such as those that lock and kill a handheld or that reset a device password—and for handling the delivery of third-party applications that you push out to handhelds.

BlackBerry Synchronization Service. Another new service is the BlackBerry Synchronization Service. In addition to wirelessly synchronizing email and calendars, BES can now wirelessly synchronize Contacts, Note, and Task data between handhelds and the mail server. The Synchronization Service also performs automatic wireless backups of handheld data and user-specific settings (e.g., browser bookmarks, email filters or searches, autotext settings, profile options). This addition is a huge advantage because these settings are restored automatically if a user receives a new handheld. When the device is activated and provisioned, any backed-up settings that are applicable to the new device are restored.

BlackBerry Router Service. The third new service in BES 4.0 is the BlackBerry Router Service, which detects when a handheld is connected via a physical cable and BlackBerry Desktop Software. When a handheld is cable-connected, the BlackBerry Router Service sends all communications over the wired connection instead of over the wireless network. Like the Attachment Service, the Router Service is a remote component and can be installed on a separate server from the Dispatcher Service. The main reason to move the Router Service to a separate server is so that multiple BES servers can share one router, as Figure 2 shows. This capability minimizes the number of servers that need to access the RIM network through your firewall. However, I don't typically separate the Router Service and the Dispatcher Service because doing so creates a single point of failure, and the Router Service doesn't incur an extreme load on system resources.

BlackBerry Alert Service. The BlackBerry Alert Service remains unchanged from earlier BES versions. The Alert Service's primary function is to provide a way to keep administrators and monitoring systems appraised of what's happening on the BES. For example, the Alert Service can send you an SMTP message when a BES service generates an application error in the Windows event log.

BlackBerry Controller Service. The BlackBerry Controller Service, which was introduced in BES 3.6, monitors the Dispatcher Service and its Agent processes. Because these processes interact with MAPI, they're the most susceptible to outside situations that can cause deadlock or process failures. When the Controller Service detects that an Agent or the Dispatcher Service has terminated or hung, it automatically restarts the process or service. You can test this function in a test environment by using the Kill command (from the Microsoft Windows resource kits) to kill one of the BlackBerry Agent processes; the Controller Service will start a new Agent almost immediately. (The service resuscitates only the Dispatcher Service and Agents, so I recommend that you use some other monitoring package to keep track of the other services.)

Storage. Earlier BES versions took a hybrid approach to storage, using the BESAdmin mailbox on Exchange to store configuration information and a Microsoft SQL Server Desktop Engine (MSDE) or SQL Server­based management database to store license keys and transient information (e.g., queued messages) for delivery. BES 4.0 uses the management database to store all configuration, licensing, and operational data. The BESAdmin mailbox is still necessary but is used mainly to provide an interface to Exchange so that BES can perform directory lookups and initial authentication. This new reliance on an external database makes it vital that you regularly back up the database and understand how to restore the backup. I generally recommend that you use SQL Server instead of MSDE for BES 4.0 deployments. SQL Server provides better performance, a more robust environment (letting you cluster the database to provide fault tolerance), and many more backup and restore features.

Another consideration in regards to database use is security. Earlier BES versions stored a user's individualized encryption key only in the user's mailbox and on the user's handheld device. Now, BES also stores a copy of the encryption key in the management database. Although the BlackBerry solution's method of using encryption keys still makes it difficult for a third party to make use of the keys, in security-conscious environments you might need to limit access to the SQL Server that holds the management database.

Evolution
One thing I like about RIM is that it doesn't leave its old handhelds behind. Rather than sunset older devices, the company updates its handheld OS and applications so that most new server features are available on all handhelds. RIM's more recent handheld devices are Java-based; the older RIM 950 and RIM 850 series handhelds use C++, which prevents inclusion of all newer features. (For example, new wireless-provisioning capability is available on C++ devices, but JavaScript support isn't.) The minimum upgrade version needed to use the feature set from BES 4.0 is BlackBerry Handheld Software 2.7 for C++ devices or BlackBerry Handheld Software 4.0 for Java devices. To determine which features will work on particular handhelds, read RIM's whitepaper "BlackBerry Enterprise Server for Microsoft Exchange Version 4.0 Technical Overview" (http://tinyurl.com/bqslc).

To take advantage of the full set of new features, then, you'll need to upgrade not only BES, but also the handheld OS. You can get an upgrade for C++ devices from the BlackBerry support Web site (http://www.black
berry.com/support). For Java devices, you'll need device-specific versions that depend on the wireless carrier that provides your connectivity. Each carrier tailors the device to match the settings and features of the carrier's network. For example, Cingular Wireless will provision a BlackBerry 6210 handheld with software that lets the device's phone portion work on the Cingular network and with Cingular gateways. A T-Mobile­specific BlackBerry OS won't work on a Cingular BlackBerry even though both carriers supports the BlackBerry 6210.

So what is this new functionality I keep talking about? After you upgrade both the handheld and BES software, you'll get full wireless personal information manager (PIM) synchronization and the ability to configure redirection filters directly from the handheld. Users can specify an Out of Office message and turn Out of Office Notifications on and off from the handheld—no Outlook required! Applications that were already enabled for wireless access, such as the Calendar, have been enhanced so that users can accept or reject meeting requests with comments or tentatively accept invitations, and email now completely synchronizes with the Sent Items folder as well as the Inbox. For example, when a user sends a message from within Outlook, BES will detect the message and send a truncated copy of the message to the handheld device, which will show a sent item with a check mark just as if the user had sent the message from the BlackBerry device. The user can use the more function to retrieve the full message later.

Perhaps the most exciting new feature is BES 4.0's wireless-provisioning capability. If you need a reason to upgrade, this is the one. Because of the new version's enhanced wireless capabilities, users will rarely need to run the Handheld Manager software (previously known as Desktop Manager). You'll still need Handheld Manager to reload or upgrade the OS or radio software—for example, entering a wrong password 10 times wipes the handheld device's memory, requiring a cradle-connected, Handheld Manager­driven reload. But in most cases, you can now wirelessly provision applications and data. Wireless provisioning opens up new possibilities for both upgrading and replacing handhelds on demand as well as getting new users up and running quickly. A prime real-life example that I've witnessed is using wireless provisioning to keep users connected during a migration from Exchange Server 5.5 to Exchange Server 2003. The new Exchange organization was completely separate from the old, and so the BlackBerry servers needed to be separate too. Most of the migrations took place over a weekend; without wireless provisioning, many users would have had to wait until the following Monday to reestablish BlackBerry service by reconnecting their handhelds to their PCs using a cradle or USB connection.

RIM also provides a tool called the BlackBerry Handheld Configuration Tool, which lets you configure many handheld devices at one time. This tool is mainly intended for use in equipment configuration and distribution centers. For example, if you purchase and deploy 50 BlackBerry devices or redistribute 20 devices, you can simultaneously connect 10 handhelds to one system, then use the BlackBerry Handheld Configuration Tool to wipe, load, and preconfigure the devices in bulk. You can then distribute the handhelds to end users and wirelessly perform any customizations that the users need.

Stay Tuned for Tips and Tricks
I've only scratched the surface of BES 4.0's new features and components. In the coming issues, I'll give you some tips for upgrading and some tricks that I use to keep my BES 4.0 environment running smoothly.