Determining Exchange Server 2007 Placement

Understanding Exchange Server 2007 Server Roles

Exchange Server 2007 introduced the concept of server roles to Exchange terminology. In the past, server functionality was loosely termed, such as referring to an Exchange server as an OWA or front-end server, bridgehead server, or a Mailbox or back-end server. In reality, there was no set terminology that was used for Exchange server roles. Exchange Server 2007, on the other hand, distinctly defines specific roles that a server can hold. Multiple roles can reside on a single server, or multiple servers can have the same role. By standardizing on these roles, it becomes easier to design an Exchange environment by designating specific roles for servers in specific locations.

The server roles included in Exchange Server 2007 include the following:

• Client access server (CAS)— The CAS role allows for client connections via nonstandard methods such as Outlook Web Access (OWA), Exchange ActiveSync, Post Office Protocol 3 (POP3), and Internet Message Access Protocol (IMAP). CAS servers are the replacement for Exchange 2000/2003 front-end servers and can be load balanced for redundancy purposes. As with the other server roles, the CAS role can coexist with other roles for smaller organizations with a single server, for example.

• Edge Transport server— The Edge Transport server role is unique to Exchange 2007, and consists of a standalone server that typically resides in the demilitarized zone (DMZ) of a firewall. This server filters inbound SMTP mail traffic from the Internet for viruses and spam, and then forwards it to internal Hub Transport servers. Edge Transport servers keep a local AD Application Mode (ADAM) instance that is synchronized with the internal AD structure via a mechanism called EdgeSync. This helps to reduce the surface attack area of Exchange.

• Hub Transport server— The Hub Transport server role acts as a mail bridgehead for mail sent between servers in one AD site and mail sent to other AD sites. There needs to be at least one Hub Transport server within an AD site that contains a server with the Mailbox role, but there can also be multiple Hub Transport servers to provide for redundancy and load balancing.

• Mailbox server— The Mailbox server role is intuitive; it acts as the storehouse for mail data in users’ mailboxes and down-level public folders if required. It also directly interacts with Outlook MAPI traffic. All other access methods are proxied through the CAS servers.

• Unified Messaging server— The Unified Messaging server role is new in Exchange 2007 and allows a user’s Inbox to be used for voice messaging and fax capabilities.

Any or all of these roles can be installed on a single server or on multiple servers. For smaller organizations, a single server holding all Exchange roles is sufficient. For larger organizations, a more complex configuration might be required.

Understanding Environment Sizing Considerations

In some cases with very small organizations, the number of users is small enough to warrant the installation of all AD and Exchange Server 2007 components on a single server. This scenario is possible, as long as all necessary components—DNS, a global catalog domain controller, and Exchange Server 2007—are installed on the same hardware. In general, however, it is best to separate AD and Exchange onto separate hardware wherever possible.

Identifying Client Access Points

At its core, Exchange Server 2007 essentially acts as a storehouse for mailbox data. Access to the mail within the mailboxes can take place through multiple means, some of which might be required by specific services or applications in the environment. A good understanding of what these services are and if and how your design should support them is warranted.

Outlining MAPI Client Access with Outlook 2007

The “heavy” client of Outlook, Outlook 2007, has gone through a significant number of changes, both to the look and feel of the application, and to the back-end mail functionality. The look and feel has been streamlined based on Microsoft research and customer feedback. Users of Outlook 2003 might be familiar with most of the layout, whereas users of Outlook 2000 and previous versions might take some getting used to the layout and configuration.

On the back end, Outlook 2007 improves the MAPI compression that takes place between an Exchange Server 2007 system and the Outlook 2007 client. The increased compression helps reduce network traffic and improve the overall speed of communications between client and server.

In addition to MAPI compression, Outlook 2007 expands upon the Outlook 2003 ability to run in cached mode, which automatically detects slow connections between client and server and adjusts Outlook functionality to match the speed of the link. When a slow link is detected, Outlook can be configured to download only email header information. When emails are opened, the entire email is downloaded, including attachments if necessary. This drastically reduces the amount of bits across the wire that is sent because only those emails that are required are sent across the connection.

The Outlook 2007 client is the most effective and full-functioning client for users who are physically located close to an Exchange server. With the enhancements in cached mode functionality, however, Outlook 2007 can also be effectively used in remote locations. When making the decision about which client to deploy as part of a design, you should keep these concepts in mind.

Accessing Exchange with Outlook Web Access (OWA)

The Outlook Web Access (OWA) client in Exchange Server 2007 has been enhanced and optimized for performance and usability. There is now very little difference between the full function client and OWA. With this in mind, OWA is now an even more efficient client for remote access to the Exchange server. The one major piece of functionality that OWA does not have, but the full Outlook 2007 client does, is offline mail access support. If this is required, the full client should be deployed.

Using Exchange ActiveSync (EAS)

Exchange ActiveSync (EAS) support in Exchange Server 2007 allows a mobile client, such as a Pocket PC device, to synchronize with the Exchange server, allowing for access to email from a handheld device. EAS also supports Direct Push technology, which allows for instantaneous email delivery to handheld devices running Windows Mobile 5.0 and the Messaging Security and Feature Pack (MSFP).

Understanding the Simple Mail Transport Protocol (SMTP)

The Simple Mail Transfer Protocol (SMTP) is an industry-standard protocol that is widely used across the Internet for mail delivery. SMTP is built in to Exchange servers and is used by Exchange systems for relaying mail messages from one system to another, which is similar to the way that mail is relayed across SMTP servers on the Internet. Exchange is dependent on SMTP for mail delivery and uses it for internal and external mail access.

By default, Exchange Server 2007 uses DNS to route messages destined for the Internet out of the Exchange topology. If, however, a user wants to forward messages to a smarthost before they are transmitted to the Internet, an SMTP connector can be manually set up to enable mail relay out of the Exchange system. SMTP connectors also reduce the risk and load on an Exchange server by off-loading the DNS lookup tasks to the SMTP smarthost. SMTP connectors can be specifically designed in an environment for this type of functionality.

Using Outlook Anywhere (Previously Known as RPC over HTTP)

One very effective and improved client access method to Exchange Server 2007 is known as Outlook Anywhere. This technology was previously referred to as RPC over HTTP(s) or Outlook over HTTP(s). This technology enables standard Outlook 2007 access across firewalls. The Outlook 2007 client encapsulates Outlook RPC packets into HTTP or HTTPS packets and sends them across standard web ports (80 and 443), where they are then extracted by the Exchange Server 2007 system. This technology enables Outlook to communicate using its standard RPC protocol, but across firewalls and routers that normally do not allow RPC traffic. The potential uses of this protocol are significant because many situations do not require the use of cumbersome VPN clients.