Microsoft Exchange 2000 Server Front-End and Back-End Topology

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: June 1, 2000 | Updated : July 31, 2002

For the latest information, please see https://www.microsoft.com/exchange/

Introduction
Advantages of a Front-End and Back-End Server Environment
How Front-end and Back-end Topology Works
Deployment Considerations
Scenarios
Configuring a Front-End Server
Configuring a Back-End Server
Configuring Firewalls
Front-end and Back-end Topology Checklist
Front-end and Back-end Topology Troubleshooting Steps
Additional Resources

Introduction

Microsoft® Exchange 2000 Server supports the deployment of Exchange in a manner that distributes server tasks among front-end and back-end servers. A front-end server accepts requests from clients and proxies them to the appropriate back-end server for processing. This document discusses front-end and back-end server architecture, paying particular attention to HTTP.

Important: Most of the information in this document pertains to Exchange 2000 Service Pack 2 (SP2) or later versions. Therefore, if you are running Exchange 2000 Service Pack 1 (SP1) or earlier, you should upgrade to Exchange SP2 to take full advantage of the information within this document.

Exchange 2000 SP2 Enhancements

Exchange 2000 SP2 includes several enhancements that optimize front-end servers for perimeter networks (also known as demilitarized zone or DMZ networks). Regardless of your network configuration, you should review this section to determine if these enhancements impact your organization.

The DSAccess service in Exchange SP2 no longer uses remote procedure calls (RPCs) to perform Microsoft Windows 2000 Active Directory® directory service discovery. However, if your front-end server is configured to authenticate requests, Internet Information Services (IIS) must still have RPC access to Active Directory in order to authenticate the requests. For more information about DSAccess, see "DSAccess" later in this document.

In addition, Exchange System Attendant in Exchange SP2 no longer requires RPCs when it runs on a front-end server. Specifically, the components of System Attendant that use RPCs are no longer loaded on front-end servers in Exchange SP2; therefore, these components are disabled when you designate a server as a front-end server. The following list briefly describes these components:

DSProxy The DSProxy service refers MAPI clients (such as Microsoft Outlook® 2002) to global catalog servers for global address list lookups. DSProxy also allows MAPI clients with older versions of Outlook to access Active Directory. Without DSProxy, the front-end server can no longer determine which back-end server contains a MAPI client's mailbox. Therefore, you cannot point a MAPI client to the front-end server for the purpose of determining the user's back-end server and routing the request to the appropriate server.
Recipient Update Service The Recipient Update Service, which is responsible for updating recipients in the directory to match address lists or recipient proxy policies, no longer runs on front-end servers.
Offline Address Book Generation (OABGen) OABGen creates the off-line address book. Without the OABGen service, front-end servers no longer generate offline address books.
Group Polling System Attendant uses group polling to ensure that the local computer remains a member of the Domain Exchange Servers group. System Attendant polls the Domain Exchange Servers group and adds the local computer back to the group if it is no longer a member. Front-end servers no longer perform this function.
Mailbox Management The Mailbox Management service, which starts and stops the mailbox cleanup process according to the settings defined in Recipient Polices, no longer runs on front-end servers.
Free/Busy (madfb.dll) The free/busy service, which manages user schedules, no longer runs on front-end servers.

Assumed Knowledge

You should have an understanding of Microsoft Outlook Web Access (HTTP), Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP), and Internet Message Access Protocol version 4rev1 (IMAP) in a standard Exchange deployment, as well as basic Exchange 2000 and Microsoft Windows® 2000 Internet Information Services (IIS) concepts. Figure 1 shows simple Exchange front-end and back-end topology.

Figure 1: A simple Exchange 2000 front-end and back-end topology

Note: Exchange 2000 Server can be used only as a back-end server in a front-end and back-end configuration. However, Exchange 2000 Enterprise Server can be used as a front-end server or a back-end server in a front-end and back-end configuration. For more information about the differences between Exchange 2000 Server and Exchange 2000 Enterprise Server, see Microsoft Knowledge Base article 296614, "XADM: Differences Between Exchange 2000 Standard and Enterprise Versions."

Advantages of a Front-End and Back-End Server Environment

The front-end and back-end server topology is recommended for multiple-server organizations that use Microsoft Outlook Web Access (HTTP), POP, or IMAP and for organizations that want to provide HTTP, POP, or IMAP access to their employees over the Internet. After receiving a request, the front-end server uses Lightweight Directory Access Protocol (LDAP) to query the Microsoft Windows 2000 Active Directory® directory service and determine which back-end server holds the requested resource.

Note: A front-end server is a specially configured server running Exchange 2000. A back-end server is a server with a standard configuration running Exchange 2000. There is no configuration option to designate a server as a back-end server. The term "back-end server" refers to all servers in an organization that are not front-end servers after a front-end server is introduced into the organization.

Using a front-end and back-end deployment has the following advantages:

Single namespace The primary advantage of a 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. In addition, creating a single namespace ensures that Outlook Web Access, POP, or IMAP access remains scalable as your organization grows.
Ability to balance processing tasks between servers You can configure servers running Exchange 2000 to support Secure Sockets Layer (SSL) traffic between the client and the server to protect the traffic from third-party interception. However, encrypting and decrypting message traffic uses processor time. When SSL encryption is in use, front-end and back-end server architecture provides an advantage because the front-end servers can handle all encryption and decryption processing. In addition, you can use an SSL accelerator to further mitigate the impact encryption and decryption has on the server. An SSL accelerator improves performance by removing processing tasks from back-end servers, while still allowing data to be encrypted between the client and the server running Exchange.
Firewalls 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, you can configure the front-end server to authenticate requests before proxying them, protecting the back-end servers from denial-of-service attacks.
Increased IMAP access to public folders The IMAP protocol allows a server to refer a client to another server. Exchange 2000 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 has access to the entire public folder hierarchy. When a front-end server proxies a command to a back-end server, it automatically handles any referral response that is passed back when attempting to access a folder that is not available on the back-end server. This makes the referral transparent to the client. For more information about nonreferral-enabled IMAP clients, see Request for Comments (RFC) 2221 and RFC 2193.

The front-end and back-end architecture supports 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 server or back-end server.

Note: The MAPI remote procedure call (RPC) protocol (used, for example, by Microsoft Outlook 2002) is not supported by front-end and back-end architecture. MAPI clients have built-in support for handling situations where mailboxes are moved from one server to another or where content is not available on a server.

How Front-end and Back-end Topology Works

Although the general functionality of the front-end server is to proxy requests to the correct back-end servers on behalf of the client computers, the exact functionality of the front-end server depends on the protocol and the action being performed.

When you install Exchange on a server running Windows 2000, it integrates with IIS. It is important to note that Exchange stores configuration information in Active Directory, whereas, IIS stores configuration information in the metabase, a local configuration database shared by the protocols that IIS supports. The Exchange System Attendant service replicates relevant configuration changes made in Active Directory through Exchange System Manager to the metabase at regular intervals. You can tell when the configuration replication has happened by looking for entries in Event Viewer from the metabase update service (MSExchangeMU).

The following sections discuss the role of DSAccess in front-end and back-end topology and how front-end and back-end topology works with each of the supported protocols.

DSAccess

DSAccess is a shared Microsoft Exchange 2000 Server component that accesses and stores directory information in cache. DSAccess in Exchange 2000 SP2 uses Lightweight Directory Access Protocol (LDAP) to dynamically detect the directory servers it should contact, based on criteria such as Active Directory site configuration and Active Directory server availability. Exchange 2000 front-end servers use DSAccess to determine which server contains a particular user's mailbox, the SMTP addresses that exist for a user object, the servers that contain public folder stores, and so on.

In Exchange 2000 SP1 and earlier versions, DSAccess used RPCs to connect to a directory server so that DSAccess could discover the topology. In Exchange SP2, DSAccess uses LDAP for most operations. However, DSAccess still uses RPCs to call the NetLogon service for each domain controller and global catalog server that it discovers.

If you have a perimeter network in which you cannot allow RPC traffic between the perimeter network and the corporate network, the RPCs from DSAccess to domain controller and global catalog servers will fail. If this happens, DSAccess determines that RPC connectivity is simply blocked, and that the servers are still available. However, DSAccess continues to send the NetLogon RPC, which may affect performance. To stop DSAccess from making the NetLogon RPC, you can create a registry key. For more information about the registry keys you can create to optimize DSAccess in a perimeter network, see "Configuring DSAccess for Perimeter Networks" later in this document.

POP and IMAP

When you use a front-end server, the names of the servers that host the mailboxes are hidden from the users. Client computers connect to one host name shared by the front-end servers. As a result, moving users between servers is transparent to the users and requires no reconfiguration of client computers.

To log on, a POP or IMAP client sends the front-end server a logon request that contains the name of the mailbox to be accessed. Unlike HTTP, the front-end server does not authenticate the user; it uses Active Directory to determine which back-end server contains the user's mailbox. The front-end server then proxies the logon request to the appropriate back-end server, where authentication is performed. The back-end server then sends the results of the logon operation back to the front-end server, which returns the results of the operation back to the client. Subsequent POP or IMAP commands are handled in a similar fashion.

SMTP must be available on the front-end server to allow POP and IMAP clients to submit e-mail. You can install SMTP on the front-end server or set up a separate SMTP server. E-mail submission through SMTP on the front-end server works the same way as it does on any other server running Exchange. For more information about how to configure SMTP on a front-end server, see "Configuring a Front-End Server" later in this document.

Note: If your front-end server is accessible from the Internet, you should also configure SSL for POP and IMAP so that user authentication information and data is not passed over the Internet in clear text.

IMAP Access to Public Folders

When a non referral-enabled IMAP client connects to a back-end server, it can access only public folders that have a replica on the user's home server. To access public folders that have replicas on other servers, an IMAP client must be referral-enabled. A referral-enabled client issues special commands to an IMAP server to create a list of the public folders available to the client. When the client computer requests a public folder that does not have a local replica, the server responds to the client request with a referral URL that contains the name of the server that has the public folder. The referral-enabled IMAP client computer then creates a new connection to that server to retrieve the appropriate information.

In a front-end and back-end topology, however, the front-end server acts as a referral-enabled client, so IMAP clients connecting to the front-end server do not need to support referrals; the front-end server handles referrals for them. It transparently maps non referral-enabled client requests to their referral counterparts, making the entire list of public folders available to a non referral-enabled client. When the front-end server receives a referral response from the back-end server, it does not pass this response back to the client. Instead it follows the referral for the client and makes a connection to the appropriate back-end server that has the data. The back-end server then responds with the requested item, which the front-end server then relays back to the client.

Note: In Exchange 2000 SP1 and earlier versions, by default, IMAP4Svc and POP3Svc were dependent upon MSExchangeIS. If your configuration did not allow RPC traffic across the internal firewall (between front-end servers and back-end servers), you were required to remove the IMAP and POP3 dependency on MSExchangeIS so that you could stop the MSExchangeIS and MSExchangeSA services on the front-end server.

However, in Exchange 2000 SP2, IMAP and POP3 are no longer dependent upon the MSExchangeIS service. Therefore, you do not need to remove this dependency.

SMTP

POP and IMAP protocols are used only for receiving mail; you must configure SMTP on the front-end server before POP and IMAP clients can submit mail.

To run SMTP on the front-end server and have it accept inbound mail (mail for your domains), you must have a mailbox store mounted on the front-end server. The reason for this is that non-delivery reports (NDRs) may be generated on the front-end server, and the NDRs must be routed through the store for formatting.

Important: The mailbox store on the front-end server must not contain any mailboxes.

To configure SMTP so that POP and IMAP clients can submit mail to external domains, you need to allow relaying on the front-end server. By default, Exchange allows relaying only from authenticated clients. It is recommended that you keep this default. Clients such as Microsoft Outlook Express 5.0 and Microsoft Outlook 98, Microsoft Outlook 2000, and Outlook 2002 support SMTP authentication as well as Transport Layer Security (TLS) encryption. The following are two other options for allowing relaying:

You can allow relaying to all IP addresses; however, if your front-end server is connected to the Internet, doing this allows anyone on the Internet to use your server to send mail.
If you know the subnet clients send mail from, you can allow relaying from just those IP addresses. However, the Internet environment makes it difficult to determine such a specific set of IP addresses.

Note: If you want the front-end server to act as the bridgehead server between your company and the Internet, it is recommended that the server on the Internet that accepts mail for your domains has the ability to scan incoming messages for viruses.

HTTP (Outlook Web Access and Web Folders)

Whether generated by a browser or a specialized client, such as Windows 2000 Web Folders, HTTP requests from the client computer are sent to the front-end server. The front-end server uses Active Directory to determine which back-end server to proxy the request to.

After determining the appropriate back-end server, the front-end server forwards the request to the back-end server. The request is identical to the original request sent from the client. In particular, the HTTP host header, which matches the name of the front-end server to which the request was sent (meaning the hostname or fully qualified domain name that the user entered in the browser), remains unchanged. The front-end server contacts the back-end server using the hostname of the back-end server (for example, backend1), but in the HTTP headers of the request, the front-end server sends the host header used by the client, for example, www.adatum.com. The host header setting ensures that the appropriate back-end Exchange virtual server handles the request. The virtual servers on the back-end must be configured to handle front-end server requests. For more information about configuring virtual servers on a back-end server, see "Configuring a Back-End Server" later in this document.

For HTTP requests, the front-end server always contacts the back-end server over TCP port 80 (the default HTTP port), regardless of the port the client used to contact the front-end server. This means that:

SSL encryption is never used between the front-end and back-end servers, although the client might use it in communication with the front-end server.
HTTP virtual servers that differentiate themselves from other servers only by port number are not supported in a front-end and back-end topology. For example, if a back-end server has an HTTP virtual server listening on port 8080, a client can access that back-end server only if the client is pointed directly to the back-end server (for example, https://backend1:8080/data). A client connecting to the front-end server is not able to access this data.

The back-end server processes the HTTP request from the front-end normally, and the response is sent unchanged through the front-end server back to the client. In most cases, the back-end server handles the front-end server as if it were another HTTP client. The client, therefore, never needs to know that the request was not handled on the front-end server.

Finding User Mailboxes

To provide access to mailbox folders through HTTP, you must have a virtual directory on both the front-end and back-end servers that points to the mailboxes.

Note: User mailboxes cannot be stored on the front-end server.

When you install Exchange, a virtual directory named "Exchange" is created in the default virtual server. This directory points to the default SMTP domain for the Exchange organization. When you configure the virtual directory on the front-end server through Exchange System Manager, you can select the SMTP domain name. Users connecting to that virtual server must have an e-mail address in their object in Active Directory with the same domain. In the dialog box in which the SMTP domain is selected, the list of domains is a list of all domains for which there are recipient policies. As a result, you might see duplicates in the list; it does not matter which one you choose.

When the front-end server detects a request to a location within the mailbox store (based on the setting of the virtual server or directory), it contacts an Active Directory global catalog server in the domain using LDAP and determines which back-end server contains the user's mailbox.

Logging on to Outlook Web Access

Users can log on to Outlook Web Access through explicit logon or implicit logon.

Explicit logon There are a few URLs that users can use to connect to Outlook Web Access. The usual URL is https://server/exchange/username/. Accessing Outlook Web Access using this URL is referred to as explicit logon.

Explicit logon must be used when the front-end server is not configured to authenticate users (for more information about authentication, see "Authentication Issues" later in this document) or when a user is attempting to access a mailbox that is not his own but to which he has access.

When the front-end server receives an explicit logon request from a client, the user name is extracted from the URL and combined with the SMTP domain name associated with the virtual directory or virtual server to construct a fully qualified SMTP address. The front-end server looks up this address in Active Directory and determines which back-end server has the mailbox associated with the address. The front-end server then forwards the request to that back-end server, which processes the request as if it came directly from the client. The back-end server returns the response it generates to the front-end server, which returns it unchanged to the client.

Implicit logon If the front-end server is configured to authenticate users, then users can access their mailboxes by omitting the username from the request, and pointing their browser to https://server/exchange/. After authenticating the user, the authentication information is used to look up the mailbox associated with the user in Active Directory and the back-end server on which the mailbox is located. The URL is updated with the user name and sent to the correct back-end server. This is known as implicit logon. Implicit logon is useful only for logging on to Outlook Web Access; specialized HTTP clients generally do not use implicit logon.

Simplifying the Outlook Web Access URL

Users commonly request that a simpler URL be made available for accessing their mailbox. The following procedure provides a simple method for reducing the URL.

This procedure configures a request sent to the root of the Web server (https://server/) to redirect to the Exchange virtual directory. For example, a request to https://mail/ is directed to https://mail/exchange/, which then triggers implicit logon.

To reduce the Outlook Web Access URL

Using the Internet Services Manager, open the properties for the Default web site.
Click the Home Directory tab, and then select A redirection to a URL.
In Redirect to, type /exchange, and then click A directory below this one. (If you want your users to use SSL to access their server, you can also choose to redirect to https://mail/exchange/.)

Note: This method works only when the front-end server has authentication enabled (when implicit logon is possible). Users will still have to enter the full URL including username to access other mailboxes or content in other folders.

Finding Public Folders

Just as you must configure virtual directories for mailboxes, you must also configure virtual directories for each of the public folder trees that are to be accessible over HTTP through the front-end server.

When you install Exchange, a virtual directory called "public" is created under the default Exchange HTTP virtual server to allow access to the default (MAPI-accessible) public folder tree. When you create other public folder trees (for example, to host applications), you must also create virtual directories in Exchange System Manager to expose these trees over HTTP. Identical virtual directories must exist on each front-end server and on all back-end servers that host the public folder tree.

A request made to a URL in a public folder tree is handled differently when accessing the default (or MAPI-accessible) public folder tree than when accessing general-purpose public folders (also known as application Top-Level Hierarchies [TLH], or non-MAPI TLHs).

In both cases, however, the goal for accessing public folders is twofold:

Availability If data exists in an Exchange 2000 public folder somewhere in the Exchange organization and is accessible over HTTP, it is available to the user.
Consistency As long as the server is available and the user is authenticated, the same public folder server services every request from that user. For authenticated users, ensuring that they go to the same public folder server means that they see the same data each time they access the public folder trees through the front-end server (including status of read and unread messages, which is stored on individual servers and is not replicated between public folder servers). The fact that users always reach the same back-end server is also important for server-based applications that maintain session state, such as some built with Active Server Pages (ASP).

Public Folder Referrals

In Exchange, you can configure public folder replication on a per-folder basis. The actual public folder tree hierarchy is available on all Exchange servers in the organization, but the contents of each folder may not. This information is not stored in Active Directory but is maintained as a property on each folder in the public folder store. Therefore, special handling is required when the back-end server selected by the front-end server does not contain the contents of the folder requested by the client. See Figure 2 for an example of how public folder referrals travel through a front-end server.

The Default (MAPI) Public Folder Tree

When a client accesses the default public folder tree in Outlook Web Access, an attempt is made to maintain parity with MAPI clients such as Outlook 2002. Each mailbox store is associated with a particular public folder store somewhere in the organization (sometimes on the same server as the mailbox store, sometimes on a dedicated public folder server). The public folder store associated with the user's mailbox store is the public folder store that displays in Outlook 2002.

When a user requests a public folder in the default public folder tree through HTTP, the front-end server authenticates the user and looks up the user in Active Directory to see which public store is associated with that user's mailbox store. The front-end server then forwards the request to the user's public folder server.

This ensures that users who switch between Outlook and Outlook Web Access see the same data and take advantage of the load balancing that the administrators configured into the system.

If an authenticated user does not have a mailbox associated with it (for example, when users with accounts in a Microsoft Windows NT® 4.0 domain have access to Exchange 2000 mailboxes), the front-end server treats accesses to the default public folder tree the same way as it treats access to the general-purpose public folder trees. Also note that if the front-end server is not configured to authenticate users, requests for public folders are not load balanced.

General-Purpose Public Folder Trees

Default public folder tree servers have an association with mailbox stores because of their MAPI heritage; general-purpose public folder trees do not have such an association. As a result, requests for folders in general-purpose public folder trees are handled slightly differently than requests for folders in the default public folder tree.

When a client makes a request to access a general-purpose public folder tree, the front-end server first contacts Active Directory to find a list of all servers running Exchange 2000 in the organization that have a replica of the particular general-purpose public folder tree that the client is attempting to access. This list is filtered to remove servers running Exchange 5.5, because Exchange 5.5 does not support the HTTP extensions (Web Distributed Authoring and Versioning) that Exchange 2000 supports.

The front-end server then uses the user's authentication token in a hashing algorithm against the list of servers to ensure that:

Users are load-balanced across the available servers.
Individual user requests are always processed by the same back-end server, regardless of the HTTP client used.

Note: If you add or remove a back-end server, the output from the hashing algorithm changes, and users may be redirected to a different server from then on. For more information, see "Adding or Removing Back-End Servers" later in this document.

When Content Is Not Available on the Back-End Server

The front-end and back-end topology has special handling for times when the back-end server receives a request for a public folder for which it does not have a replica. This handling happens for folders in the default public folder store as well as folders in general-purpose public folder trees.

When a back-end server receives such a request, it returns a list of the servers that have the contents of the requested folder. This is the only case in which the back-end server does not process requests from a front-end server in the same way it processes requests directly from clients. The front-end server does not pass this information back to the client, but runs the same hashing algorithm against the new list of servers again, to ensure load balancing. As a result, in organizations that use partial replicas of public folder trees, the front-end server may have to perform two HTTP requests to satisfy the client's single request. However, in processing the client's request, the front-end server caches information about which servers have the content, allowing the front-end server to avoid extra requests when data in the same folder is accessed in the future.

The caches maintained by the front-end server substantially reduce the number of queries sent to Active Directory and back-end servers for both public and private folder accesses. Cache information expires after ten minutes and is also reset when changes in server configuration are detected.

Figure 2: Public folder referral through a front-end server

An HTTP client authenticates against the front-end server and requests /public/PublicFolder2.
The front-end server authenticates the user against Active Directory and requests the location of the user's default public folder store.
Active Directory tells the front-end server that the user's default public folder store is on Server1.
The front-end server sends the client request to Server1.
Server1 tells the front-end server that it does not have the contents of /public/PublicFolder2, but Server2 and Server3 do.
The front-end server performs a hashing algorithm against the list of servers with the content (in this case, Server2 and Server3). The results of the hash in this case turn out to be Server2, so the front-end server forwards the request to Server2.

Note: A hashing algorithm applies a given number (in this case, the user's security token) and uses it to generate a position in a list so that the distribution of all possible inputs is even over the list.
Server2 returns the contents of /public/PublicFolder2 to the front-end server, which then sends the contents to the HTTP client.

Back-End Server Downtime

If a back-end server is down for maintenance or is otherwise inaccessible over HTTP, the front-end server cannot connect to it. The front-end server marks that server "unavailable" for a period of 10 minutes and sends the request to a different server if there are other servers available; the request fails if no other servers are available. While the back-end server is unavailable, the front-end server automatically directs requests to other servers. Therefore, after a back-end server returns to production, it might be inaccessible through the front-end server for as long as 10 minutes, because the front-end server might still have that back-end server marked as unavailable.

Adding or Removing Back-End Servers

The goal of the hashing algorithm is load balancing; however, a condition of the algorithm is that the distribution of users across servers is dependent on the number of servers. Therefore, if the list of servers hosting the content for a public folder changes because of the addition or removal of a server, the result of the hashing algorithm may direct the user to a new server for future requests. Typically, when the server processing a user's request changes the user cannot tell that anything physical changed, with the exception of the following:

Users may observe that the read or unread state of messages is reset.
Users of Web-based applications (running in general-purpose public folder trees) that maintain session state may need to restart their application session if they use the application during the transition period.

Therefore, it is recommended that administrators inform their users before adding or removing public folder servers.

At a high level, the hashing algorithm works as follows: Two back-end servers, numbered 1 and 2, with a particular public folder tree are deployed. Then, if six different users—A, B, C, D, E, and F—try to access data, the front-end server distributes their requests over the two servers as follows:

Users A, B, and C get their data from server 1.
Users D, E, and F get their data from server 2.

Note: This load balancing is done transparently—users do not know which back-end server is actually handling the request.

Then another server is added, server 3. Now the users are distributed as follows:

Users A and B get the data from server 1.
Users C and D get the data from server 2.
Users E and F get the data from server 3.

In this example, users A, B, and D did not change servers, but users C, E, and F did.

Authentication Issues

The front-end server handles authentication in two ways: either the front-end server authenticates the user itself, or it forwards the request anonymously to the back-end server. Either way, the back-end server also performs authentication.

It is recommended that you use dual authentication, in which you configure both front-end and back-end servers to authenticate users, particularly when the front-end server is exposed to the Internet. For more information about dual authentication, see "Dual Authentication" later in this section.

If you have a locked-down perimeter network, in which RPCs are blocked and it is impossible for the front-end server to authenticate users, you can use pass-through authentication. However, it is important to understand the risks of using pass-through authentication. For more information about pass-through authentication, see "Pass-Through Authentication" later in this section.

Exchange HTTP front-end servers support only HTTP 1.1 basic authentication between client computers and front-end servers, as well as between front-end and back-end servers. Basic authentication is a simple authentication mechanism defined by the HTTP specification that lightly encodes the user's user name and password before sending it to the server. To achieve real password security in a front-end and back-end topology, SSL encryption should be used between the client and the front-end server.

Note: Front-end servers do not support:

Windows Integrated Security (which includes both NTLM and Kerberos authentication).
HTTP 1.1 Digest authentication.

Basic authentication does not support single sign on. Single sign on is when a user logs on to a computer running Windows, the user authenticates against a domain, and then the user can access all resources and applications in the domain without re-entering his or her credentials. Microsoft Internet Explorer versions 4.0 and later allow single sign on for Web applications, including Outlook Web Access, if the server being accessed has Integrated Windows authentication enabled. Because front-end servers do not support Integrated Windows authentication, when users access HTTP applications, the front-end server always prompts them for authentication and they must re-enter their credentials, even if they already used Windows to log on. Users only have to enter credentials once per browser session, however, because their credentials are cached in the browser process.

Dual Authentication

In dual authentication, both front-end and back-end servers are configured to authenticate users with HTTP basic authentication. Basic authentication is the only form of authentication that front-end servers support. Back-end servers support both basic authentication and Integrated Windows Authentication. To enable connections through a front-end server, basic authentication must be enabled on both the front-end server and back-end servers.

HTTP basic authentication carries the authentication information in every request from the client to the front-end server; the front-end server then passes the information to the back-end server. The authentication information in the request is sufficient for both servers; therefore, after the front-end server requests authentication information from the user, the back-end server receives the same information and does not need to request it from the user again.

You should configure front-end servers to perform authentication whenever possible. If you cannot enable authentication on the front-end server, implicit log on does not work, and you cannot load balance public folder requests. You can use explicit logon can to gain access, regardless of how authentication is configured.

Note: Exchange relies on IIS to perform the authentication for HTTP requests. IIS uses RPCs to directory servers to perform authentication. If RPCs are not allowed between the front-end server and the directory server, you must use pass-through authentication. For more information about how to enable pass-through authentication and the risks of doing so, see "Pass-Through Authentication" later in this section.

Pass-Through Authentication

In pass-through authentication, the front-end server is configured with anonymous authentication, so it does not ask the user for an authorization header. The front-end server forwards the user's request to the back-end server, which asks the user for authentication. The back-end server's request for authentication and the user's response are routed unchanged through the front-end server.

Warning: When you use pass-through authentication, anonymous HTTP requests go directly to the back-end server where they are authenticated. You should use pass-through authentication only if the front-end server cannot authenticate, for example, in a locked down perimeter network where RPCs are not allowed across the intranet firewall. You should carefully consider the consequences of allowing RPCs to cross the intranet firewall versus allowing anonymous requests to reach back-end servers. For more information, see "Scenarios" later in this document.

When pass-through authentication is used, the front-end server is not able to load balance public folder requests, because it does not have the authentication token on which to perform a hashing algorithm. Additionally, implicit logon will not work. Users have to enter the full URL including their user name to log on.

User Logon Information

When authenticating against a front-end server, by default, the user must enter his or her user name in the following format: domain\username. You can configure the front-end server to assume a default domain so that users do not need to remember their domain.

An additional option for authentication is to configure a user principal name (UPN) for users. This allows users to enter their e-mail address as their user name. For more information, see "Configuring a Front-End Server" later in this document.

Note: If you want to set a default domain or configure a UPN, you should upgrade to Exchange 2000 SP1 or later. For more information, see Microsoft Knowledge Base article 267936, "XIMS: Directory Service to Metabase Service May Not Replicate the Default Logon Domain for Virtual Servers."

Remote Procedure Calls (RPCs) in Front-end and Back-end Topology

Exchange 2000 SP1 and earlier versions used RPCs to perform Active Directory service discovery (which is performed by DSAccess) and to authenticate users (which is performed by IIS). In Exchange 2000 SP2, DSAccess no longer uses RPCs to perform Active Directory service discovery. However, IIS still uses RPCs to authenticate requests on the front-end server. Therefore, if you enable basic authentication on the front-end server, you must open certain RPC ports. For more information about opening RPC ports on the intranet firewall, see "Configuring an Intranet Firewall" later in this document.

Stopping RPC Traffic Across the Intranet Firewall

Corporations that have perimeter networks often restrict the type of traffic that passes from the perimeter network into the corporate intranet.

Without RPC access to Active Directory servers, the front-end server cannot authenticate clients. Therefore, features that require authentication on the front-end server (such as implicit logon and public folder tree load balancing) will not work. Public folder access is possible, but the front-end server cannot load balance the requests because the front-end server cannot determine the identity of the user. Without the user's authentication token, the front-end server cannot perform the load balancing hashing algorithm. As a result, all anonymous requests for a public folder are routed to the same back-end server.

If open RPC ports are not allowed between the perimeter network and the corporate intranet, you must use pass-through authentication. With pass-through authentication, the front-end server passes requests to the back-end anonymously, and then the back-end server performs the authentication.

Note: If you run IMAP or POP on the front-end servers with the RPC ports closed, you must ensure that MSExchangeIS and MSExchangeSA are not running on the front-end server.

Deployment Considerations

When deploying a front-end and back-end topology, you must take into account several factors: expected load, hardware needs, administrative overhead, load balancing and security to name a few. The following section goes over these considerations in more detail.

Recommended Server Configurations and Ratios

Server configuration depends on many factors, including the number of users for each back-end server, the protocols used, and the expected load on the system. The configuration of particular models of servers should be done in consultation with a hardware vendor or consultant. For more information about server sizing, see the capacity and topology calculator at https://go.microsoft.com/fwlink/?Linkid=1716.

As a general rule, one front-end server is reasonable for every four back-end servers. However, this number is provided only as a suggested ratio, not as a rule. Use this information only as a starting point. Front-end servers do not need large or particularly fast disk storage, but should have fast CPUs and a large amount of memory. There is no need to back up the disks on the front-end server unless you choose to enable SMTP, because SMTP commits queued mail to the local disk. For POP, IMAP, and HTTP, no user data is stored on the drive.

For more information about hardware requirements for front-end and back-end servers, see the following technical papers:

Microsoft Exchange 2000 Front-End Server and SMTP Gateway Hardware Scalability Guide at https://go.microsoft.com/fwlink/?Linkid=1713.
Microsoft Exchange 2000 Server Back-End Mailbox Scalability at https://go.microsoft.com/fwlink/?Linkid=1711.

Load Balancing

In a corporate or hosting environment, you may want to load balance the front-end servers. Windows 2000 provides load balancing through Network Load Balancing (NLB). Other load-balancing mechanisms include domain name service (DNS) round robin and a hardware load-balancing solution.

Windows NLB works by clustering two or more servers that represent the cluster with a single IP address. Each computer receives traffic to its own unique IP address and the shared IP address. Each member of the cluster performs a hashing algorithm to map incoming clients to one of the members of the cluster based on the client IP address, port, and other information. When a packet arrives, all servers or hosts perform the same hashing algorithm, and the output is one of the hosts. That host then responds to the packet. The mapping does not change unless the number of hosts in the NLB cluster changes. The configuration of every server in the NLB cluster must be same, otherwise clients may experience different behavior depending on which server they are routed to.

Note: NLB has no health monitoring; if the World Wide Web Publishing Service on a front-end server is not running, for example, NLB continues to send requests to that server. Microsoft Application Center 2000 supports load balancing including health monitoring as well as many other features. For more information about Application Center, see the Microsoft Application Center Web site at https://go.microsoft.com/fwlink/?Linkid=591

Whatever load-balancing solution you use, you should ensure that each user is always sent to the same front-end server for the duration of a session. This makes use of the caching and connection state information already maintained on the front-end server. In NLB, this is referred to as "client affinity." Many hardware solutions also have this ability.

Reducing Virtual Server Creation

In some circumstances, it might be important to reduce the number of virtual servers created on the back-end servers. You should not reduce the number of virtual servers unless you fully understand how HTTP virtual servers work. You can reduce virtual server creation by either of two methods.

Make an analysis of the users and data on each back-end server to determine if users will ever be directed to that particular server. If a back-end server contains mailboxes for only adatum.com, then there is no need for that back-end server to have a virtual server for contoso.com. If users from contoso.com are later added to that back-end server, however, then an administrator will need to create a virtual server for contoso.com.

Similarly, you only need to create virtual directories for resources your users will need access to. On a server that has no public store, the public virtual directory is not necessary.

Securing Communication: Client to Front-end Server

To secure data transmitted between the client and the front-end server, it is recommended that the front-end server be SSL-enabled. In addition, to ensure that user data is always secure, access to the front-end server without SSL should be disabled (this is an option in the SSL configuration). When using basic authentication, it is critical to protect the network traffic by using SSL to protect user passwords from network packet sniffing.

You do not need to configure SSL on back-end servers when using a front-end server, because the front-end server does not support using SSL to communicate with back-end servers. You can configure SSL on the back-end servers for use by clients that are directly accessing them.

Back-end servers sometimes need to generate absolute URLs, such as a list of URLs for the messages in a user's inbox. If SSL is used between the client and the front-end server, the back-end server needs to know this, so it can formulate URLs using HTTPS instead of HTTP. If the SSL decryption is done on the front-end server, the front-end server knows SSL was used, and it notifies the back-end server of this by passing an HTTP header that says, "Front-End-Https: on" in all requests to the back-end server.

If there is a separate server between the client and the front-end server that performs the SSL decryption, that server must be able to pass the "Front-End-Https: on" header to the front-end server, which then passes it to the back-end server. As an alternative, you can configure SSL between the SSL decryption server and the front-end server. However, if you added that separate server to offload the additional traffic caused by SSL encryption and decryption, this method defeats that purpose. This method allows that separate server to filter the traffic.

Tip Ensure that the Windows 2000 License Logging Service is running on the front-end server. IIS does not allow more than 10 simultaneous SSL connections unless this service is running.

SSL Accelerators

There is a decrease in performance involved in setting up and tearing down SSL connections, so you may want to investigate adding an SSL accelerator to your front-end and back-end topology.

SSL accelerators generally come in two forms:

A card you can put on each front-end server. One example is the Compaq AXL200.
A separate device or computer you place between the clients and the front-end servers. Examples are the F5 BigIP SSL accelerator and the Microsoft Internet Security and Acceleration Server 2000 Service Pack 1 (ISA). These accelerators support adding the "Front-End-Https: On" header for Outlook Web Access.

Note: For information about configuring the ISA server for Outlook Web Access, see Microsoft Knowledge Base article 307347, "Secure OWA Publishing Behind ISA Server May Require Custom HTTP Header."

Accelerator cards are generally used directly on the front-end server, and they offload the encryption and decryption overhead, increasing the throughput of each connection and decreasing the amount of work the software on the server needs to do.

External accelerator devices sit between the clients and the front-end servers. Traffic coming from the client is decrypted on the accelerator device and sent to the front-end server unencrypted. Likewise, traffic from the front-end server is sent to the accelerator device unencrypted, and then it is encrypted for transmission to the client.

The most important factor to consider when choosing what type of SSL accelerator to use is the number of front-end servers in your topology. If you have a small number of front-end servers, adding SSL accelerator cards to each of them is a simple, cost-effective way to offload SSL duties. Because the SSL decryption is done on the front-end server, there is no need for extra configuration of the "Front-End-Https: on" header for Outlook Web Access.

For a large number of front-end servers, the cost of additional accelerator cards and the administrative cost of storing and configuring SSL certificates on each server eventually ceases to be cost effective. In this case, a separate SSL accelerator device may be a more cost effective option for your topology because it needs to be configured only once, regardless of the number of front-end servers. These devices generally cost more than an accelerator card, so weigh the options in your own topology to determine which to use. Keep in mind that for Outlook Web Access, an external SSL device must have the ability to notify the front-end server that SSL was used with the "Front-End-Https: on" header.

Securing Communication: Front-end to Back-end

HTTP communication between the front-end and back-end servers is not encrypted. When the front-end and back-end servers are in a trusted physical or switched network, this is not a concern. However, if front-end and back-end servers are kept in separate subnets and network traffic must pass over unsecured areas of the network, it is recommended that this traffic be encrypted to protect passwords and data.

IP Security (IPsec)

Windows 2000 supports IPsec, which is an Internet standard that allows a server to encrypt any IP traffic, except traffic that uses broadcast or multicast IP addresses.

With IPsec you can:

Configure two servers running Windows 2000 to require trusted network access.
Exchange data that is protected from modification (using a cryptographic checksum on every packet).
Encrypt any traffic between the two servers at the IP layer.

In a front-end and back-end topology, you can use IPsec to encrypt traffic between the front-end and back-end servers that would otherwise not be encrypted.

IPsec Protocols

The method in which data is secured using IPsec depends on which protocol is used: Authentication Header (AH) or Encapsulating Security Payload (ESP). With AH, the packets are not encrypted; AH adds a checksum to the IP packet. AH guarantees that the packet came from the expected host, was not impersonated, and was not modified in transit. AH uses IP protocol 51. ESP, which uses IP protocol 50, encrypts the entire contents of the IP packet. Both forms of IPsec provide a reliable and trusted communication channel that an attacker cannot easily insert data into or interrupt.

This kind of encryption affects the performance on both the front-end and back-end servers; the precise extent to which it affects performance, however, depends on the type of encryption used.

IPsec Policy

The IPsec policy filter you configure on the back-end servers should be designed to apply only to traffic initiated by the front-end server that is sent to TCP port 80 on a remote server. You should configure IPsec on the back-end servers so that they respond appropriately when they receive a request for IPsec communication. However, the back-end servers should not require that all communication from all clients be encrypted using IPsec.

Windows 2000 has three IPsec policies installed by default. Select the "Client (respond only)" policy for the back-end server. With this policy enabled on the back-end server, the front-end server can use IPsec to communicate safely with the back-end server, while other clients (including MAPI clients like Outlook 2002) and servers can communicate with the back-end server without needing to use IPsec.

IPsec with Firewalls and Filtering Routers

When a firewall or filtering router is used between the front-end and back-end servers, the filters must allow IPsec to pass through it. First, HTTP (TCP port 80) is no longer required and should be blocked. Second, the IPsec negotiation port at 500/UDP is required. 500/UDP is the well-known Internet assigned port for the Internet Key Exchange (IKE) Standard, which is defined in RFC 2409. This standard uses UDP and not TCP to avoid the security weaknesses of relying on TCP connections. IKE provides strong security for the negotiation data packets. It establishes and maintains the IPsec connections, called security associations.

In a perimeter network, you may want the increased security of IPsec without losing the ability to filter traffic for security reasons. In this case, you can set up an IPsec tunnel from the front-end server to the internal firewall, and then a separate tunnel from the internal firewall to the back-end server. This approach secures the information on the wire while allowing you to use filtering or intrusion detection software or techniques on the traffic before it reaches your internal network.

Note: IPsec encryption occurs after the application (in this case, Exchange) passes the request to Windows to send to the server. So, as far as Exchange is concerned, the request is made over HTTP using TCP port 80. However, before the traffic leaves the server, it is intercepted, possibly encrypted if ESP is configured, and sent over a separate channel (IP protocols 50 or 51). Thus, the encryption is transparent to the Exchange applications running on each server, and the fact that the data never used port 80 is not an issue to these applications.

Service Packs: Upgrading Front-End and Back-End Servers

When new service packs are released, upgrading your front-end servers is a straightforward process. It is simpler than upgrading a back-end server, because there is no user data stored on the front-end server. As long as there are multiple front-end servers, taking one server offline does not mean an interruption in service for the user. If you have multiple front-end servers that are load balanced, you can remove the front-end server you want to upgrade from the load-balancing cluster, upgrade it, and add it back to the load-balancing cluster with no interruption in service to users.

Upgrading Considerations for Outlook Web Access

If Outlook Web Access is deployed in your organization, you should upgrade every front-end server in the organization before you upgrade any back-end servers. This is because of the way Outlook Web Access is built. At a high level, Outlook Web Access data is comprised of two parts: templates and controls. Templates are things such as forms (e-mail messages, calendar items, and other forms). Controls are files such as DHTML behaviors, JScript files, style sheets, and images that are stored in the /exchweb virtual directory in IIS.

When a user accesses Outlook Web Access through the front-end server, the templates actually come from the back-end server, and the controls come from the front-end server. The templates come from the back-end for performance reasons. The controls come from the front-end server because there is no mechanism to proxy a request for data that is not in the Exchange store from a front-end server to a back-end server. This is not a problem as long as the front-end and back-end servers run the same version and service pack of Exchange.

A problem arises when the servers run different versions of service packs. If a template on a back-end server references a control on a front-end server, and the front-end server is running a previous service pack, the control the back-end server is referencing might not exist. As a result, Outlook Web Access does not work for users whose mailboxes are on the upgraded back-end server.

The reverse situation does not have the same problem. If you upgrade a front-end server first, then users see templates from the back-end server. These templates reference the previous versions of the controls, which still exist on the front-end server, because the files are versioned and not removed in an upgrade. To address this issue, it is recommended that you upgrade all front-end servers before upgrading any back-end servers.

Scenarios

This section discusses common scenarios where Exchange front-end and back-end topology is deployed. The scenarios can be broadly divided into intranet and extranet scenarios, with the intranet scenarios focused on performance and scalability and the extranet scenarios focused on security.

In each scenario, the following topics are discussed:

Scenario What is the scenario, and when does it apply?
Setup instructions How to set up the scenario, in general terms. (Specific configuration instructions appear later in this document.)
Discussion What is special about this scenario? How does it work? What additional information is needed to make decisions about this scenario?
Issues Caveats or limitations of this scenario.

Standard Front-End/Back-End Topology

Figure 3 illustrates a basic front-end and back-end topology.

Figure 3: A standard front-end and back-end topology

Scenario

A company wants to maintain a single namespace for their e-mail servers but cannot fit all of their users on a single server.

Setup Instructions

Set up a standard collection of servers running Exchange.
Set up a single server running Exchange configured as a front-end server.
Direct HTTP, POP, and IMAP users to this server, not to their back-end servers.
Ensure that all virtual directories and servers are configured identically on all front-end and back-end servers.

Discussion

This is the default configuration. You do not need to perform any steps other than the standard front-end and back-end configuration steps.

Issues

If the network permits connections between the client and the back-end servers, there is nothing to prevent users from circumventing the front-end server and connecting directly to the back-end server. If this is undesirable, you must change the network routing configuration or the back-end server configuration to prevent direct connections between a client and a back-end server.

To configure the back-end server to only allow connections to a virtual server from a certain group of IP addresses

In Internet Services Manager, right-click the virtual server, and then click Properties.
Click the Directory Security tab. In IP address and domain name restrictions, click Edit. Select Denied Access, and then click Add to allow specific IP addresses or a range of IP addresses (using a network ID and a subnet mask) to access that virtual server.

Web Farm

Figure 4 illustrates a Web farm scenario.

Figure 4: Front-end and back-end topology in a Web farm

Scenario

A corporation is rolling out Outlook Web Access to 200,000 users. The goal is to have a single namespace (for example, https://mail) in which users can reach their mailboxes. In addition, for performance reasons, the corporation wants to avoid having a bottleneck at the front-end server or a single point-of-failure, so they want to spread the load over multiple front-end servers by using Network Load Balancing. This scenario is referred to as a "Web Farm."

Setup Instructions

Set up a group of servers as back-end servers in the same forest.
Distribute users over the servers.
Set up another group servers as front-end servers and configure Network Load Balancing on all these servers.

Discussion

For information about how to set up Network Load Balancing, see the Windows online documentation. Configuring Exchange on the front-end servers does not require any special steps.

Issues

As mentioned earlier, the load-balancing solution you use should ensure that each user is always sent to the same front-end server for the duration of a session.

Scenarios With Firewalls

The following scenarios all require some sort of firewall. You can use software and hardware solutions as a firewall. The minimum requirement of the firewall that protects the server from the Internet is port filtering. Port filtering restricts the type of network traffic that comes through the firewall by allowing only information sent to specific ports through the firewall.

IP filtering is also supported by many firewalls. IP filtering improves the reliability of the firewall by allowing you to restrict traffic through the firewall to only the front-end server.

Front-End Server Behind the Firewall

Figure 5 illustrates a front-end and back-end topology where the front-end server is behind the firewall.

Figure 5: A simple Exchange firewall topology

Scenario

To achieve security and still provide access to Outlook Web Access, POP, or IMAP from the Internet, a corporation wants to place the Exchange system behind the corporate firewall.

Setup Instructions

Set up a standard Exchange front-end and back-end environment in the corporation.
Configure a firewall between the front-end server and the Internet. For more information about how to configure an Internet firewall for use with a front-end server running Exchange, see "Configuring Firewalls" later in this document.

Discussion

Because the entire configuration is inside the firewall, Exchange does not require any special configuration. After a request comes through the firewall to the front-end server, the front-end server returns a response without any configuration changes.

IP address filtering is highly recommended to limit requests through the firewall to only those going to the front-end server (or servers) running Exchange and block requests through the firewall to other servers in the organization.

Perimeter Network

Figure 6 shows an Exchange 2000 front-end server in a perimeter network.

Figure 6: Exchange 2000 front-end server in a perimeter network

Scenario

In a perimeter network scenario, a corporation places the front-end server between two separated firewalls. The first firewall separates the front-end server from the Internet and allows requests only to that front-end server. The second firewall separates the front-end server from the internal network. The systems between the two firewalls lie in what is known as a perimeter network. This is also referred to as a demilitarized zone (DMZ). A perimeter network configuration provides extra security by ensuring that even if the front-end server is compromised, the intruder is still isolated from the rest of the corporation, giving the corporate security team time to detect and neutralize the intrusion.

Setup Instructions

Configure the outer (Internet) firewall for a firewall in this environment, limiting access to only the ports required and to only the designated front-end server.
Configure the inner (intranet) firewall to have certain ports open to support authentication, DNS, and Active Directory access. The exact list depends on the balance of security and features that each corporation chooses.

For information about how to configure Internet and intranet firewalls, see "Configuring Firewalls" later in this document.

Discussion

Typically, corporations that have deployed and standardized the use of a perimeter network have restrictions on the type of network traffic allowed through the intranet firewall by limiting the network ports that are enabled on the intranet firewall. However, the front-end server requires certain ports to operate fully.

Issues

Some corporations that have deployed perimeter network topologies for other services have policies that restrict computers located within the perimeter network from initiating connections with servers inside the corporate intranet. A front-end server running Exchange is not supported in this configuration, because it must initiate connections.

Additionally, in this configuration, it is recommended that you completely configure the front-end server before the intranet firewall is put in place or locked down. Configuring settings on the front-end server in Exchange System Manager requires the System Attendant (MSExchangeSA) service to be running so that the configuration information can replicate to the metabase. The MSExchangeSA service requires RPC access to the back-end servers, and RPCs often are not allowed across an intranet firewall in a perimeter network.

The DSAccess component in Exchange 2000 SP2 is redesigned to provide better support for perimeter networks in which RPC traffic is not allowed across the internal firewall. However, there are two additional registry keys that you should set on the front-end server to disable NetLogon and the Directory Access ping:

NetLogon DSAccess connects to Active Directory servers to check available disk space, time synchronization, and replication participation by using NetLogon service with RPC. If you do not allow RPC traffic across the internal firewall, you should stop the NetLogon check by creating the DisableNetlogonCheck key on the front-end server.
Directory Access Ping By default, Directory Access uses Internet Control Message Protocol (ICMP) to ping each server to determine whether the server is available. However, in a perimeter network, there is no ICMP connectivity between the server running Exchange and the domain controllers. Therefore, Directory Access determines that every domain controller is unavailable. Directory Access then discards old topologies and performs new topology discoveries, which impact server performance. To avoid these performance issues, you should turn off the Directory Access ping on the front-end server by creating the LdapKeepAliveSecs registry key for the Windows implementation of LDAP (wLDAP).

For information about how to set these registry keys, see "Configuring DSAccess for Perimeter Networks" later in this document.

Configuring a Front-End Server

A front-end server must be part of the same Exchange organization as the back-end servers, and as a result, it must be a member of the same Windows 2000 forest. A front-end server is actually an ordinary server running Exchange until it is configured as a front-end server. A front-end server must not host any users or public folders.

To set up a front-end server

Install the server running Exchange in the organization.

Note: Only servers running Exchange 2000 Server Enterprise Edition can be configured as front-end servers.
Use Exchange System Manager to go to the server object, right-click the server object, and then click Properties.
Select This is a front-end server, and then close the page.
To begin using the front-end server do one of the following:
- Restart the computer.
- Stop and restart the HTTP, POP, and IMAP services.

HTTP-Specific Configuration

In the simplest topology, you do not need to do any extra configuration on the front-end servers. If you are hosting multiple domains, organizations, or public folder trees, however, you will need to create additional virtual servers or directories.

Hosting Multiple Domains

There are two main ways to configure the HTTP virtual servers when hosting additional domains. You need to have a virtual server or directory that is unique for each domain you are hosting so that users with e-mail addresses from those domains will be able to log on to the appropriate virtual server or directory.

In the following methods, your default Exchange domain is microsoft.com, and you are hosting mailboxes for adatum.com and public folders for contoso.com. The methods describe how to configure your front-end and back-end servers for these hosted companies.

Method One: Additional Virtual Servers

In this method, you create a virtual server for each domain you host. You have three HTTP virtual servers on each server running Exchange: one is the default Exchange virtual server, one is the virtual server for adatum.com's mailboxes, and one is the virtual server for contoso.com's public folder tree. This method allows for maximum flexibility in determining the resources available to each domain.

Each virtual server (as well as any virtual directories pointing to mailboxes) must be associated with a specific SMTP domain. By associating each virtual server with a specific SMTP domain, Exchange allows users with SMTP addresses from that domain to log on through that virtual server. Exchange Setup associates the default Exchange HTTP virtual server with the default Exchange domain (microsoft.com in this example), and this cannot be changed.

For any additional virtual servers you create, you need to associate the virtual server with the appropriate domain. If you do not specify the appropriate domain, users will be unable to log on to this front-end server unless they also have an e-mail address from the default domain.

You must specify the appropriate domain because each HTTP virtual server must have a unique combination of IP address, host header, and port. If you try to create a virtual server that has the same combination of these settings as another, it will not start. In a non-encrypted session, when a client connects to the server, the packet the server receives contains the IP address, the requested port, and the host header. The server uses this information to find the appropriate virtual server to handle the request. The server then takes the user's authentication credentials and looks up the user in Active Directory. If the user does not have an e-mail address with the SMTP domain associated with this virtual server, the server will deny access unless the user also has an e-mail address with the default domain of the Exchange organization (mydomain.com), in which case the request is handled by the default Exchange HTTP virtual server. Many administrators managing a hosting environment, however, choose to allow only one e-mail address per user—that of the hosted domain—in which case the domain must be uniquely configured.

Note: When SSL is used, the host header is contained in the encrypted portion of the packet; only the IP address and port are available in the unencrypted portion. To determine which SSL certificate to use to decrypt the data, the server must be able to determine the appropriate virtual server with a unique combination of IP address and port. Therefore, when SSL is used (such as when the front-end server is deployed on the Internet), the IP address must be specifically associated with the appropriate virtual server.

After you create the additional virtual server, you need to create the Exchange and Public virtual directories underneath that virtual server. For specific steps for creating virtual directories, see "Creating Virtual Directories" later in this document.

Method Two: Additional Virtual Directories

The second way of configuring multiple hosted domains is to add a virtual directory for each domain. For access to mailbox stores, you must specify the domain in the properties of the virtual directory. For access to public stores, you must specify the root public folder. For your first hosted company, adatum.com, add a virtual directory under the default Exchange HTTP virtual server, with a name that uniquely identifies the hosted company, such as Adatum. In the properties of the virtual directory, click Modify, and then select adatum.com as the SMTP domain, just as you did for the virtual server. Users from adatum.com will now be able to go to https://mail.microsoft.com/adatum/ to access their mailboxes.

Add another virtual directory for Contoso, and this time select Public folder and specify the public folder root for Contoso. Users from contoso.com will now be able to go to https://mail.microsoft.com/contoso/ to access their public folders.

The main advantage to this method has to do with SSL. SSL certificates are issued for a specific host or domain name—in this case, mail.microsoft.com. When you have multiple virtual servers with different domain names (for example, mail.microsoft.com and mail.adatum.com), you need one SSL certificate for each domain, and that costs money. Because, in method two, clients access their data through a single domain—https://mail.microsoft.com—you save on the cost of the certificates as well as the additional step of configuring SSL on each virtual server.

Creating HTTP Virtual Servers

You must use Exchange System Manager, not Internet Services Manager when you create virtual servers.

To create a virtual server

In Exchange System Manager, in the HTTP Protocols container for the front-end server, right-click HTTP, and then select New Virtual Server.

Note: For a name, it is recommended that you use something following the form of "adatum.com (Front End)." Consistent naming of the new virtual servers ensures that each virtual server's purpose and associated domain can be easily determined. The name of the virtual server is used only for identification purposes and does not affect its operation.
Click Modify, and then specify the domain.

Note: The list of domains in Select SMTP Domain is pulled from the domains of the SMTP addresses in the Exchange organization's recipient policies, so if you have more than one recipient policy for the same domain, you will see duplicates in this dialog box. It does not matter which one you choose.
Click Advanced, and then add host headers that define all the names a client might use to contact this front-end server.

Note: If a front-end server is used internally and externally, it is recommended that you list both a hostname and a fully qualified domain name.

Leave the TCP ports at the default unless you have some reason to change them.

Note: If you change the TCP ports, HTTP clients will need to know the specific port to connect to (for example, https://mail.adatum.com:8080/exchange).

You can leave the IP address field at the default, All unassigned, or restrict it to the particular IP address assigned to the server. You might want to configure a specific IP address for the virtual server if you know SSL will be used to connect to this front-end server.

Creating Virtual Directories

To create virtual directories

In Exchange System Manager, right-click the HTTP virtual server, click New, and then click Virtual Directory.
Name the virtual directory.

Note: The name you use is important, because this is what the client must enter into their browser (for example, https://mail.microsoft.com/*virtualdirectoryname*).
Right click the virtual directory you just created, and then click properties. Specify whether or not the directory is for access to a mailbox or a public store. If the directory is for access to a mailbox store, the SMTP domain must be specified. If the virtual directory is for access to a public folder store, then select the appropriate public folder to act as the root public folder for this virtual directory.

If you are hosting multiple domains, as explained in the first method for adding virtual servers, where a virtual server is created for each domain, it is recommended that you use the standard virtual directory names—"Exchange" for mailbox access (make sure to specify the domain again) and "public" for public folder store access. Do not create an "exadmin" virtual directory on any additional virtual servers; this is used only by System Manager and is not proxied by the front-end server.

Configuring Authentication

It is highly recommended that you use dual-authentication, in which both front-end and back-end servers are configured to authenticate users.

However, if you have a locked down perimeter network in which RPCs are not allowed across the intranet firewall, and it is impossible for the front-end server to authenticate users, you can use pass-through authentication.

To configure authentication

Start Exchange System Manager: Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
Go to the "Exchange" or "Public" virtual directory.
Right-click the "Exchange" or "Public" virtual directory, and then click Properties.
Click the Access tab, and then click Authentication.
Do one of the following:
- To configure the front-end server to authenticate users (as in dual authentication), select the Basic authentication check box.
- To configure pass-through authentication, select the Anonymous access check box, and then clear the Basic authentication check box.

Configuring The Front-End Server To Assume a Default Domain

You can configure the front-end server to assume a default domain so that users do not need to remember their domain.

To configure the front-end server to assume a default domain

Start Exchange System Manager on the front-end server: Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
Right-click the "Exchange" virtual directory, and then click Properties.
Click the Access tab, and then click Authentication.
Select the Basic authentication check box, and then type the domain in the Default domain box. (See Figure 7.)
Repeat this procedure for the "Public" virtual directory.

Note: Ensure that the System Attendant service is running so that the configuration settings replicate from the directory to the IIS metabase (you can also restart Exchange System Attendant to force replication).

After replication is complete, users can log on with just their user name and password; no domain is required.

Figure 7: Configure the front-end server to assume a domain

Configuring a User Principal Name (UPN)

An additional option for authentication is to configure a user principal name (UPN) for users. This allows users to enter their e-mail address as their user name. To configure UPN, in the Authentication Methods dialog box (see Figure 7), in the Default domain box, type a backslash (\) . After you configure a UPN in the properties of the virtual directories on all front-end and back-end servers, users can authenticate by using user@domain.com as their user name.

Note: If you want to set a default domain or configure UPN, you should upgrade to Exchange 2000 SP1 or later. For more information, see Microsoft Knowledge Base article 267936, "Directory Service to Metabase Service May Not Replicate the Default Logon Domain for Virtual Servers."

Disable Unnecessary Services

Not all Exchange services are required on a front-end server, depending on the protocols being exposed and whether or not you will be making configuration changes after the initial setup. To stop and disable services, use the Services snap-in in the Microsoft Management Console (MMC). The following list shows the Exchange services required; stop and disable all other Exchange services:

HTTP: No Exchange-specific services required. However, the World Wide Web Publishing service (w3svc) must be running in order for Outlook Web Access to work.
POP: Exchange POP (POP3Svc), Exchange Information Store service (MSExchangeIS), and Microsoft Exchange System Attendant Service (MSExchangeSA).
IMAP: Exchange IMAP (IMAP4Svc), MSExchangeIS, and MSExchangeSA.
SMTP: MSExchangeIS and MSExchangeSA
Exchange System Manager: MSExchangeSA
Routing Engine: Microsoft Exchange Routing Engine Service (RESvc). The routing engine must be running on all Exchange servers.

Dismount and Delete Public and Mailbox Stores

You must dismount and delete the public folder stores on the front-end server before you place the server in production.

If you are not using SMTP on the front-end server, you should also dismount and delete the mailbox stores. (If you are using SMTP, a mailbox store is required, but the mailbox store must not contain any mailboxes. For more information, see "SMTP" earlier in this document.)

The Information Store service will not start unless there is at least one storage group defined. If you need to leave the Information Store service running, do not delete the storage group on the front-end server after deleting the private and public stores.

Note: If the MSExchangeIS service is not running, you will not be able to make configuration changes using Internet Services Manager (ISM). If you must make configuration changes using ISM (for example, configuring SSL encryption), be sure to complete these steps before you remove the mailbox and public folder stores.

Configuring Network Load Balancing

You may want to load balance the front-end servers. Do not use Windows Clustering Services to load balance the front-end servers because there is no data stored on the front-end servers; each front-end is essentially a copy of every other, so failing over is not useful. Use Network Load Balancing to evenly spread client requests across multiple front-end servers.

See the Windows 2000 online documentation for information about configuring Network Load Balancing.

Configuring SSL

The steps to configure SSL for POP, IMAP, and SMTP differ from HTTP.

To configure SSL for POP, IMAP, and SMTP

In Exchange System Manager, right-click the virtual server, and then click Properties.
Click the Access tab, and then click Certificate.
Follow the wizard, using the guidelines in the online help to request and install the SSL certificate.

To configure SSL for HTTP

In Internet Services Manager, for the default Exchange HTTP virtual server, right-click Default Web Site, and then click Properties.
Click the Directory Security tab, and then select Server Certificate.
Follow the wizard, using the IIS documentation as a reference, to request and install the SSL certificate. HTTP SSL is configured individually for each virtual server or web site, so if you create additional HTTP virtual servers in System Manager, you will need to configure SSL for each server (or web site as it is referred to in Internet Services Manager).

Configuring SMTP

Mail for Internal Domains

If you want the front-end server to accept mail inbound from the Internet, the front-end server needs to know the domains for which it should accept mail. Adding recipient policies for each of your domains tells all servers in the Exchange organization to accept mail for those domains. Additionally, you must enable anonymous access for other SMTP servers on the Internet to successfully route mail to your organization.

Mail for External Domains

In the default configuration, SMTP mail submitted to your server addressed to domains external to your Exchange organization will be denied, because relaying is turned off for all anonymous access (authenticated users can still send mail to any external domain, however). Users who try to anonymously submit mail to external domains get an error, such as "550 5.7.1 Unable to relay for suzan@adatum.com." The clients must be configured to use SMTP authentication.

If you do not want to require clients to use SMTP authentication, you can change the server to allow unauthenticated relaying. On the properties of the SMTP virtual server, go to the Access tab and click Relay.

If you choose to require SMTP authentication for mail submitted by your users from the Internet, you should also require SSL for clear text or basic authentication, so that corporate usernames and passwords are not sent out unencrypted. Configure SSL for basic authentication in the Properties of the SMTP virtual server: On the Access tab, click Authentication, and then select Requires TLS encryption.

Configuring DSAccess for Perimeter Networks

Important: This section contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.

Warning: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. For information about how to edit the registry, view the "Change Keys and Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Information" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. If you are running Windows NT or Windows 2000, you should also update your Emergency Repair Disk (ERD).

To disable NetLogon and the Directory Access ping, create the following registry keys on the front-end server:

NetLogon DSAccess connects to Active Directory servers to check available disk space, time synchronization, and replication participation by using the NetLogon service with RPC. If you do not allow RPC traffic across the internal firewall, you should stop the NetLogon check by creating the DisableNetlogonCheck registry key on the front-end server.

To create the DisableNetlogonCheck registry key

Start Registry Editor (Regedt32.exe).
Locate and select the following key in the registry:

HKEY_LOCAL_MACHINE System\ CurrentControlSet\ Services\ MSExchangeDSAccess

On the Edit menu, click Add Value, and then add the following registry value:

Value name: DisableNetlogonCheck Data type: REG_DWORD Value data: 1

Directory Access Ping In a perimeter network, you must also create a registry key on the front-end server to prevent Directory Access from pinging domain controllers. Create the LdapKeepAliveSecs registry key on the front-end server.

To create the LdapKeepAliveSecs registry key

Start Registry Editor (Regedt32.exe).
Locate and select the following key in the registry:

HKEY_LOCAL_MACHINE System\ CurrentControlSet\ Services\ MSExchangeDSAccess

On the Edit menu, click Add Value, and then add the following registry value:

Value name: LdapKeepAliveSecs Data type: REG_DWORD Value data: 0

Configuring a Back-End Server

Exchange configuration is stored in Active Directory on a per-forest basis, which means that all front-end and back-end servers must be in the same forest. Back-end servers can be accessed directly if required, with no effect on the behavior of the front-end and back-end configuration.

If you did not configure any extra virtual servers or directories on any front-end servers, then you do not need to configure any on the back-end server. If you created additional virtual servers or directories on any front-end servers, however, you must add matching virtual servers and directories on the back-end servers.

The specific back-end server configuration steps depend on whether the back-end server is hosted on a cluster or not. The steps below describe configuration for non-clustered back-end servers. For information about configuring clustered back-end servers, see the technical paper Deploying Exchange 2000 Server Clusters with Service Pack 2 at https://go.microsoft.com/fwlink/?Linkid=6275.

Note: When back-end servers are clustered, you cannot access the cluster HTTP virtual directory using the name of the actual physical clustered computer. You must use the virtual group name.

Creating and Configuring HTTP Virtual Servers on Back-End Servers

In the "Configuring a front-end server" section, two methods for configuring your front-end and back-end topology when hosting multiple domains were discussed. Method one involves setting up a virtual server for every hosted domain. Method two involves setting up a virtual directory for every hosted domain. Back-end configuration differs slightly depending on which method you chose. Additionally, if you create additional virtual servers on the front-end servers for other reasons (such as to host web applications), you must add similarly configured virtual servers to any back-end servers on which the Web applications will exist.

Method One: Additional Virtual Servers

In method one above, we configured an extra virtual server for adatum.com, with an Exchange virtual directory beneath it. To configure the back-end servers for this method, you will need to create an additional virtual server. The steps are slightly different from those for configuring the front-end server.

To configure additional virtual servers on a back-end server

Give the virtual server a consistent name, such as "adatum.com (Back-End)".
Click Modify, and then select the appropriate domain from the list (adatum.com in this case).
Click Advanced, and then add the appropriate host headers (mail.adatum.com in this case). The address through which the client browser accesses the front-end server is forwarded by the front-end server to the back-end server, so the back-end server must be aware of every name a client might use to reach the front-end server (for example, https://mail, https://mail.adatum.com, and so forth).

Note: on the back-end server, the TCP port must be 80, because this is the only port used for HTTP communication between front-end and back-end servers, regardless of the port used by the client to communicate with the front-end server. You can leave the SSL port at the default setting.

Method Two: Additional Virtual Directories

In method two above, we created an extra virtual directory for adatum.com. On your back-end servers, configure the virtual directory structure to be exactly the same as the virtual directory structure on the front-end servers. As with the front-end servers, ensure that you specify the appropriate SMTP domain for virtual directories associated with mailbox stores.

Configuring Authentication on Back-End Servers

By default, HTTP virtual servers on the back end are configured to allow both basic authentication and Integrated Windows Authentication. You should use this default configuration.

Basic authentication passes the user name and password across the network in a lightly encoded (not encrypted) format. Integrated Windows Authentication refers to a package of authentication mechanisms (such as NTLM and Kerberos) that are more secure and do not send the password across the network in clear text. Only Internet Explorer supports Integrated Windows Authentication.

If you configure the front-end HTTP virtual servers to authenticate requests, the front-end server requests authentication information from the user. The user sends authentication information to the front-end server, which authenticates the user and then passes on the information to the back-end server. The back-end server then authenticates the user, but it does not need to request authentication information from the user again.

Configuring Firewalls

This section discusses the configuration of firewalls for use with an Exchange front-end and back-end topology and additional configuration required on the front-end servers in these environments.

Configuring an Internet Firewall

In Internet scenarios, a firewall is required between the corporation and the Internet. The firewall must be configured to allow requests to certain IP addresses and over certain TCP/IP ports. Table 1 lists the ports required for different services.

Table 1 Ports required to be open on the Internet firewall

Internet Firewall Mail Protocols

Port number/transport	Protocol
443/TCP	HTTPS (SSL-secured HTTP)
993/TCP	SSL-secured IMAP
995/TCP	SSL-secured POP
25/TCP	SMTP

Configuring an Intranet Firewall

When you set up a perimeter network, a firewall must be configured between the front-end server and the corporate intranet.

Basic Protocols

In all cases, all the supported protocol ports must be open on the inner firewall. The SSL ports do not need to be open, because SSL is not used in communication between the front-end server and the back-end servers. Table 2 lists the ports required for the intranet firewall.

Table 2 Protocol ports required for the intranet firewall

Intranet Firewall—Mail Protocols

Port number/transport	Protocol
80/TCP	HTTP
143/TCP	IMAP
110/TCP	POP
25/TCP	SMTP
691	Link State Algorithm routing

Active Directory Communication

To communicate with Active Directory, the Exchange front-end server requires LDAP ports to be open. Both TCP and UDP are required: Windows 2000 on the front-end server will send a 389/UDP LDAP request to a domain controller to check if it is available for use; the LDAP traffic after that uses TCP. Windows 2000 Kerberos authentication is also used; therefore, the Kerberos ports must also be open. Both TCP and UDP are required for Kerberos as well: Windows uses UDP/88 by default, but when the data is larger than the maximum packet size for UDP, it uses TCP. Table 3 lists the ports required for communicating with Active Directory.

Table 3 Ports required for Active Directory communication and Kerberos

Intranet Firewall—Active Directory Communication

Port number/transport	Protocol
389/TCP	LDAP to Directory Service
389/UDP
3268/TCP	LDAP to Global Catalog Server
88/TCP	Kerberos authentication
88/UDP

There are two sets of optional ports that can be opened in the firewall. The decision to open them depends on the policies of the corporation. Each decision involves tradeoffs in the areas of security, ease of administration, and functionality.

Domain Name Service (DNS)

The front-end server needs access to a DNS server to correctly look up server names (for example, to convert server names to IP addresses) Table 4 lists the ports required for access.

If you do not want to open these ports, you must install a DNS server on the front-end server and enter the appropriate name to IP mappings for all of the servers it might need to contact. If you choose to install a DNS server, it is essential to keep these mappings up to date when changes are made to the organization.

Table 4 Ports required for access to DNS server

Intranet Firewall—DNS

Port number/transport	Protocol
53/TCP	DNS Lookup
53/UDP

Note: Most services use UDP for DNS lookups and only use TCP when the query is larger than the maximum packet size. The Exchange 2000 SMTP service, however, uses TCP by default for DNS lookups. For more information, see Microsoft Knowledge Base article 263237, "XCON: Windows 2000 and Exchange 2000 SMTP Use TCP DNS Queries."

Remote Procedure Calls (RPCs)

DSAccess no longer uses RPCs to perform Active Directory service discovery. However, if your front-end server is configured to authenticate requests, IIS must still have RPC access to Active Directory in order to authenticate the requests. Therefore, you must open the RPC ports that are listed in Table 5.

Disallowing RPC Traffic

If you have a locked-down perimeter network in which it is impossible for the front-end server to authenticate users, you may not be allowed to open the RPC ports that are listed in Table 5. Without these RPC ports, the front-end server cannot perform authentication. You can configure the front-end server to allow anonymous access, but you should understand the risks of doing so. For more information, see "Authentication Issues" earlier in this document.

Restricting RPC Traffic

If you want the features that require RPCs, such as authentication or implicit logon, but do not want to open the wide range of ports above 1024, you can configure your domain controllers and global catalog servers to use a single known port for all RPC traffic. For more information about restricting RPC traffic, see Microsoft Knowledge Base article 224196, "Restricting Active Directory Replication Traffic to a Specific Port."

The registry key will need to be set on any server that the front-end server may contact with RPCs, such as a global catalog server. Set the registry key in the above article to a specific port such as 1600. On the firewall between the perimeter network and your intranet, you need to open only two ports for RPC communication—the RPC portmapper (135) and the port you specify (1600 as listed in Table 5).

Table 5 RPC ports needed for authentication

Intranet Firewall—RPCs: Service Discovery and Authentication

Port number/transport	Protocol
135/TCP	RPC port endpoint mapper
1024+/TCP or 1600/TCP	All service ports (Example) RPC service port, if restricted

IPsec

Table 6 lists the necessary requirements for allowing IPsec traffic across the intranet firewall, if you choose to use IPsec. You only need to allow the port that applies to the protocol you configure; for example, if you choose to use ESP, it is only necessary to allow IP protocol 50 across the firewall.

Table 6 Ports required for IPsec

Intranet Firewall—IPsec

Port number/transport	Protocol
IP protocol 51	Authentication Header (AH)
IP protocol 50	Encapsulating Security Payload (ESP)
500/UDP	Internet Key Exchange (IKE)
88/TCP	Kerberos ()
88/UDP

Front-end and Back-end Topology Checklist

Configure Front-End Server(s)
	Step 1. Install Exchange: · Install Exchange on the front-end server. · Designate the server as front-end in the server properties. · Restart the server, or stop and restart the necessary services.
	Step 2. Configure HTTP virtual servers or directories on the front-end server for access to mailbox and public stores as necessary: For additional virtual servers, specify the SMTP domain, IP address, and host headers or ports. Leave the Basic authentication check box selected. For additional virtual directories for public stores, specify the appropriate public store root. For additional virtual directories for mailbox stores, specify the SMTP domain.
	Step 3. Disable unnecessary services: · Stop any services that are not required for the protocols you are using.
	Step 4. Important Dismount and delete the public folder store.
	Step 5. Dismount and delete the mailbox store if necessary: · If you are not running SMTP, dismount and delete all mailbox stores. · If you are running SMTP, leave a mailbox store mounted, but make sure the mailbox store does not contain any mailboxes.
	Step 6. Set up front-end server load balancing if necessary: · Install load balancing on all front-end servers. · (Recommended) Enable client affinity.
	Step 7. Configure SSL (recommended): · Option 1: Configure SSL on the front-end server. · Option 2: Set up a server between the client and the front-end server to offload SSL decryption.
	Step 8. If you use a perimeter network and do not want to allow RPCs across the intranet firewall: · Disable authentication on the front-end server. Note: If you disable authentication on the front-end server, you allow anonymous requests to reach your back-end servers. · Create the DisableNetlogonCheck registry key and set the REG DWORD value to 1 · Create the LdapKeepAliveSecs registry key and set the REG DWORD value to 0
	Step 9. If required, create an IPSec policy on the front-end servers.
Configure Back-end Servers
	Create and configure HTTP virtual servers or directories to match the front-end: For additional virtual servers, set the host headers and IP addresses as appropriate. The TCP port must be left at 80. Make sure the Basic authentication and Integrated Windows Authentication check boxes are both selected. For additional virtual directories for public folder stores, specify the appropriate public folder store root, to match the root configured on the front-end server. For additional virtual directories for mailbox stores, specify the SMTP domain.
Configure Firewalls
	Step 1. Configure the Internet firewall (between the Internet and the front-end servers): · Open TCP ports on the Internet firewall for the mail protocols: 443 for HTTPS 993 for SSL-enabled IMAP 995 for SSL-enabled POP 25 for SMTP (including TLS)
	Step 2. If using a perimeter network, configure the intranet firewall: · Open TCP ports on the intranet firewall for the protocols you are using: 80 for HTTP 143 for IMAP 110 for POP 25 for SMTP 691 for Link State Algorithm routing protocol · Open ports for Active Directory Communication: TCP port 389 for LDAP to Directory Service UDP port 389 for LDAP to Directory Service TCP port 3268 for LDAP to Global Catalog Server TCP port 88 for Kerberos authentication UDP port 88 for Kerberos authentication · Open the ports required for access to the DNS server: TCP port 53 UDP port 53 · Open the appropriate ports for RPC communication: TCP port 135 - RPC endpoint mapper TCP ports 1024+ - RPC service ports · (Optional) If you want to limit RPCs across the intranet firewall, edit the registry on servers in the intranet to limit RPC traffic to a specific port. Then open the appropriate ports on the internal firewall: TCP port 135 – RPC endpoint mapper TCP port 1600 (example) – RPC service port Warning Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. For information about how to edit the registry, view the "Change Keys and Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Information" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. You should also update your Emergency Repair Disk (ERD). If you use IPsec between the front-end and back-end, open the appropriate ports. If the policy you configure only uses AH, there is no need to allow ESP, and vice versa. UDP port 500 – IKE IP protocol 51 – AH IP protocol 50 - ESP

Front-end and Back-end Topology Troubleshooting Steps

Problems experienced with front-end and back-end architectures are often caused by the inability of network traffic to flow from the front-end server to the correct back-end servers because of incorrect configurations on the server or the network routers. In all cases, event log entries may help troubleshoot the particular issue. When you troubleshoot reported or observed problems with a front-end and back-end topology, step through the issues below to see if they might apply to your problem.

Troubleshooting Tools

When troubleshooting problems in a front-end and back-end topology, the following tools can help you:

Network Monitor Use Network Monitor to monitor the traffic and determine exactly what is happening between the front-end and the other servers. Set up a client to connect to the front-end server and monitor the traffic between the front-end servers and the intranet servers. You can also use Network Monitor to monitor between the client and the front-end server if SSL is not being used.
Event Viewer Check the event logs on the front-end and back-end servers and any other involved servers (DNS, global catalog, and other servers). There may be entries that provide a clue as to what the problem is.
RPC Ping To test RPC connectivity between the front-end server and a global catalog or back-end server, use the Rpings.exe tool. It is available in the support directory of the Exchange CD.
Telnet Use telnet.exe to attempt to connect directly to the user's back-end server using the port that the mail protocol uses. For example, if Outlook Web Access is not working when you connect to the front-end server, try using telnet from the front-end server to port 80 on the back-end server.

General

Make sure that all of the appropriate services are started on the front-end and back-end servers. This includes the relevant Exchange services as well as the World Wide Web Publishing service and SMTP service, if applicable.
If you have a perimeter network, make sure that the appropriate ports are open on the internal firewall as described in the "Configuring Firewalls" section earlier in this document.
Ensure that the front-end server can successfully connect to the global catalog servers and DNS server. This is particularly important when the front-end server is in a perimeter network. Telnet from the front-end server to the appropriate ports on the servers in the intranet—389, 3268, 53, and other ports.

Note: Windows 2000 telnet uses TCP/IP and cannot be used to connect to UDP ports.
If you are unable to connect to the back-end server from the front-end server using the hostname with any protocol, try using the IP address. If this works, then verify you can connect to the DNS server the front-end server is using. Also verify that the name to IP mapping is correct in DNS.
If the front-end server is configured with the list of domain controllers and global catalog servers in the registry, verify that the front-end can reach each of those servers exactly as specified in the registry entry.
Make sure the combination of IP address and host header is unique for each virtual server.
If you have a load balancing solution for the front-end servers, ensure that the shared IP can be reached from client computers.
Administration: If you want to use Exchange System Manager, ensure that the System Attendant service is running. Also recall that you cannot use the Internet Services Manager after deleting the stores on the front-end server.
If users complain that the state of read and unread messages in public folders fluctuates, consider the following:
1. Was a back-end public folder server added or removed?
2. Is authentication enabled on the front-end?
3. Are any back-ends that host the folder down?

Logon Failures

If your users have problems logging on to POP, IMAP or Outlook Web Access, consider the following common problems:

Is the user entering the username in the proper format—domain\username, username@domain.com, username?
If UPN or a default domain is configured and the user is entering the username in the proper format, verify that the default domain setting is correct on all virtual servers and virtual directories in Exchange System Manager. Verify the same setting in Internet Services Manager. If the domain is correct in Exchange System Manager but not in Internet Services Manager, there is most likely a problem replicating settings from Exchange System Manager to Internet Services Manager. Try restarting the MSExchangeSA service to fix this.
Verify that the host headers for the HTTP virtual server match exactly what the client browser is using to connect to the server. Verify that the host headers are correct and there are no typing mistakes on the back-end and front-end virtual servers and directories.
If you have multiple virtual servers for multiple domains, make sure that the SMTP domain is properly configured.
Ensure that the user attempting to log on has an e-mail address for the domain configured on the virtual server the user is accessing.

HTTP-Specific Troubleshooting Tips

Internet Explorer version 5.0 and later versions use WebDAV (Web distributed authoring and versioning) to talk to the server running Exchange. Some older firewalls or proxy servers do not support the HTTP verbs used and block them, which causes Outlook Web Access to fail. Possible solutions for why OWA fails follow:

Upgrade the firewall to a version that does support WebDAV. The Web site at https://www.webdav.org/other/proxy.html contains a list of many proxy servers, whether or not they support WebDAV, and whether or not patches are available to enable support for this standard. Note that with Internet Explorer 5.0, Outlook Web Access requires HTTP verbs that are not part of the core WebDAV standard, such as SEARCH. These verbs are necessary for Outlook Web Access to function properly. If your firewall blocks them, look in the documentation for the firewall to see if it has a way of entering additional verbs to support; Squid Proxy Server is one that has this ability.
Use Internet Explorer 4.0 or another browser that does not use WebDAV.
Configure SSL to encrypt the traffic so that the firewall or proxy server cannot monitor the traffic and detect that WebDAV is being used.

Some of the error messages that are returned when using HTTP through the front-end server can also help target investigations. Depending on the configuration of your browser, the error number might be obvious or might be somewhere in the text of the response. Errors you many encounter include:

401 Unauthorized This error means that the user entered an incorrect user name or password. Remember that unless you have configured it otherwise, authentication requires a user name of the format domain\password.
403 Forbidden: SSL required The server may be configured to require SSL, so that clients who connect without using https:// get a page with this error. This is configured on a virtual server or virtual directory basis. In Internet Services Manager, right click on the directory or web site and choose Properties. On the Directory Security tab, click Edit under Secure Communications.
404 File Not Found This error means that the URL entered is not valid. Look for typographical errors in the name of the user or other parts of the URL. If there are no errors, check the configuration of the HTTP virtual server on the back-end server for typographical errors in the names of virtual directories that were created.
Another scenario in which a client browser gets a 404 error is if the user attempts to log on to a virtual server, but he does not have the e-mail address for which that virtual server is configured. However, if a user has an e-mail address for the default Exchange domain (the one specified in the default recipient policy), he will always be able to log on to the default Web site.
Additionally, note that it takes a few minutes for mailboxes to be created, and information to be replicated to all domain controllers and global catalogs in the domain or forest. You may not be able to log on to Outlook Web Access immediately after the mailbox is created; you may have to wait a short amount of time. One way to force mailbox creation is to log on to the mailbox with Outlook, or send a message to the mailbox.
500 Internal Server Error This error occurs most often in a locked-down perimeter network scenario and is a sign that the front-end server cannot connect to domain controllers through a closed-down intranet firewall. Check the registry keys carefully against the actual configuration of the organization.
503 Service Unavailable The front-end server thinks the back-end server is down or cannot reach it. This error is generated in two situations. First, if the Information Store service on a back-end server is stopped or the user's database is dismounted, then the back-end server returns this error. Second, the front-end server generates this error if it is unable to contact a valid back-end server. This could be because the back-end server is down for maintenance or because of network issues between the front-end and back-end servers. Use telnet.exe to verify that the front-end server can connect to the back-end servers.

Additional Resources

The following technical papers, Microsoft Knowledge Base articles, and other resources provide valuable information regarding Exchange 2000 front-end and back-end topology.

Technical Papers

Front-end and Back-end Scalability:
Microsoft Exchange 2000 Front-End Server and SMTP Gateway Hardware Scalability Guide at https://go.microsoft.com/fwlink/?Linkid=1713
Microsoft Exchange 2000 Server Back-End Mailbox Scalability at https://go.microsoft.com/fwlink/?Linkid=1711
IPsec:
IP Security for Windows 2000 Server at https://go.microsoft.com/fwlink/?LinkId=7197
Exchange 2000 clustering:
Deploying Exchange 2000 Server Clusters with Service Pack 2 at https://go.microsoft.com/fwlink/?Linkid=6275

Microsoft Knowledge Base Articles

The following Microsoft Knowledge Base articles are available on the Web at https://support.microsoft.com/:

Differences between Exchange 2000 Server and Exchange 2000 Enterprise Server:296614 — XADM: Differences Between Exchange 2000 Standard and Enterprise Versions
Configuring ISA Server:307347 — Secure OWA Publishing Behind ISA Server May Require Custom HTTP Header
Configuring UPN Logons: 267936 — XIMS: Directory Service to Metabase Service May Not Replicate the Default Logon Domain for Virtual Servers
DNS Lookups with Exchange 2000 SMTP service:263237 — XCON: Windows 2000 and Exchange 2000 SMTP Use TCP DNS Queries
Directory Lookup Information:250570 — XADM: Directory Service Server Detection and DSAccess Usage
Restrict RPC Traffic to a Specific Port:224196 — Restricting Active Directory Replication Traffic to a Specific Port

Other Useful Resources

Microsoft Exchange Server Web Site: https://www.microsoft.com/exchange/
Security Services Web site: https://go.microsoft.com/fwlink/?Linkid=1706
Internet Standard Documents
HTTP 1.1: RFC 2616 (https://www.ietf.org/rfc/rfc2616.txt)
POP: RFC 1939 (https://www.ietf.org/rfc/rfc1939.txt)
IMAP: RFC 2060 (https://www.ietf.org/rfc/rfc2060.txt)
IMAP Referrals: RFC 2221 and RFC 2193
Server Sizing Calculator: https://go.microsoft.com/fwlink/?Linkid=1716
Microsoft Application Center Server 2000: https://go.microsoft.com/fwlink/?Linkid=591
DSAccess registry keys:
https://support.microsoft.com/default.aspx?scid=kb;en-us;320529
https://support.microsoft.com/default.aspx?scid=kb;en-us;320228

For more information: https://www.microsoft.com/exchange/

Does this paper help you? Give us your feedback. On a scale of 1 (poor) to 5 (excellent), how do you rate this paper?

exchdocs@microsoft.com

Microsoft Exchange 2000 Server Front-End and Back-End Topology

On This Page

Introduction

Exchange 2000 SP2 Enhancements

Assumed Knowledge

Advantages of a Front-End and Back-End Server Environment

How Front-end and Back-end Topology Works

DSAccess

POP and IMAP

SMTP

HTTP (Outlook Web Access and Web Folders)

Deployment Considerations

Recommended Server Configurations and Ratios

Load Balancing

Reducing Virtual Server Creation

Securing Communication: Client to Front-end Server

Securing Communication: Front-end to Back-end

Service Packs: Upgrading Front-End and Back-End Servers

Scenarios

Standard Front-End/Back-End Topology

Web Farm

Scenarios With Firewalls

Configuring a Front-End Server

HTTP-Specific Configuration

Disable Unnecessary Services

Dismount and Delete Public and Mailbox Stores

Configuring Network Load Balancing

Configuring SSL

Configuring SMTP

Configuring DSAccess for Perimeter Networks

Configuring a Back-End Server

Creating and Configuring HTTP Virtual Servers on Back-End Servers

Configuring Authentication on Back-End Servers

Configuring Firewalls

Configuring an Internet Firewall

Configuring an Intranet Firewall

Front-end and Back-end Topology Checklist

Front-end and Back-end Topology Troubleshooting Steps

Troubleshooting Tools

General

Logon Failures

HTTP-Specific Troubleshooting Tips

Additional Resources

Technical Papers

Microsoft Knowledge Base Articles

Other Useful Resources

Additional resources