I've been directed to upgrade our existing BES to the latest. On top of that, it is to go from MSDE to SQL and from physical to virtual. This is just begging to go awry if not accomplished in the proper order, I'm certain.

Here are the Specs:

Current
Server 2003 R2 SP1
Exchange 2003 SP2
BES 4.0.5 (Bundle 43)
MSDE 8.00.761 (on BES)
(3!?!) Versions of JRE:
J2SE Runtime Environment 5.0 Update 6 (V 1.5.0.60)
Java 2 Runtime Environment, SE v1.4.2_03
Java 2 Runtime Environment, SE v1.4.2_11

End Goal
Server 2003 R2 SP1
Exchange 2003 SP2
BES 4.1.5
SQL 2005 Remote DB

Can anybody recommend the best way to move forward on this? What should come first, should I consider a knife edge migration? Like most of your installs, the BES is considered critical and cannot go down for more than a 4 hour outage window, and we have no secondary BES, so I need to make sure all the i's are dotted an t's are crossed.

Thanks for any advice!

what size store/users/publicfolders?
How many bes users?

I would do the following:

1. Move the database from MSDE to SQL to make sure the DB works
2. Perform a knife edge cutover of the BES to the virtual server

With the database moved first you've ensured that the DB works fine and when you cut the BES over if it doesn't work you can bring the original BES backup while you work out the kinks.

The best way to move the DB is to get the install folder of the BES version you are running and move the Database folder to the SQL server then run the createdb.exe from a command line. This creates a blank BESMgmt database and writes the appropriate entries in the Sysmessage table. Then backup the DB on MSDE and restore it on the SQL, then use the BlackBerry Config utility to point to the SQL db.

If that works without issue then start the cutover process. All these docs can be found on RIM's TKC, BlackBerry Technical Solution Center.

Feel free to ask any questions you may have.

Which store are you referring to, the Exchange store? We have several across a half dozen servers.

I don't believe anybody is using public folders (on their BB anyhow), and they are going away down the road in the release after Exch 2007.

BES User count is between 300 and 400 if I recall correctly.

Gibson,

So you think I should migrate the DB and go virtual and THEN do an inplace upgrade from 4.0.5 to 4.1.5? Would I want the upgrade to expand the DB schema before move to SQL or after?

Thanks!

Yup, move the BES then upgrade to 4.1.5.

I dont remember much about 4.0 and SQL. But 4.1.5 does SQL well.

I would upgrade to 4.1.5 first then after all is well, upgrade MSDE to SQL then go virtual.

The database runs everything so you can switch over to virtual fast.
More exprienced admins may have answers for you on going virtual.

OK, I have two opposite answers. I have to say I lean towards moving the DB and having the old server to fall back on if something goes belly up.

I agree with Gibson's order and I would do things in stages. If you do the knife-edge cutover to virtual, your outage for that piece will be approximately 30-40 minutes instead of the several hours required for doing a physical-to-virtual conversion.

On the knife-edge cutover, can the virtual box be a clean install versus a cut over to a previously made VM?

Super, could you explain that a little clearer. Do you mean a newly installed VM versus a previously made imaged VM? If so, it shouldn't matter as long as they both work.

We did that all the time for the trainers at RIM, just had VM's made with the BES and all on it and they just placed the files where need be when they travelled.

Gibson,

I gave this more thought last night. What I was asking was if you could knife-edge to a clean install on a VM, or if you had to do it to an image of the existing machine. Your answer clears that up.

My problem with my first option though will be the existing machine is 4.0.5 with the old DB structure, so doing a knife-edge to a new install of 4.1.5 wouldn't have the proper tables in the DB.

The reason I ask about the clean install is that the existing machine seems to be a tad flaky and I've never cared for dirty installs. With that end goal in mind, do you have any other suggestions?

Thanks again everyone.

B....also Blackberry-less and never sees the BES unless somebody broke it or it needs fixing.

what flaky issues are you having?

Sometimes it just hangs and needs a reboot. The BES will open, you can see everything, but it just isn't processing emails. Reboots always bring it back around, but I'd rather not bring whatever that may be along.

I would build a new VM server and install on that and then cut over. If you don't have the install files for 4.0.5, you will need to upgrade your existing server & database to 4.1.x first so you are at the same level when you do the cut over.

The other advantage of doing it from a clean VM build is that you don't run into any problems with changing the # of processors you want your VM to run. If your current box has multiple processors and you want the virtual machine to use only one, then you will have a lot of flaky errors if you do a physical-2-virtual and change the # of processors.

Here are our BES settings for reference.
VMWare ESX 3.5
1 Processor
1024 MB RAM
~400 users

We have had no performance problems with these settings. I am thinking about bumping the memory up slightly, but don't really need to.

Scott,

Those are great Stats to know on the VM box, Thanks!

I'm now thinking about upgrading the existing box to 4.1.5 on MSDE, converting to SQL, and then a knife-edge over to a freshly installed VM box. Sound reasonable?

I thought I'd restir this pot a bit.

What is the purpose of migrating the DB? Is that simply to move the users without re-activation?

What I'm considering doing now is getting a temp SRP, installing the new VM with 4.1.6 and migrating users over to it a few at a time.

Then after everyone is moved, will you move the DB to the VM or just have/leave it on a dedicated SQL box?

My plan would be as follows:

1. Install new BES on new VM box with new SQLDB.
2. Remove 10 users from old BES.
3. Add 10 Test users to new BES.
Repeat.

This allows a slow migration to a fresh install and troubleshooting before cutting the whole company over.

There will be some inconvienience to the users in re-activating, but that's hardly an earth stopping process. I'd like to lose the old DB completely unless there is something more sinister at play if I don't. (The old DB would need to be upgraded anyhow since it's 4.0)

Ok, I'm going to bump this up as we have finally procured the funds and hardware to move on it.

I've been searching (no, really) and reading on the knife-edge upgrade process and need a bit more guidence. (Think bumper rails on the gutters at the bowling alley)

First question: Can I upgrade the DB structure on the 4.0.5 installation and still run 4.0.5 or will that be the impending death of the BES? If yes, how do I upgrade the DB without upgrading the BES?

Next: Gibson stated the following Is that the install of 4.0.5 or is that the install folder of 4.1.5 he refers to? What do the additional steps do if it's the same DB structure? We were able to backup the MSDE DB and restore it to SQL without the added steps. (or so I've been told by our DB person)

Does Chapter 9 apply strictly to 3.6 upgrades or does it work for 4.0.x as well? I have information from a very generous member that I should be a 4.0.7 first and then it should work. Anybody have a clue anymore if that's a painful upgrade?

This whole thing is an inherited system and I have minimal exposure to BES so I apologize if this stuff is relatively elementary.

Thanks!

Read chapter 6. page 49

http://na.blackberry.com/eng/deliver...ide%5B1%5D.pdf

Also The create DB is a directory in the install files of 4.0.
Use that first before restoring to SQL or it will have issues.