Front-End and Back-End Topology Advantages
The front-end and back-end server topology should be used for multiple-server organizations that provide e-mail access to their employees over the Internet. Additionally, organizations that use Microsoft® Office Outlook® Web Access, POP, IMAP, and RPC over HTTP on their internal network can also benefit from a front-end and back-end server topology.
The primary advantage of the front-end and back-end server architecture is the ability to expose a single, consistent namespace. You can define a single namespace for users to access their mailboxes (for example, https://mail for Outlook Web Access). Without a front-end server, each user must know the name of the server that stores their mailbox. This complicates administration and compromises flexibility, because every time your organization grows or changes and you move some or all mailboxes to another server, you must inform the users.
With a single namespace, users can use the same URL or POP and IMAP client configuration, even if you add or remove servers or move mailboxes from server to server. Additionally, creating a single namespace ensures that HTTPS, POP, or IMAP access remains scalable as your organization grows. Finally, a single namespace reduces the number of server certificates required for SSL encryption because clients are using SSL to the same servers and using the same namespace.
Offloads SSL Encryption and Decryption
Clients such as Microsoft Office Outlook®
You can position the front-end server as the single point of access on or behind an Internet firewall that is configured to allow only traffic to the front-end from the Internet. Because the front-end server has no user information stored on it, it provides an additional layer of security for the organization. In addition, the front-end servers authenticate requests before proxying them, protecting the back-end servers from denial-of-service attacks.
Improved Public Folder Access and Features
A front-end Exchange server increases the robustness of accessing public folders, as it knows the state of back-end servers and can use multiple referrals to access public folder data. This includes system data such as calendar free/busy information. In addition, in Exchange Server 2003, a front-end Exchange server enables your users using Outlook Web Access to reply or forward to posts in public folders. Without a front-end server, public folder posts can be only read.
Increased IMAP Access to Public Folders
The IMAP protocol specification allows a server to refer a client to another server. Exchange supports this referral functionality in cases where a public folder store on a particular server does not contain the content requested and the client needs to be referred to another server. However, this requires a client that supports IMAP referrals, and most clients do not support referrals. (The University of Washington Pine client and toolkit is one example of a client that supports referrals.)
When a non referral-enabled IMAP client connects through a front-end server, the client can access the entire public folder hierarchy, as the front-end server itself will automatically handle any referrals. This makes the referral transparent to the client. For more information about non referral-enabled IMAP clients, see Request for Comments (RFC) 2221 and RFC 2193.
Multiple Protocols Supported
The front-end and back-end architecture supports RPC over HTTP, HTTP, POP, and IMAP. You can also install SMTP on the front-end server, although there are essentially no differences between SMTP on a front-end or back-end server.
The MAPI remote procedure call (RPC) protocol (that is used by Outlook on non- RPC over HTTP mode) is not proxied by the front-end server. Outlook has built-in support for handling situations where mailboxes are moved from one server to another or where content is not available on a server.