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:

1. Launch IIS Manager (formerly Internet Services Manager—ISM).
2. Right-click Default Web Site, then select Properties.
3. Click the Home Directory tab, then select A Redirection to a URL.
4. In the Redirect To field, type

   /exchange

   then click A directory below this one.

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 flint@bigcorp.com. 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).

   Previous  [1]  2  Next