Supporting HTTP Access

Whether generated by a browser or a specialized client, 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. Apart from specific header information that indicates the request was passed through a front-end server, the request is almost the same as 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. For more information about configuring virtual servers on a back-end server, see Configuring a Back-End Server.

For HTTP requests, the front-end server always contacts the back-end server over TCP port 80 (the default HTTP port), regardless of whether the client contacted the front-end server through port 80 or 443 (the SSL port). This means that:

• HTTP virtual servers on the Exchange front-end server can listen only on port 80 (HTTP) or 443 (HTTPS).

  Note

  No other ports other than port 80 and port 443 can be used for HTTP virtual servers on the Exchange front-end servers.

• SSL encryption is never used between the front-end and back-end servers, although the client should use it to communicate 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 cannot 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. This whole process is not visible to the client, which just interacts with the front-end server. The client is unaware of how the request was handled internally.

Finding User Mailboxes

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

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 additional virtual directories on the front-end server through Exchange System Manager, you can select the SMTP domain name. In Exchange 2000 Server SP3 and Exchange Server 2003, users connecting to that virtual server must have an e-mail address in their list of SMTP proxy addresses on their object in Active Directory with the same domain. In Exchange Server 2003 SP1, users can override the SMTP domain by specifying the SMTP address in the URL (for explicit logon), or just use an implicit logon. For more information see "Logging on to Outlook Web Access" later in this topic.

In the dialog box where the SMTP domain is selected, the list of domains is a list of all domains for which there are recipient policies. Therefore, you might see duplicates in the list; it is not important which one you select.

When the front-end server detects a request to a location in 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 Lightweight Directory Access Protocol (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 using either implicit logon or explicit logon.

Implicit Logon

If the front-end server is configured to authenticate users, users can access their mailboxes by omitting the username from the request, and pointing their browser to their mailbox virtual directory. The usual URL is 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.

Exchange 2000 Server SP3 and Exchange Server 2003

Implicit logon makes use of the SMTP domain specified on the HTTP virtual directory to identify the user. Therefore, users connecting to that virtual server must have an e-mail address in their list of SMTP proxy addresses on their object in Active Directory with the same domain.

Exchange Server 2003 SP1

Implicit logon no longer relies exclusively on the SMTP domain specified. All the user information can be gleaned from their logon. Users can use any mailbox Exchange virtual directory to access their e-mail messages.

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 Mechanisms for HTTP) or when a user is attempting to access a mailbox that is not their own but to which they have access, for example, in the case of delegate users.

Exchange 2000 Server SP3 and Exchange Server 2003

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 and returns it back through the front-end server to the client.

Exchange Server 2003 SP1

The user can choose to override the SMTP domain configured on the mailbox virtual directory, by specifying the SMTP address in the URL itself. For example; https://<server>/exchange/username@domain.com. If no SMTP domain is specified, the SMTP domain from the virtual directory will be used.

You can prevent specific users from accessing Outlook Web Access by disallowing the HTTP protocol for those users. To change a user's protocol settings, in Active Directory Users and Computers, use the Exchange Advanced tab in a user's properties.

Simplifying the Outlook Web Access URL

Users commonly request that a simpler URL be made available for accessing their mailbox. For detailed instructions on simplifying the Outlook Web Access URL, see How to Simplify the Outlook Web Access URL.

Enabling the "Change Password" Feature

If you are using Outlook Web Access, you can enable the Change Password feature in IIS to:

• Alert users when their passwords expire.

• Enable users to use the Options button in Outlook Web Access to change their passwords.

Keep in mind that if you want to use the Change Password feature, you must also use SSL between clients and the front-end server to secure the password during transmission. Additionally, you must create a virtual directory named IISAdmPwd on the front-end server and back-end servers to handle the Change Password requests.

For more information about how to configure the Change Password feature, see Implementing the Change Password feature with Outlook Web Access.

For more information about how to configure SSL, see Helping to Secure Communication: Client to Front-End Server.

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 the goal for accessing public folders is twofold:

• For availability   If data exists in an Exchange 2000 Server or Exchange Server 2003 public folder somewhere in the Exchange organization and is accessible over HTTP, it is available to the user.

• For 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 every time that 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 public folder servers in the organization, but the contents of each folder may not be. 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.

The following figure illustrates how public folder referrals travel through a front-end server.

Public folder referral through a front-end server

1. An HTTP client authenticates against the front-end server and requests /public/PublicFolder2.

2. The front-end server authenticates the user against Active Directory and requests the location of the user's default public folder store.

3. Active Directory indicates to the front-end server that the user's default public folder store is on Server1.

4. The front-end server sends the client request to Server1.

5. Server1 tells the front-end server that it does not have the contents of /public/PublicFolder2, but Server2 and Server3 do.

6. 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.

7. Server2 returns the contents of /public/PublicFolder2 to the front-end server, which then sends the contents to the HTTP client.

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. 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 the public folder hierarchy (tree) in Outlook.

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.

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 Server or Exchange Server 2003 in the organization that have a replica of the particular general-purpose public folder tree that the client is attempting to access.

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.

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 occurs for folders in the default public folder store in addition to 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. 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 and consistent views. 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.

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.

This process significantly increases reliability for public folder access. The front-end server will attempt to contact multiple back-end servers for the data, whereas a client connecting directly to a back-end server will not.

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 depends 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 folder content to public folder servers.

At a high level, the hashing algorithm works as follows: Two back-end servers, numbered 1 and 2, hold the contents of a public folder. Then, if six different users—A, B, C, D, E, and F—try to access data in this folder, 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.

Then another server is added, server 3, and the folder's contents are also replicated to this server. 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.