BES you is, or BES you ain't my baby...

Managing, protecting and just plain nurturing your Exchange Servers is a pretty common theme in this blog, but many times we can ignore eco-system servers that are just as critical.  Blackberry Enterprise Server (BES) is one such example, though many corporations use GoodLink and other tools as well.

Eco-System servers are systems that are not Microsoft-created add-ons for Exchange Server, but that rely on (or are even installed on) Microsoft Exchange boxes.  They can range from something simple like an anti-spam service or appliance, to something as complex as a Customer Relationship Management (CRM) solution that uses Exchange as a data warehouse.   BES is extremely popular among mid-sized and larger organizations to provide remote access to email where Windows Mobile or other Exchange Activesync devices may not be the best choice. While the Blackberry platform from Research in Motion is a great way to deliver mail to mobile workforces, it will almost definitely add at least one more server to your environment that you have to keep an eye on.

BES runs on a Windows platform in most cases, and generally will be installed on a different machine than the Exchange Server itself.  (I'm keeping this discussion specifically to Windows and Exchange, please visit Research in Motion, LTD for other options).  If you choose, you can use BES as a hosted service, and therefore not have any servers on your site, but most mid-sized and larger organizations bring the BES system in-house.

There are two common configurations for BES.  The simplest is a single-server that hosts both the BES application and a small MSDE or Microsoft SQL database.  MSDE is a great engine, but is limited in terms of how large the database can grow.  Once you go beyond that limit, a full license of SQL is required.  Single server configurations offer simplicity, only one box to manage and worry about backing up, replicating, etc.  Their drawback is scalability. Once you go past a couple of hundred users (easy to do in larger firms), the overhead of both the BES application and the SQL systems on the same box will slow the server to a crawl when it is under any form of stress.

Multi-server configurations take over where single-server configurations get bogged down.  You can host the BES applications on one server, and the database on another.  This allows each application to use the power of the entire server it is located on.  In addition, you can have multiple BES application servers sharing the SQL back-end server, which gives you higher levels of scalability without having to use multiple SQL licenses, offering a cost savings that adds up fast.

In all of these situations, there are a couple of considerations that you need to be aware of when setting up redundant and/or Disaster Recovery for BES systems.  The first is that the application servers are high-I/O load systems, but don't store much data locally.  Nearly all BES data is stored either on the Exchange Server or in the SQL database.  While that means that there is less stuff to protect on a BES application server, it doesn't mean there is nothing.  The Server Routing Protocol (SRP) information and a critical set of application settings are still housed on the application server, so protection is mandatory.

In short, you have to protect Exchange, SQL and the BES application server in your DR plan, otherwise your mobile users will quickly find themselves with no mobile e-mail.

SQL and Exchange are relatively well documented in terms of protection.  But the application server poses a very specific issue.  If the SRP is installed on two machines (as in a traditional failover solution), and these two machines accidentally transmit data to the RIM network at the same time, you will be forced to manually correct the issue by calling RIM tech support and getting the SRP unlocked.  So, your basic options for protection of this type of server are to either use a backup/restore method; use a full-server failover system (like Livewire or FSFO - see disclaimer below); or be prepared to build a new application server in the event of an emergency.  The theory of having a standby BES server with the SRP loaded but kept offline does work (it's called Knife-Edge Cutover), but can be dangerous in situations where many administrators work on the servers and don't necessarily talk to each other before doing things.

Any of these theories can be used, but you will need to have the method you will use ready to go well before the actual emergency.  Plan well, and your Exchange, SQL and BES services will perform as expected, but fail to plan and the mobile devices you rely on to get emergency info out to your employees will be turned into expensive paperweights.