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