Issue #6: Front-end/back-end Exchange Server topology issues

Best Practices Guide: The 10 most common Exchange Server issues and how to avoid them -- part 6 of 10.

With Exchange 2000 Server, Microsoft introduced a "front-end/back-end topology." Prior to this release, Exchange servers were used in dedicated roles like mailbox servers, public folder servers, and gateway/bridgehead servers. There were no explicit role definitions or feature segregation. Outlook Web Access (OWA) could live on a separate server that didn't have Exchange Server installed.

Front-end servers are designated as such by checking the front-end option in an Exchange server's properties. A benefit of front-end servers is the ability to present a single name-space to HTTP/HTTPS (Outlook Web Access, Outlook Mobile Access, RPC over HTTP(S), Exchange ActiveSync), IMAP4 and POP3.

Any Exchange servers that are not designated as front-end servers are considered "back-end" servers. There is no explicit back-end server role that is similar to the front-end server role in Exchange 2000/Exchange 2003. But in a front-end/back-end Exchange Server topology, a back-end typically means a server that hosts mailboxes.

Exchange Server Edition: Exchange 2000 requires front-end servers to run Exchange Server Enterprise Edition, which costs significantly more than Exchange Server Standard Edition. Exchange 2003 Standard Edition offers the use of front-end servers.

Placing front-end servers in perimeter networks (DMZ): A frequently asked question is whether front-end servers can be placed in perimeter networks. While it is possible, it is not recommended.

Front-end servers need to communicate with servers on the internal network -- with the back-end servers where mailboxes reside, and with the domain controllers/global catalogs. This requires opening quite a few ports from the front-end server(s) in the perimeter network to the internal network, which poses security risks. Additionally, the front-end server is a member of the domain; it is not recommended to place member servers from internal Active Directory forests in less trusted networks.

Nevertheless, if requirements dictate placing front-end servers in perimeter networks, they should be locked down adequately. IPSec is also recommended for all communication between the front-end server(s) in perimeter networks and the back-end servers and domain controllers/global catalogs in the internal networks.

A good alternative to placing front-end servers in perimeter networks, or placing them in internal networks, is to use secure appliances and SSL VPNs.

Using SSL: In a nutshell, when deploying Exchange servers in a front-end/back-end topology, SSL should always be deployed on the front end for all protocols running on the front end and allowed access from the Internet -- ie., HTTP(S), IMAP4, and POP3. However, using SSL on back-end servers is not supported in a front-end/back-end Exchange Server topology.

Using host headers on front-end or back-end servers: Host headers are typically used with Web servers to host multiple Web sites on the same IP address and TCP port. Using host headers is likely to create problems in a front-end/back-end Exchange Server topology. Additionally, the HTTPS protocol does not lend itself well to the use of host headers.

SMTP is not "front-ended" like other protocols: An important consideration when deploying front-end Exchange servers is the use of SMTP on front ends. SMTP is not "front-ended" like HTTP(S), IMAP4 and POP3. SMTP running on a front-end server behaves no differently than SMTP running on a back-end server. A front-end server running SMTP can be made a bridgehead for SMTP and routing group connectors. However, without any connectors, email from back-end servers does not automatically flow out of front-end servers.

Deleting stores and shutting down store service on front-ends: On front-end servers not running SMTP, the Exchange Server information stores can be deleted and the information store service can be stopped and disabled. If running SMTP, the information store service must be running and a store has to be mounted to generate non-delivery reports (NDRs).


 Home: Introduction
 Issue #1: Exchange Server storage sizing and location
 Issue #2: SMTP virtual server and connector configuration
 Issue #3: Exchange recipient policies and Recipient Update Service
 Issue #4: Exchange Server messaging hygiene
 Issue #5: Exchange Server and DNS
 Issue #6: Front-end/back-end Exchange Server topology issues
 Issue #7: Exchange Server information stores and mailbox sizes
 Issue #8: Moving or removing Exchange servers
 Issue #9: Exchange Server backups and disaster recovery
 Issue #10: Exchange Server monitoring -- or lack thereof

Bharat Suneja, Microsoft Exchange MVP
Bharat Suneja is a Microsoft Certified Trainer (MCT), Exchange MVP, and Principal Exchange Architect for Zenprise, Inc., maker of real-time troubleshooting and diagnostics software for Exchange. Bharat Suneja has over 10 years of experience in IT, architecting and managing Exchange Server and Active Directory environments, ranging from small and mid-sized businesses and e-commerce companies to large ISPs and ASPs. An active writer and contributing editor for international IT publications such as PC Quest, Bharat was also a technical reviewer for Exchange Server 2003 24 Seven by Jim McBee. Visit Bharat Suneja's blog at
This was first published in February 2007

Dig deeper on Microsoft Exchange Server Performance



Enjoy the benefits of Pro+ membership, learn more and join.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: