The Big Picture
Exchange 2007 features a lot of architectural changes that drive and increase functionality. Implementation requires a hardware upgrade to 64-bit hardware as well as a new approach to server configuration. The major changes from previous versions fall into 4 areas: lots of minor but annoying bugs have been fixed (including the 32kb rules limit and aggravating behaviors within calendaring), 64-bit architecture is used (no 32-bit version is available), new server roles are introduced, and high availability has been dramatically improved.

What A Microsoft Exchange 2007 implementation Means for You
With Microsoft Exchange 2007 you get a better, more versatile product than with previous versions of Exchange. The move to 64-bit architecture, for example, will give you a great deal more application horsepower. If you have specific Service Level Agreements (SLA’s) in place which you are not meeting, Exchange 2007’s High Availability features can be the solution you need. And the new server roles will both allow you the flexibility to create a topology that fits your unique requirements and help ensure that your organization’s email compliance requirements are met.

Let’s take a look at some of these changes in detail.

Understanding Microsoft Exchange 2007 Server Roles
Server Roles (i.e. groups of features or functions) allow you to deploy only the features and services necessary on a given server. Exchange 2007 provides 5 different server roles, an expansion from the current limitation of 2. You must have at least one Client Access Server role and one Hub Transport Server role in every Active Directory site that has a Mailbox Server; the other roles are optional depending on your circumstances.

• Mailbox Server - The Mailbox Server role provides the basic message storage for your organization and includes mailboxes, public folders and other core services such as calendaring. Exchange 2007 can support up to 50 stores (i.e. mail databases) per server, deployed either as individual storage groups or bundled together into one. The Mailbox server role is the only role that can be deployed as a cluster; if you will be using clustering, you’ll need to install the Mailbox server on dedicated hardware.
• Hub Transport Server - The Hub Transport Server role provides mail transport services to your Exchange infrastructure. Every message that is sent or received by the users in your organization is processed by a Hub Transport Server, which allows you to create and enforce server-based transport rules based on your compliance requirements (including rules that flag for certain words or phrases), track mail more effectively, and provide granular journaling for individual mailboxes in any mail store.
• Client Access Server - The Client Access Server role provides mailbox access to clients accessing Exchange with POP3, IMAP4, OWA, Outlook Anywhere (previously RPC over HTTPS) or Active Sync.
• Unified Messaging Server - The Unified Messaging Server role is new to Exchange, and cannot interoperate with any previous versions of Exchange. This role integrates with your IP/VoIP gateway or IP-PBX to provide email access to voice mails as well as telephone access to messages, contacts and calendar items.
• Edge Transport Server - The Edge Transport Server role is typically deployed in your DMZ and is used to provide mail transport between Exchange and the internet. It can be used to provide anti-spam and anti-virus protection, as well as messaging security services using special rules called transport agents. This is the only server role that cannot reside on the same server as the other roles.

Taking Advantage of Exchange’s Improved High Availability
Your users expect their email to be up 24/7, as reliable and available as their telephone service. Unfortunately, delivering on this expectation has not always been easy.

In earlier versions of Exchange, multiple redundant servers could be used for particular roles, but there was no easy way to create redundant mailboxes or public folder servers. Exchange 2007 introduces two new High Availability features, with a 3rd on the way. These features all use a method called log shipping to keep independent replicas of Exchange 2007 storage groups. These features are:

• Local Continuous Replication, which creates one or more replicas of storage groups on a single non-clustered mailbox server. Logs from the mailbox server are copied and shipped to a different location on the same server, preferably on separate physical disk partitions. A copy of the mail itself is then created in the second location by replaying the log file. Mechanisms to prevent corrupted data from being replayed to the replica are included.
  
  Because it does not include the failsafe of truly redundant servers, Coyote Creek only recommends Local Continuous Replication for those who cannot afford to purchase a second server but still want to have a way to recover if the database gets corrupted.
• Cluster Continuous Replication, which provides even greater storage group availability by shipping the logs to an entirely different server. There is no single point of failure because you have two servers, each with its own set of disks. Cluster Continuous Replication requires the use of Windows Clustering Services (part of Windows 2003 Enterprise Edition) between the two servers. In conjunction with the log shipping you also get the advantages of clustering with automatic service monitoring and failover, and replication of Exchange configuration settings.
  
  If you need to roll out soon, this is the High Availability feature that we recommend.
• Standby Continuous Replication is expected to be included with Service Pack 1 for Exchange 2007, which will hopefully be available by the end of 2007. With Standby Continuous Replication data can be replicated on a per-storage-group basis to your choice of either standby servers or clusters. The targets, whether single mailbox servers or clusters, can be placed either inside the primary data center or in a remote location, ready to be manually activated if the primary server or data center fails.
  
  If you’re not in a rush to roll out, or if you don’t want to use Windows Clustering Services, Coyote Creek’s recommendation is that you wait to see if Standby Continuous Replication delivers on its promises.

Is Now the Time to Upgrade?
Regardless of what other vendors’ sales people may tell you, the upgrade cycle for this version has just started and field experience is minimal. As Microsoft Exchange consultants, we are recommending that organizations postpone upgrading to Exchange 2007 at least until Service Pack 1 is released, unless there is a truly compelling reason to upgrade immediately.

Conclusion
With all of the new features introduced in Exchange 2007, upgrading is not a simple process. Coyote Creek’s Microsoft Exchange experts have received specialized training on this new product. We can help you evaluate your needs, design your new architecture, and oversee the entire Microsoft Exchange 2007 implementation process. Give us a call if you have any questions about Microsoft Exchange 2007. We’re here to help you.

About Coyote Creek Consulting
Coyote Creek Consulting is a privately owned IT consulting firm based in Silicon Valley. We solve complex enterprise-level IT infrastructure engineering problems, always working pragmatically within real-world design thresholds.

Back to Expertise