- Best iPhone, iPad Business Apps for 2014
- 14 Tech Conventions You Should Attend in 2014
- 10 Desktop Apps to Power Your Windows PC
- How to Add New Job Skills Without Going Back to School
Network World - While Exchange 2007 introduced a plethora of reliability and scalability features, Exchange 2010 helps to clean up what was really a confusing set of options. E-mail managers looking for guidance on building distributed Exchange networks will be pleased to see what has been pushed into Exchange 2010. (We weren't able to test most of these features, so our analysis is based on using the management GUI and reading the reviewers' guide provided by Microsoft.)
The biggest change for administrators in Exchange 2010 is an extended but simplified capability to distribute different user mailboxes across different servers, and keep those servers highly available. The binding of message stores to physical servers has been loosened considerably, and network managers should now easily be able to replicate a message store — up to 16 copies are supported — across multiple servers, with automatic failover capability between servers.
We built two different mailbox servers (the "role-based" server system introduced in Exchange 2007 is essentially unchanged in 2010) and then created a "database availability group", a new concept in Exchange 2010 that replicates a message store database between two servers. Then, we disconnected one of the servers from the network and tested that the other copy of the database was still available. Compared with the more confusing set of options for local and remote replication in Exchange 2007, this was much easier to set up and had an easier recovery path.
Of course, having two copies of the message store doesn't help if you don't build other resiliency, such as multiple client access servers, into your deployment, so this new feature isn't going to be the last word in simplified reliability. Clustering can be an important part of a high availability solution as well, and Exchange 2010 should simplify that tremendously. In Exchange 2007, Windows Server clustering was managed very separately from Exchange itself, which required additional expertise and a different skill set from what the standard e-mail manager holds. Exchange 2010 doesn't entirely solve this (based on the documentation we received), but does move cluster management directly into the Exchange management system. We've observed that some e-mail managers are reluctant to use clustering because they don't understand it and don't know how to manage and control it; by moving this important part of a high-reliability system directly into Exchange, Microsoft makes it more likely that managers will be able to use clustering successfully.
A nice improvement on the scalability front is the ability to move a mailbox between databases without shutting it down. In Exchange 2007, moving message store mailboxes from one database to another could require a significant amount of downtime. In Exchange 2010, you move a mailbox which is in active use between message store databases. This lets the e-mail manager balance the load across servers and disk subsystems without making mailboxes unavailable. Having this feature will also let e-mail managers resist the temptation to build many small message databases rather than a few larger ones, because there's no need to try and predict how big each mailbox and message store database is going to be for load-balancing purposes.