Mailbox Server role

An Exchange Server 2007 mailbox server is the same conceptually as an Exchange server mail store for all versions up to and including 2003. It stores emails. This is the location of the priv.edb, priv.stm etc (although there is no streaming file in Exchange Server 2007). However it should be noted that this is the only thing that this role does û you need to look to other roles for delivering mail, messaging hygiene and so on.

Taking the guidelines from Exchange Server 2003 of 50GB per store, one store per storage group (http://support.microsoft.com/default.aspx?scid=kb;en-us;890699) and 1 IO per user (http://blogs.msdn.com/jamesmwhelan/archive/2005/11/15/492892.aspx) means that a Exchange Server 2007 should be incredibly scaleable with the right hardware. A drop of circa 75% in IO requirements (giving Exchange Server 2007 a 0.25 IOPS) should allow a fourfold increase in either users, data, throughput or growth ability. Or even better for the SME market, the ability to be scaleable with Exchange using inexpensive SATA disks rather than Brocade switches and EMC storage solutions.

So what does that mean realistically? Think about this:

Two externally attached USB-2 drives, software mirrored for the Exchange databases.
Two identically specified USB-2 drives, software mirrored for the transaction logs.

For under $600 you get to have resilient 300GB for the stores and 300GB for the transaction logs. Admittedly that is not a terribly good way of doing things, but it does have the advantage of bang-for-buck / size of hard drive to resilience.

In the SME market of under 100 users this gives an AVERAGE mailbox of 1GB before you need to get worried. It further gives you the ability to do offline defragmentation of the database on the same drive at that level of store usage.

In theory the reduction in IOPS requirements due to the 64 bit architecture means that each storeÆs recommended maximum size should increase to 200GB however it is more based on restore time than performance when in use.

As with Exchange Server 2003, create a new storage group for each store. Unlike Exchange 2003, you now have the ability to create up to 50 SGs per server and a maximum of 50 stores so there should never be a need to create a second store inside a storage group (though the facility is supported). Taking this further, retaining the existing 50GB per store recommendation and running that across one store for each of 50 storage groups gives a calculation of 2.5TB of data per server. Even the most ardent of email hoarding organisations should find that sufficient although because of the way Exchange works, that 50GB recommendation would therefore be the maximum mailbox size for an individual.

Larger firms will no doubt be running more than one Exchange Server. This is still possible with Exchange Server 2007. So your choices are numerous.

1. Resilient hardware. The most popular option for servers is to let the server take the strain. Redundant power supplies, hard disks, memory and so on are all critical to the running of your Exchange farm. Organisations running Exchange on an elderly desktop unit with no redundancy at all are principally the ones with no backups and fairly large problems when things go wrong. This will remain the best option in Exchange Server 2007 until you get to the largest of organisations.
2. LCS. Local Continuous Replication. Now here is a thought, why can you not mirror the store? In Exchange Server 2007 you now can. Think of it as a software mirror of your store to another store on the same physical box. It can even be on the same spindles if you really want to slow things down! Take a live store, Exchange takes a replica and as you close a log, you log ship to the LCS replica, play the log through and the replica is then up to date. It will never be more than one log file out.
3. CCS. Continuous Clustered Replication. This is the new term for a clustered Exchange environment. This will need its own book.

Why CCS? If you are a huge firm and email is so critical to your organisation that one second of downtime is simply not an option, then CCS is for you. CCS will mean two monstrously powerful servers each with their own storage solution. Talk to the vendors, there are enough of them out there. This is not going to be for the faint hearted and is not for any firm without large pockets and the ability to employ highly paid external consultants.

Rule of thumb û if you have not implemented at least one live cluster server, you do not need CCS.

That is the caveats out of the way. Down to business. CCS is similar in concept to LCS but across multiple servers. Finish writing the log, ship it to another server, play forward that log. This sounds tremendously simple in theory but the configuration of an Exchange cluster is a complex beast (although Exchange Server 2007 is far easier than earlier versions). Now transaction logs flowing from machine to machine across the network and potentially across a WAN link? Yowzer. What happens if the file does not copy correctly, there is some kind of latency or other problem. That could create a whole can of worms.

It wonÆt. Trust me. There will be more on this once information is in the public domain.