Understanding Front-End Servers

Many organizations that implement Microsoft Outlook Web Access (OWA) based on Exchange Server 2003 or Exchange 2000 Server don't connect client browsers directly to the Exchange server on which the user's mailbox is located. Rather, a front-end Exchange server accepts the OWA connection from a client, then proxies the connection to the back-end server on which the user's mailbox resides. The front-end model offers the advantage of letting all users specify the same URL to access their mailboxes.

However, the traditional front-end model also has disadvantages, especially with regard to authentication. Let's look at how the traditional front-end server model works and examine the limitations of that model's authentication method. Then, I outline an alternative mechanism for using a variant of the front-end server configuration to implement a normalized namespace with OWA. This alternative approach avoids the drawbacks of Basic authentication while letting all users enter the same URL to access their email.

Configuring a Front-End Server
Front-end servers have two special characteristics. First, the This is a front-end server check box on the server's Properties page is selected; if the box isn't selected, the server is just another back-end server. To configure a system as a front-end server, open the Microsoft Management Console (MMC) Exchange System Manager (ESM) snap-in. Navigate to Administrative Groups/AGName/Servers/Servername, where AGName is the name of the administrative group in which the server resides and Servername is the name of the server. Right-click the server, select Properties, then select the This is a front-end server check box, as Figure 1 shows.

The second characteristic of front-end servers is that they contain no user mailboxes: All mailboxes in the environment reside on back-end servers. In fact, front-end servers generally don't even have a storage group (SG) or database. A front-end server needs a database only if the server deals with incoming SMTP connections. (The SMTP service needs a database to generate nondelivery reports—NDRs.)

No specific configuration option designates a server as a back-end server. After you configure at least one front-end server in the environment, all your Exchange servers that aren't designated as front-end servers are, by default, back-end servers.

How Front-End Servers Work
With the traditional approach to using front-end and back-end servers with OWA, a user's Web browser client establishes an HTTP-DAV connection to a front-end server. The front-end server queries an Active Directory (AD) Global Catalog (GC) server to determine which back-end server hosts that particular user's mailbox, then proxies the HTTP-DAV session to that server. All subsequent communication between the browser and the back-end server takes place through the front-end server, as Figure 2 shows.

The front-end-server model is useful because it lets you address multiple back-end mailbox servers through a single namespace. Suppose your company, Bigcorp, has multiple mailbox servers, each with its own Fully Qualified Domain Name (FQDN—e.g., server1.bigcorp.com, server2.bigcorp.com). In the absence of a front-end server, all your OWA users must know the name of the particular back-end server on which their mailbox resides (e.g., server1, server2) and specify that server's URL in their browser. If you later move some or all of those mailboxes to another server, the users whose mailboxes you move would need to learn and use the new server name.

However, when you deploy a front-end server, all your OWA users, regardless of which back-end server hosts their mailboxes, can simply enter the front-end server's host name as the OWA URL. Say that your Exchange front-end server is named webmail.bigcorp.com. If you move users' mailboxes to another back-end server, your front-end server will proxy the connection to the appropriate back-end server so long as webmail.bigcorp.com continues to resolve to the front-end server. Users remain oblivious to the complexities of the back-end server naming structure.

Using Multiple Front-End Servers
In some cases, you might want to implement more than one front-end server. If your environment is large, you might need additional front-end servers to maintain acceptable performance. Or, if you have a geographically dispersed environment, you might want to put a front-end server near each group of users. Using multiple front-end servers requires a couple of modifications to the single-front-end-server approach.

First, if you use multiple servers, the normalized URL needs to direct browser clients to one of those servers in a manner that spreads the traffic among them. For this purpose, you can use Windows NT Load Balancing Service (WLBS), DNS round-robin routing, or hardware-based load-balancing switches.

Second, you need to ensure that the URL that users enter resolves to the Exchange virtual server. The typical approach is to have OWA users append /exchange to the host address (e.g., http://webmail.bigcorp.com/exchange/). However, to avoid requiring a longer URL, you can use Microsoft IIS redirection to redirect connections to the root of the Web server.

To set up IIS redirection, perform the following steps:

Explicit vs. Implicit Logons
Understanding the types of OWA logons is central to understanding how OWA works in a front-end/back-end implementation. Users can access their mailboxes through OWA by entering either an explicit logon or an implicit logon. The URL for an explicit logon specifies the server and mailbox that the user wants to access and takes the form http://servername/exchange/username/, where servername is the name of either the OWA front-end or back-end server and username is the name of the user's Windows account. For example, an explicit URL for a user named Flint might be http://webmail.bigcorp.com/exchange/flint/.

When a front-end server receives an explicit URL from a Web browser client, the server extracts the username portion of the URL and combines it with the SMTP domain name that's associated with the Exchange virtual directory, thus rendering an SMTP address for the user. For example, when user Flint types his URL, the front-end server combines the username portion (flint) with the SMTP domain name (bigcorp.com) to obtain an SMTP user address of [email protected]. Then, the front-end server uses this SMTP address in a query to a GC to identify the back-end server on which Flint's mailbox resides. The front-end server then forwards the request unchanged to the back-end server, which processes the request as if it came directly from the Web browser.

Similarly, the front-end server routes all responses back to the Web browser client. The front-end server must use an explicit logon if only the back-end server authenticates the Web browser session.

An implicit logon URL takes the form http://servername/exchange/, where servername can be the name of either the OWA front-end or back-end server. From a usability perspective, an implicit logon is more attractive than an explicit logon because the URL is shorter and simpler. As I explained earlier, you can omit the /exchange part of the URL if you redirect the connection to the Exchange virtual directory. Thus, in its simplest form, an implicit logon URL could be something like http://webmail.bigcorp.com/.

The price you pay for the simplicity of an implicit logon URL is that the front-end server must authenticate the initial user connection to determine the user's identity before forwarding the request to the appropriate back-end server. This additional authentication can affect the performance of your domain controllers (DCs).

Authentication
A traditional front-end server/back-end server deployment handles user authentication in one of two ways:

Because the front-end server needs to determine the user's identity to forward the request to the appropriate back-end server, pass-through authentication requires an explicit logon. I don't recommend pass-through authentication for OWA access. Pass-through authentication lets anonymous HTTP requests go directly to the back-end server, thus exposing your server to rogue HTTP requests and potential Denial of Service (DoS) attacks. Pass-through authentication is also less desirable than dual authentication because most OWA users prefer to type the simplest possible URL. Figure 3 shows an explicit logon with pass-through authentication.

Dual authentication is the better approach because it allows implicit logons and their simpler URLs. Although dual authentication requires both front-end and back-end servers to perform authentication, as Figure 4 shows, users need to enter their credentials only once. After the front-end server authenticates the user's credentials, the server caches them within the client browser process. Front-end/back-end server implementations use dual authentication almost exclusively. One exception is when the front-end server can't use a remote procedure call (RPC) to communicate with a DC; this scenario might occur if a firewall separates the front-end server from the DC. In that case, pass-through authentication is necessary.

Front-end servers support only HTTP Basic authentication, which has several drawbacks. Because Basic authentication doesn't encrypt a user's credentials, I recommend that you always use Secure Sockets Layer (SSL) connections between OWA clients and front-end servers. Another drawback of HTTP Basic authentication is that it doesn't support single sign-on (SSO), which relies on Integrated Windows authentication (i.e., either NT LAN Manager—NTLM—or Kerberos authentication). Finally, with Basic authentication, users must always enter their credentials when they connect to a front-end server—even if they're already logged on to the Windows domain.

Pseudo Front-End Servers
Companies that use OWA would ideally like to be able to combine normalized namespaces and SSO. With such a combination, users could enter a simple, standard URL that would let the front-end server direct the browser session to the appropriate back-end server, and users who are logged on to the domain wouldn't need to reauthenticate. You can implement just such a combination by configuring what I call a pseudo front-end server.

A pseudo front-end server takes advantage of an Exchange server's redirection capability. A connection to a back-end Exchange server, even if the server doesn't host the desired user mailbox, results in the back-end server automatically sending a redirection to the client. The redirection includes a new URL that specifies the correct back-end server to which the client should connect. The client can then establish a direct connection to that back-end server. The server that the client originally contacted plays no further role in the communications stream between the client and the back-end server. Because a pseudo front-end server approach connects directly to a back-end server, you can use Integrated Windows authentication, which in turn supports SSO.

As Figure 5 shows, users can reference the pseudo front-end server (which is really just another back-end server) by typing a normalized URL of the form http://webmail.bigcorp.com/. You can use a pseudo front-end server in several ways. One way is to implement a pseudo front-end server solely to accept initial connections and redirect the client to the appropriate back-end server. In this case, the pseudo front-end server hosts no user mailboxes, so the server has little actual work to do. Another way is to use your pseudo front-end server to host mailboxes and perform redirections as additional workload. A third approach is to have all your back-end servers act as pseudo front-end servers and to use a load-balancing solution to share the workload across them.

Which Approach?
By understanding how OWA clients interact with Exchange front-end and back-end servers, you can choose the best approach for your environment. Pseudo front-end servers make sense when you want to use a normalized OWA namespace and Integrated Windows authentication or when you want to reduce overhead associated with multiple authentications. Traditional front-end servers still have their place, however—for example, they simplify publishing OWA services to the Web.