We're planning an emergency upgrade of our BES to move it from MSDE to SQL 2005. After adding a new mail store, MAGT 2 refuses to start up after reboots. Probably related to us having more Exchange servers than agents.

Is there a good reason to not put SQL 2005 on the same server as BES? It's not a VM and we'll make sure the hardware specs can handle both.

I saw one forum post recommending against it, but I haven't found any documentation or solid reasons to support it. Any thoughts?

In general, you'll do better keeping MS SQL on it's own server, unless it development server that doesn't get stressed much. If you're using it for production, and there's any kind of load on it, you'll have more options to optimize performance if it's on its own box. Also- when you start putting multiple production services on the same physical server, you lose the flexibility of restarting one when needed, without having to also take down whatever else is on the box. For example: you may find reasons throughout the year to restart BES, but if SQL 2005 is on the same box, and supporting multiple applications, you will NOT want to have to bring it down every time you restart the machine that BES is installed on.

Also: SQL Server, especially 2005, can multi-thread well if it has access to all the CPU's / cores on your server. If it has to complete with other processes, that's another opportunity for optimization that you pass up.

In general - best practices suggest that such diverse production services should have their own machine.

- Jon

That's good info. Our BES will always be on its own physical server, but SQL might be shared if it's on another physical server. It'll ultimately be up to the windows server group, but I'll tell them what you said. Thanks.

OK... while you're passing along suggestion to them - a couple of other considerations that are significant:

Depending on the database and the applications hitting it, SQL Server performance can improve dramatically given more RAM. In general, it makes excellent use of RAM, and can cache indexes in RAM when there's enough space, making lookups (as in queries, joins, etc) dramatically faster.

Other consideration is I/O: SQL performance is heavily dependent on disk I/O, and this is an area that is often ignored. Fast I/O makes a huge difference, and the drive controller configuration is important as well. Multi-threading controllers, large amounts of cache memory on the controller, and minimum contention on the drive/controller all help SQL performance.

Good idea, before all is locked in stone, to get some input from an MS SQL tuning guru re: hardware / network configuration for your server. I've been in IT/technology a LONG time, and been amazed at some of performance hits resulting simply from a lack of proper information at the right point in the decision making process.

Good luck with all of this...

- Jon

We've learned about SQL performance the hard way with 12,000 nodes in our Altiris environment. In that situation, we had our SQL db on a SAN with some slow disks. It's since been overhauled, but yeah, disk performance is critical to SQL. Thanks again for the tips. Hopefully we can get the other half of the BES users up tomorrow.

please dis-regard this reply becasue I meant this to be a new post. My apologises.

It turns out that it was directly related to our Exchange environment having issues. We still need to plan that DB upgrade this summer though.. ;)

When you do upgrade ... please read this: KB12247 - How to move from an MSDE database to a Microsoft SQL Server database