BlackBerry® Enterprise Server Version 5.0

[MichiganMan]

So...  we are looking to migrate from our current 4.1.x environment to BES 5.x, as it is the greatest thing since sliced bread and will bring you cookies and milk every night (or so my RIM account manager tells me ).  We've had one overview meeting with our technical acct rep, and the basic plan goes something like this:

Current environment:

• 6 BES 4.1.x servers (4 virtual, 2 physical)
• 2300 users total  (avg 400ish users each, with one exception BES05, only a couple dozen on there)
• Exchange 2K7
• 1 Blackberry DB

Proposed environment:

• 2 primary BES servers (1200 users each) - both virtual
• 2 secondary BES servers for high-availability - both vitual
• 1 attachment server - physical server
• 1 leftover server - physical
• 1 Blackberry DB

Our technical resource tells me we should be able to do something like this:

1. Move all "normal" users off BES05, leaving only pilot users
2. Upgrade BES05 to the 5.0 software
3. As part of the 5.0 upgrade, the Blackberry DB schema will be "extended" but will continue to work fine with the 4.1.x servers
4. Let percolate for several weeks to ensure all is whirled peas
5. Begin to migrate users from BESxx to BES05, until full
6. Upgrade BESxx to 5.0
7. Lather, rinse, repeat until all users are hosted on 2 primary BES 5.0 servers
8. Stand up one empty server as an attachment server
9. Configure two remaining servers as secondary (failover) servers to the primaries
10.   Profit!

Being as I'm relatively new to this sort of thing, I'm hoping to get some feedback from the battle-scarred veterans.  Does this sound feasible?  Anything I should be considering?  This seems a bit off to me, as my understanding was that you had to stand up a new BES 5.0 DB, then move users from the 4.1.x DB to the 5.0 DB using the built-in migration tool.  That is not how it was explained to me, but it could be that I mis-interpreted what he was saying.

[CerealBypass]

BES 5.0 is AMAZING (and wait 'til you see 5.0.1)

That is a pretty solid plan and will definitely work assuming the new VMs have the hardware to support everything. A few things to consider:

• The part about the schema being extended is pretty important. It means that you will have to administer ALL of your your BlackBerry Enterprise Servers using the web-based BlackBerry Administration Service console. No more BlackBerry Manager, even if you want to manage the 4.1.6 servers
• Once everyone is migrated to their respective servers, you will need to remove the remaining 4.1.6 instances from the BlackBerry domain
• "Configure" might be the wrong term in referring to bringing up the standby servers, you will actually need to run the installer and tell it that you want to build a standby server. It will ask you which instance you want to create the standby server for. 1 standby server per primary server

You do have the option of getting a migration kit and standing up an entirely new BlackBerry domain built exclusively of 5.0 servers. In this scenario, you can use the BlackBerry Enterprise Transporter (BET) to move everyone across. Both plans have their own pros and cons.

I'll open it up to some follow up.

[MichiganMan]

Thank you for the response - I'm debating the entire separate 5.0 method right now. On the plus side, I know it will be clean and configured as I want it, rather than the "inherited" solution I have now.  I've also been speaking with our VM folks, and they've got me wondering if I need an HA solution if I'm running in a virtual environment.  All of my experience with HA has been to limit the impact of hardware failure, and since that is essentially irrelevent to this solution, what could/would trigger a failover?  In other words, what am I protecting against?

If I set up a separate BES 5 environment, I'm assuming I'll need a separate SQL license for the duration of the move.

[knottyrope]

You can run a second instance on your SQL server to keep them separated. You can also make the new instance with out a reboot of SQL.

If running SQL on a new box then you will need another license for SQL.

[MichiganMan]

Our SQL environment is also virtualized via a solution called Polyserve, so I think I may be OK on licensing there.  So, the "migration method" (as opposed to the "upgrade in place" method)  would look something like this:

1. Migrate all users off BES01 (or just stand up a new v5 server)
2. Rebuilt BES01 as BESv5_01
3. Stand up new BESv5 DB
4. Migrate all users from BES02(physical server) to BESv5_01 
5. Rebuild BES02 to BESv5_Attach1 (dedicated attachment server in BES 5 world)
6. Migrate users from BES03 to BESv5_01
7. Rebuild BES03 to BESv5_02
8. Migrate all users from BES04, BES05, etc to BESv5_01, BESv5_02 balancing load as we go
9. Stand down all remaining BES 4.x assets

Not quite a 12 step program, but seems relatively straightforward and has the advantage of not messing with my production environment.

Any thoughts as to pro's/con's for each method?

[knottyrope]

How many mail servers are you running with BES users on them?

[CerealBypass]

I believe the plan is to ultimately end up with two servers hosting all of the users and having one remote attachment service.

Your plan looks good with the only real question mark being the very first step. Where are you planning on moving the users on BES01 to begin with?

In terms of HA, you have the option of including it or not. They can be added in later if needed. From a VMWare perspective, are you talking about simply restoring a snapshot if needed, or is there some kind of redundancy in place which includes a different server?

HA is most effective if the primary and standby are on separate machines. I've seen at least one instance where both servers were virtual and on the same physical machine when the box decided to burn out. In a situation like that, HA isn't going to do much for you.

Within the HA options, there are various thresholds that can be configured and will cause the BES to automatically fail over. The key point there is "automatically." If one BES were to go down, the failover can happen without you having to be woken up at night. HA does take a little bit of planning to get right. Like I said, it can always be added in later if you so desire.

[MichiganMan]

I'm flexible on the total number of servers, with the caveat that I don't want to increase the total number of servers at all.  Based on all that I've read and seen (at WES and online), I ought to be able to run 1000 or more users per server rather than the 450 or so we have today.  The history on the 400ish limit is that we used to be GroupWise shop, and encountered increasing latency once we got past 400 or so users on a BES.  So, the previous administration simply bought a new BES every time they got to 400 or so users...  and now I have 6 BES servers for 2000 or so devices.

I can have my VM "servers" set up any way I'd like, in terms of memory and processor.  I'm leaning at this point to running two or possibly three VM BES 5.0 servers, configured with 4 GB of memory each, plus a separate attachment server.  I currently have a smidge under 2400 users, so two boxes would be 1200 a piece, three would get me to 800 each.  I think I will pass on HA at this time but it may fall under consideration for the future.  Another future project would be stand up a separate server to handle application distribution (I understand that is an option).  Currently we run only one homebuilt app, and that to only a subset of the user base, so I don't have the load/need to add a dedicated server for application management.  That may change, however.

I'm also leaning toward standing up a completely new v5 environment and migrating users via the built in migration tool.  I think this will give me the cleanest environment, and pose the least amount of risk to my current user base (we're in health care and as an organization are extremely risk averse). 

Thanks to all who have responded - obviously, I'm somewhat new to this particular technology space and it has been very helpful to read both the responses to this thread and the forum in general.

[CerealBypass]

The Enterprise Transporter should do the job for you. There's still a little bit of planning that is involved with that.

Check out the Install and Admin Guide for the BlackBerry Enterprise Transporter.

You need to decide whether or not you will be using bulk or live mode.

Other things to consider:

• Devices running OS 4.3 should not be migrated using the BET
• Please please please make sure the source and destination servers are using the same encryption algorithm