If the new capabilities in Research In Motion's (RIM's) BlackBerry Enterprise Server (BES) 4.0 have your mouth watering, you're probably already planning your upgrade or migration. In general, you're in store for an easy transition. But before you begin, there are a few things you should know. As promised in "BlackBerry Enterprise Server 4.0," October 2005, InstantDoc ID 47216, I'll take you through the important points of installing the new BES version and (in my opinion) its most exciting new feature—wireless provisioning.
Quiet Configuration
If you've never used BES, you need to take some steps to prepare your environment before you install the product. Don't worry; the BES 4.0 Installation Guide details these steps, which include granting the BES service account privileges to read and write to user mailboxes and creating the necessary database environment. Moving to BES 4.0 from an earlier version is also easy and well-explained in the guide, so I won't go over the steps here. But I will warn you: If you have more than a couple hundred BlackBerry users—especially if you're running multiple BES Redirector instances or have multiple physical servers—don't just pop in the CD-ROM and start upgrading. You'll need to watch out for a few potential gotchas.
When you run multiple Redirector instances, each with a unique name and a RIM Server Routing Protocol (SRP) identifier, all those instances will be collapsed into one server name during the upgrade. For example, suppose you have four Redirector instances: BES01A, BES01B, BES01C, and BES01D. After the upgrade, you'll have only the BES01A instance. All the users assigned to the BES01B, BES01C, and BES01D instances will be migrated to the BES01A instance.
Prior to the upgrade, the configuration information in each user mailbox contains references to the individual server names and the specific SRP identifiers that are associated with each instance. Let's suppose the BES01A instance uses SRP identifier 1, BES01B uses identifier 2, BES01C uses identifier 3, and BES01D uses identifier 4. In earlier BES versions, changing the BES name or moving users to a new BES required that users recradle their handhelds to receive the new SRP identifiers and server names needed to restore wireless connectivity. During an upgrade to BES 4.0, the SRP identifiers and server names are moved into Microsoft SQL Server or the Microsoft SQL Server Desktop Engine (MSDE) BES management database, and BES continues to quietly use all the previously assigned SRP identifiers. I say "quietly" because the BlackBerry Manager and the BlackBerry Configuration Panel (replacement tools for the Microsoft Management Console—MMC—BlackBerry Enterprise Server Management snap-in) will show only the SRP identifier for the first server: SRP identifier 1, associated with BES01A. It appears that SRP identifiers 2, 3, and 4 have been discarded and are no longer being used. In reality, the BES slowly updates the handhelds, replacing SRP identifiers 2, 3, and 4 with identifier 1 over time. Handhelds that are running BlackBerry Handheld Software 4.0 receive the updated identifier immediately via wireless synchronization; other handhelds get the new identifier the next time they're cradled. This method prevents communications disruption, but you need to be aware that you can't immediately reuse the old SRP identifiers to install a new server. If you attempt to do so, the RIM SRP network will detect that two servers are trying to use the same SRP simultaneously and will disable the SRP. Any handhelds that are still using the SRP will cease to communicate until you call RIM, humbly explain what happened, and have the SRP re-enabled.
The Best Strategy
In fact, when you have multiple Redirector instances or multiple BESs, you should follow RIM's phased upgrade strategy. During a phased upgrade, you manually upgrade the database to BES 4.0, run a series of premigration tests on the users assigned to each Redirector instance, then run the Installation and Upgrade tool to upgrade the server software and collapse the instances. A manual database upgrade sounds complex, but it isn't. You simply use the createdb.exe command-line utility to trigger a database upgrade outside of the wizard-driven upgrade process.
The BES CD-ROM's Database folder contains a file named besmgmt.cfg. Using Notepad, edit this file and change the CMD parameter from Install to Migrate. Set the Backup parameter to True, and specify a path for the Backup_dir parameter so that the CreateDB process will back up the database before beginning the upgrade. After you've made these changes, log on to the database server with an account (e.g., the BES service account) that has Full Control rights on the database. At a command prompt, run the command
createdb.exe besmgmt.cfg
After upgrading the database, use the BES service account to log on to the BES.
Look in the BES CD-ROM's Tools folder and find besmigration.exe. This utility lets you migrate users from one BES instance to another and lets you preview the migration to determine whether it will succeed. The preview is a vital step; don't skip it. You'll need to know the name of a specific Redirector instance, the Messaging API (MAPI) profile that links to that Redirector instance, the name of the new collapsed BES server instance, the name of the database server, and the name of the management database. Then run the utility, using the following syntax:
besmigration.exe -p -s-d
The -p option tells the utility to run in preview mode. The -s option lets you specify BES server information, and the -d option lets you specify database information. MAPI profile is the profile used by BES instance, which is the BES instance that will be collapsed or moved to a new server. New server is the BES server instance to which users will be migrated. This can be the first BES instance on a server (when you're collapsing many instances to a single instance) or a completely new instance on a new BES. Database server and database name refer to the newly upgraded BES 4.0 database.
Let's look at an example, again using the BES01A, BES01B, BES01C, and BES01D sample instances. Let's suppose that these instances are linked to matching MAPI profiles named BES01A, BES01B, and so forth. The database server name is BESsql, and the database is named BESmgmt. You're upgrading a single physical BES server, and all instances will be collapsed into BES01A. At a command line, you'd run the command
besmigration.exe -p -s bes01b bes01b bes01a -d bessql besmgmt
(Some commands wrap to multiple lines here, but you should type the command on one line.) Each mailbox associated with BES01B will be checked to ensure that the migration process can read and access all data. During the actual migration, the handheld data that's stored in the BESAdmin mailbox's structures will be moved into the management database. If any problems occur, they'll show up in the preview output, as Figure 1 shows. After you run the preview for the BES01B instance, run the utility for the BES01C and BES01D instances, using the commands
besmigration.exe -p -s bes01c bes01c bes01a -d bessql besmgmt besmigration.exe -p -s bes01d bes01d bes01a -d bessql besmgmt
Why is previewing the migration so important? When the migration process is run, either by using the Installation and Upgrade tool or by using besmigration.exe, all the users that are assigned to a Redirector instance are migrated at one time. You can't migrate selected users. If the migration process has a problem with one or more accounts, those accounts aren't migrated. The end result could be that you have some accounts on one server instance and some on another—but both instances will expect to use the same SRP identifier. Because you need to stop the source and target Redirector services while migrating, a failed migration means that one of the Redirector services won't be able to be restarted. This will either leave some users stranded on the old server or leave the migrated users without service. Your simple migration could turn into an all-night debugging and repair session.
Using the preview option helps you determine ahead of time which accounts, if any, need to be cleaned up before the migration. You should run this preview step for each Redirector instance. You should also run the preview step on the first instance (e.g., BES01A), which the rest will collapse into. You need to run this test on the first instance because that instance's data also needs to be migrated from the BESAdmin mailbox into the management database and is just as vulnerable to migration problems. (I explain the storage changes behind this aspect of the migration in "BlackBerry Enterprise Server 4.0.")
After you've confirmed that all accounts will migrate successfully, you can complete the phased upgrade. Run setup.exe from the BES installation CD-ROM to start the Installation and Upgrade tool, which will step you through the upgrade. You'll be on your way to using all the new features that BES 4.0 has to offer.
Wireless Provisioning
As I mention in "BlackBerry Enterprise Server 4.0," one of the most exciting features in this release is wireless provisioning, which lets you load BlackBerry handhelds with applications and data—without users needing to recradle their BlackBerry devices. Using BlackBerry Manager, you add a user to the BES by using the same process as earlier versions (e.g., by selecting them from the Global Address List—GAL). After adding the user, you can open the user's Properties page.
Click Set Activation Password, then specify an activation password. Provide this password to the user in person or over the telephone instead of via email (for security reasons, of course). On a new handheld or one that has had its memory wiped, an Enterprise Activation icon appears on the main screen; on a previously provisioned handheld, the user must access the Enterprise Activation function through the Options icon. After triggering Enterprise Activation, the user must enter his or her email address and activation password, then click the thumb-wheel and select Activate.
The handheld uses the activation password and an Elliptical Curve key-generation algorithm to create a temporary encryption/decryption key, then sends an encrypted activation message (Figure 2 shows an example) to the RIM network. Among other things, this message contains the handheld's PIN. RIM servers receive and retransmit the message via SMTP to the email address that the user specified.
When the message reaches the user's Inbox, BES opens, reads, and deletes the message. BES uses the activation password to decrypt the message and authenticate the activation. At this point, BES knows the handheld's PIN (from the encrypted SMTP mail message) and begins the provisioning process, which generates a new master encryption key and transmits service books (akin to .ini configuration files), applications, configuration, email, and personal information manager (PIM) data to the handheld. During activation, the user is prompted to overwrite or preserve exiting data, so that the process doesn't overwrite data that was on the handheld before activation unless the user wants it to. Unless an extremely large amount of data needs to be pushed to the handheld, the entire activation process usually takes less than 15 minutes from the time the user clicks Activate.
If the user already had a handheld that was connected to the same BES 4.0 server, any existing data that was backed up via wireless backup will be restored to the new handheld. This capability makes replacing lost or damaged BlackBerry devices extremely easy, especially when the user isn't near an IT support center. Consider an executive—attending a conference far away from the office—who drops his or her handheld into a bowl of fruit punch. The executive can walk into the nearest wireless retailer, purchase a new BlackBerry device, then use wireless provisioning to restore not only access to Exchange Server but also local device data and personalizations such as browser shortcuts and saved messages.
A Fine Vintage
The most recent BES version has some very cool new features. Take the time to explore them, and you'll be well on your way to easier administration and new service offerings for users. Bon appetit!
