Microsoft recently released Exchange Server 2013, an improved messaging platform that provides quite a few interesting features at various levels. There are major changes, and organizations will have to rethink the way they plan to maintain or integrate messaging in their infrastructure. The level of changes is not as dramatic as those seen between 2003 and 2007, but as you will see, certain things are dealt with differently. As of now, very few organizations have Exchange 2013 running, so it is certainly going to be interesting to see how this iteration of the product will interconnect with existing messaging solutions soon.
Here we will examine what is new in this release, as well as what has been simplified from 2010. This will help us gather key information we need to evaluate the possibilities and implement this fresh release into production. As of now, configuring Exchange 2013 on top of an existing Exchange infrastructure is not possible, but with the release of new service packs and cumulative updates, it will be feasible, and we will cover the most obvious features here.
Database Availability Groups (DAG) enhancements
Numerous features have been added in the database availability group components. The core functionality has not changed, as DAG is still the only way to make continuous replication work, but a few of them are reflected here:
- It is now possible to run DAG on a standard edition of the Windows Server platform.
- There have been improvements in site resiliency scenarios.
- AutoReseed allows the restore process to happen more efficiently.
- Active and passive databases can use the same storage.
- The transport dumpster has been replaced by the Safety Net engine, which is similar, but simplifies the use of shadow queues, as well as lagged copies
There are numerous other changes, but the major one is the possibility of using database availability groups for public folder replication.
Database failure isolation
With the store itself redesigned, process isolation has been introduced. This functionality helps separate different processes for databases, diminishing the chances that a single database failure can affect other databases or the server itself. While this feature might take more processing, it is still considered an asset, helping in the stability and scalability of mailbox servers.
Redesigned public folders
In Exchange 2013, public folder databases no longer exist. Instead, you can create public folder mailboxes, create a hierarchy within them, and assign them to mailbox users. The issues with a traditional public folder database are no longer present. The multi-master replication is not used anymore, and these public folder mailboxes can now participate in database availability groups, and continuous replication mechanisms, as well as in all other scenarios that control and make traditional mailboxes available to users.
Previously configured delegated mailboxes can be converted to shared mailboxes, as they provide an easier way to access messages that are for helpdesk scenarios, generic inquiries, or other types of access that require a centralized approach in administering a mailbox. When a user is granted full control for the shared mailbox, it is possible to open that additional mailbox through OWA or link it to the Outlook profile.
Mailbox database limits
While the number has not changed for the standard version, the Exchange 2013 Enterprise limit is set to 50 databases per server. This decrease is mainly due to system performance. While 50 still seems to be a large number of databases, when you consider implanting DAG and creating multiple copies of your databases, this number can be reached fairly easily. Thus, new design considerations for storage will have to be planned.
Reproduced from Global Knowledge White Paper: Exchange 2013: New Features and Changes.