If your Exchange Server users are Research In Motion (RIM) BlackBerry addicts, as mine are, you'll want to know about the many new and enhanced features in the most recent BlackBerry Enterprise Server (BES) for Microsoft Exchange versions: 3.6 and 3.5. These features improve the scalability, security, and usability of the end-to-end BlackBerry solution if you use them to their full advantage.
One change in BES 3.6 and BES 3.5 is that these versions let you create as many as four virtual BlackBerry Servers on one host computer. Each virtual BlackBerry Server runs as a separate mail-redirection service. Installing multiple BlackBerry Servers lets you better use hardware by quadrupling the number of redirected mailboxes that one computer can support. By default, when you install multiple BlackBerry Servers, the setup process appends the numbers 1 to 4 to the host server's name to provide unique names for the virtual servers. For example, if the host server is named BES01, the first virtual BlackBerry Server on that host server is named BES011, the second is named BES012, and so on.
Configuring a virtual BlackBerry Server is identical to configuring a single-instance BES server. You must purchase a Server Routing Protocol (SRP) Additional Service Key (RIM nomenclature for a license key) for each server instance just as you would if these servers were operating on different hardware. The recommended number of users hosted on a BES server before version 3.5 was 500; now, you can run 500 users per virtual BlackBerry Server—up to 2000 per physical server—if your hardware can handle the load.
In addition to installing the services that handle mail redirection, BES setup installs other services, such as BlackBerry Attachment Server to convert attachments to text and BlackBerry Mobile Data Server to provide access to corporate data resources and Web pages. During BES installation, you choose which services are available for each virtual BlackBerry Server. If you specify that the users of a certain BlackBerry Server should have access to data, BES installs an instance of BlackBerry Mobile Data Server for that BlackBerry Server. If you specify that a BlackBerry Server should convert attachments, BES installs BlackBerry Attachment Server (only one instance per physical BES server) and links the BlackBerry Server to BlackBerry Attachment Server.
For example, if you install four BlackBerry Servers and specify that the first three can perform attachment conversion but only the first two can provide data access, BES installs seven services to support this configuration, as Figure 1 shows. (The BlackBerry Database Consistency Service is a background service that's installed with the first BlackBerry Server redirection service.) This configuration would give users assigned to BES011 and BES012 full functionality, users assigned to BES013 attachment conversion capability but not data access, and users assigned to BES014 only basic functionality. (I'll provide more details about BlackBerry Mobile Data Server and BlackBerry Attachment Server in a follow-up article.)
RIM's base recommendation for BES 3.6 and BES 3.5 is a 500MHz processor with 256MB of RAM. However, BES 3.6 introduces wireless email reconciliation (a mechanism that synchronizes your desktop mailbox with your handheld device without requiring a cradle). As you can no doubt imagine, wireless email reconciliation (which I'll discuss more in the follow-up article) results in more communications activity and mailbox operations. You'll need to consider the number and types of services and users per BlackBerry Server when you think about your server hardware requirements. Perform some site-specific analysis that takes into account how many services are running, what services people will use most, and how much traffic users generate and receive. A late-model dual-processor system with 1GB to 2GB of RAM should handle a full load (i.e., four BlackBerry Servers with 500 users each) nicely. Both BES 3.6 and BES 3.5 need Windows 2000 on the BES system and work with all versions of Exchange.
When you upgrade to BES 3.6 or BES 3.5, you also need to upgrade your clients' BlackBerry Desktop Software and BlackBerry Handheld Software. The sidebar "Handheld Requirements" has the details.
Other updates and changes to BES concentrate on security. BES 2.1 introduced the concept of policies, which let you enforce certain configuration options in BlackBerry Desktop Software and on the handheld devices. For example, policies let you specify the maximum number of days between handheld backups and how long the device can remain inactive before its screen and password lock are engaged. With BES 2.1, you use a text editor to build a policy file, distribute the file to the desktop, then load it on the handheld device during desktop synchronization. BES 3.5 moves from this text-file approach of configuring policies to a GUI approach. Figure 2 shows the BES 3.6 policy-editing GUI, which takes policy administration a step further by grouping the policy settings in device, desktop, password, security, and other categories.
BES 3.5 also introduces wireless policy deployment, so you no longer need to make the policy file available at users' desktops or wait until the handheld device is in a cradle to implement a policy. Wireless deployment sends to the devices special messages that contain the policy definitions. These messages are handled just like email messages from a deliverytodevice perspective. To ensure that changes reach devices, the RIM network queues policy messages until all devices can receive them.
When you define a policy, you specify settings, then assign a list of handheld devices to the policy. This practice gives you the flexibility to define different policies for different user classes within your organization. For example, you might have given your mobile users BlackBerry 5810 devices with a minibrowser that they could use to surf the Web over your cellular provider's Wireless Application Protocol (WAP) gateway. To trim your airtime charges, you might define one policy that disables the use of the WAP browser for most users and a second policy that lets specific executives browse.
When you create and deploy policies, don't edit the default policy that's installed with BES. Always create a new policy and assign handheld devices to the new policy. When a device processes a policy message, it sets values in its memory. These settings change only when the device receives another policy message. Thus, to clear the policy settings from a handheld device, you must assign the device to the default policy, which has no definitions. This action sends the device a message that has the effect of removing all policy settings from its memory.
When you define policies, you don't need to worry about sending inappropriate settings to BlackBerry models on the policy list. BES keeps track of the different handheld types when generating the policy messages and sends only appropriate policy settings to the different types. For example, RIM 957 devices don't have built-in phones, so BES won't send them phone-related policy settings. Table 1 shows a few of the policies I've used and the settings that I recommend.
Lock It Up or Kill It
BES 3.5 introduces two new functions that let you secure a handheld device if it's lost or stolen or the user can't remember the device's password. Using the BES Administration Console, you can send the device a command that will lock the device and set a new password if the user agrees. You can also send a command that will completely erase the device's memory—effectively disabling or "killing" the device. When you disable a handheld device in this way, you must reload its handheld software by using the desktop cradle before the user can use the device again.
When you issue the Set password and lock function from the console, BES sends the handheld device a wireless command that contains a new password for accessing the device. The device displays the prompt Accept over the air password?, and the user must answer yes or no. Yes locks the device and resets the password; no locks the device and leaves the old password intact. Because you don't know whether the BlackBerry user rejected the new password, I recommend that you immediately use the BES Administration Console to disable redirection for a device after issuing the Set password and lock command for it. This action ensures that the operator can't use the device to send wireless email if he or she rejected the password change and knows the original password.
You can use the Set password and lock function to lock voice-enabled devices (BlackBerry 6750, BlackBerry 6710, BlackBerry 6510, BlackBerry 6210, and BlackBerry 5810—and probably BlackBerry 7230 and BlackBerry 7210, although I haven't tried it on these new models) without setting a new password and without the user having to respond to a prompt. To do so, you simply send a password that's shorter than the minimum defined by the applicable MinPasswordLength policy. The device will lock, and the existing password stays in effect. For example, if your policy specifies eight-character passwords (e.g., hewlett4) and you send a Set password and lock command with a seven-character password (e.g., packard), the device doesn't display the Accept over the air password? prompt, the device locks, and the old password is retained. RIM lists this characteristic as a known issue, but I consider it a feature. If a user arrives at home and realizes that she left her device on her desk at work, she could call and ask an administrator to secure the device by locking it remotely. Sending a short password to the original data-only RIM 957, RIM 950, RIM 857, and RIM 850 devices causes them to display the prompt.
All BlackBerry (and RIM) handheld devices have at least two paths for sending messages to one another: email and peer-to-peer (P2P) routing, also known as PIN-to-PIN communications because devices route messages directly to one another by using the devices' unique PIN numbers as addresses instead of routing messages through the Exchange Server system. BlackBerry devices that support Global System for Mobile Communication (GSM) and General Packet Radio Service (GPRS) can also send Short Message Service (SMS) messages. Both users and administrators like having more than one route for sending messages because the alternatives let users stay connected when Exchange is unavailable.
Figure 3 shows the email and PIN-to-PIN paths. Route 1 shows the email path, which has two legs. The sending handheld device encrypts the message by using a security key that's unique to the associated sending email account. The encryption key is stored in the devices memory as well as in a hidden folder in the user's mailbox. If user Ben wants to send an email message to user Andrew, Ben's device uses its copy of his key (i.e., 777777) to encrypt the message, then sends the message (route 1, leg A). When BES receives the message, it uses the copy of the key stored in Ben's mailbox to decrypt the message. BES then reads Andrew's encryption key (i.e., 555555) from his mailbox, encrypts the message, and sends it to Andrew (route 1, leg B). Andrew's handheld device decrypts the message by using its copy of Andrew's key. Each route leg must use a different security key to encrypt and decrypt the mail because the destination device doesn't know the sender's key and vice versa.
Route 2 shows the PIN-to-PIN path. P2P messages don't interact with BES, so it can't use the email encryption keys stored in the mailboxes to secure these messages. By default, PIN-to-PIN messages are sent unencrypted, so some organizations are reluctant to let users send sensitive information in these messages. Beginning in BES 3.6, you can use the BES Administration Console to generate a unique security key for use in PIN-to-PIN communications and distribute the key wirelessly to all handheld devices in the organization. After you distribute the key, BlackBerry devices will use it to encrypt all PIN-to-PIN messages (as Route 2 in Figure 3 shows). Only devices that have a copy of the PIN-to-PIN encryption key can receive and read the messages.
You should be aware of some considerations if you plan to go the PIN-to-PIN encryption route. First, a device that doesn't have the PIN-to-PIN encryption key (such as a device outside your organization) will discard the encrypted PIN-to-PIN messages it receives. However, because the handheld device receives a message before discarding it, the network reports a successful delivery to the sending device. The sending device shows the PIN-to-PIN message with a status of Delivered, but the destination device never shows any indication of having received the message. Handheld devices in your organization that have a PIN-to-PIN encryption key can still receive and display unencrypted PIN-to-PIN messages from handheld devices outside your organization, but external devices will discard the encrypted messages they get in reply. For example, the BlackBerry administrator at Ben and Andrew's company generates a PIN-to-PIN encryption key (i.e., 123987) and sends it to all of the company's devices. When Ben and Andrew exchange PIN-to-PIN messages, their devices use the key to encrypt the messages. If Ben sends a message to Emily, a BlackBerry user in another Exchange organization, her device will discard the PIN-to-PIN message because she doesn't have the encryption key. If Emily sends an unencrypted PIN-to-PIN message to Ben, he'll be able to read it and send a reply (and his device will show the message was delivered), but Emily won't see the reply.
To remove the PIN-to-PIN encryption key from a handheld device, you erase the device's memory and use BlackBerry Desktop Software's application loader to reload the BlackBerry Handheld Software on the device. In an effort to troubleshoot a perceived problem in sending PIN-to-PIN messages to external devices, a user might try to reload the handheld software. If he doesn't fully understand the security implications of his action and attempts a reload without consulting an administrator, he could unintentionally remove the PIN-to-PIN encryption key. This action could result in a security violation if the user then sends sensitive information in PIN-to-PIN messages. Thus, you should be sure to communicate to users the full effect of instituting PIN-to-PIN encryption.
On some occasions, a user or Help desk staffer might need to erase and reload a handheld device to resolve problems or upgrade software. Be sure you have procedures in place so that users and Help desk personnel ask you to resend the PIN-to-PIN encryption key to reloaded devices. If your organization requires a high level of security, you might want to consider generating and sending a new security key each month as a standard operating practice.
Time to Upgrade
If you haven't moved to BES 3.6 or BES 3.5, the features I've described might be sufficient to convince you to do so. Policies are my favorite because they provide so much power to keep your data safe, but the other features also provide excellent enhancements to an already good solution for wireless email.
In the follow-up to this article, I'll discuss functionality and options such as Global Address List (GAL) lookup, BlackBerry Mobile Data Server, BlackBerry Attachment Server, and wireless email reconciliation that more directly enhance the user's experience with the handheld device.