One of the biggest areas where Exchange Server 2010 differs from its predecessors is in its high-availability functionality. When you build an Exchange Server 2010 site, you have more ways to ensure that the sites go up, stay up and can withstand problems that would have previously brought your Exchange environment to a screeching halt.
The most crucial new high-availability feature is a database availability group (DAG), a way to give Exchange servers the reliability of clusters without the headaches associated with traditional clustering. DAGs gang together groups of Exchange Mailbox servers to allow their databases to be replicated automatically among the servers in the group and to allow automatic failover across the servers in the DAG. Microsoft bills DAG technology as “the base component of the high-availability and site resilience framework built into Microsoft Exchange Server 2010.”
Having DAGs simplifies many procedures when it comes to Exchange reliability. With DAGs, you can allow for failover without first having to build clustered servers and install Exchange on them. In Exchange 2010, you can add servers to a DAG at any time and allow them to replicate between each other. And because replication is more granular in Exchange Server 2010, you don’t have to replicate every mailbox.
Additionally, with DAGS, databases are not tied to a single server; they can be replicated up to 16 times across different mailbox servers. Microsoft claims a DAG with three servers better protects Exchange and recovers from disaster faster than a single, conventionally backed up server.
Mailbox, Transport and Recipient Functionality
Exchange Server has always been, and probably always will be, primarily about mail. To that end, Microsoft added a whole slew of new mail-handling features to Exchange Server 2010, including:
• Moderated transport. An administrator can require approval for sending messages to certain recipients.
• Shadow redundancy. Messages are automatically resubmitted if they’re sent to an Exchange Server 2010 hub transport server and don’t return a successful delivery report.
• End-to-end message tracking. Admins can log and analyze the entire path of a message for troubleshooting.
• Memory handling. Better handling of memory used to process distribution groups, so large distribution groups don’t choke the server when they’re expanded.
• New transport rules and rule handling. This lets you create rules bound by Active Directory Rights Management Services.
• Moving mailboxes. Move requests make it possible to move mailboxes between databases while they’re still in use. Message tracking data isn’t available during the move.
• Calendar sharing. Users can share calendars—including free/busy data—with users residing outside the organization via Outlook 2010 and the Federated Sharing feature. Note that only admins can control this, not users.
All of the new high-availability and mail-handling features aren’t worth much if you can’t control them. Exchange Server 2010 also includes some new administrative capabilities that allow you to better manage your environment.
• Exchange Management Console (EMC) behaviors. The EMC itself sports new features such as an Organizational Health overview and the ability to add Exchange forests to the console tree.
• Exchange Management Shell functions. The Exchange Management Shell Command Log saves commands that you’ve executed in the EMC for future use. This feature complements the administrator audit logging functions in Exchange 2010 that records when cmdlets are run and who runs them.
• Exchange Control Panel (ECP). Administrators can use the ECP for the Outlook Web App to manage features such as text and voice message integration, distribution list moderation and the ability to search multiple mailboxes.
Exchange Server 2010 is a 64-bit-only product. The prevalence of 64-bit server hardware and 64-bit editions of Windows Server was one factor for moving solely to x64. Another major impetus was the fact that many Exchange installations will benefit from more memory since 32-bit operating systems are infamous for having memory constraints.
While Exchange Server 2007 shipped in both 32- and 64-bit editions, the 32-bit edition was not intended for production use—it was intended solely for lab use, virtual machines (VMs) and evaluation. Unfortunately, this hasn’t stopped administrators from asking for a 32-bit version; however, that request is driven by the desire for the familiar management tools—not necessarily the need to run Exchange Server on 32-bit hardware.
There are a few workarounds for this, notes Exchange Server expert Paul Robichaux. A few options include using Remote Desktop to connect to the Exchange Server and perform management tasks using the Web-based Exchange Control Panel or using Windows PowerShell on any client that supports it.
Exchange 2010 Features: Out with the Old
Many features from previous versions of Exchange are no longer supported in Exchange Server 2010─but only because they have been replaced with new or improved features. Some examples include:
• Clustering and continuous replication in all its incarnations has been replaced with Exchange Server 2010’s high-availability and site resilience features.
• Mailbox database copies is another way in which DAGs replace a range of features such as storage groups.
• Exchange Web Services take the place of Web-based Distributed Authoring and Versioning extensions. If you have a lot of WebDAV-related functionality in your organization, you’ll need to learn how to migrate from WebDAV [http://go.microsoft.com/fwlink/?LinkId=169474] before you use Exchange Server 2010.
Microsoft has a full rundown of what it removed or replaced in Exchange Server 2010—and from Exchange Server 2007 and earlier versions of Exchange as well. The older your existing Exchange architecture, the more you’ll benefit from a complete understanding of what you’re gaining and what you’re losing.
Dig deeper on Exchange Server Deployment and Migration Advice