Referring Outlook Web Access in a Front-end/Back-end Topology

  • 發行項

主題上次修改日期： 2005-09-22

Using a front-end Exchange server to proxy incoming client requests increases the fault tolerance and load balancing capability of your topology, as compared with allowing clients to access the back-end servers directly.

The following figure how a front-end server (ExFront01) handles an incoming request for a folder in the Public Folders tree. The front-end server queries Active Directory for information about the user, queries the user's public folder store for the location of the content replica, and queries another public folder store for the replica itself.

The details of this process are as follows:

  1. An authenticated user who has a mailbox in this Exchange organization tries to view the contents of a public folder in the Public Folders tree. Outlook Web Access sends the following request:

    HTTP GET "http://<virtdir_front>/public/<folder>"

  2. The front-end server ExFront01 receives the GET request, and contacts the global catalog server. ExFront01 looks up the user in Active Directory and retrieves the value of the user's msExchHomePublicMDB attribute. This value identifies the default public folder store that is associated with the user's mailbox store. In the example shown in Figure 1, this store is on the server ExBack01.
    This example depicts a specific case. Under other circumstances (for example, a server is down, the user is anonymous, or the requested folder is not in the Public Folders tree), ExFront01 would perform one of the following actions in Step 2 instead of the action described:

    • If the server with the user's associated public folder store is not available or is an Exchange 5.5 server, the front-end server sends a GET request to another server in the local routing group. The store on that server follows the basic referral process, outlined earlier in this section, to locate a content replica.
    • If the user is anonymous (using the IIS Anonymous account), the front-end server uses a hashing algorithm to select a server in the local routing group, and sends a GET request to that server. Because anonymous users have a single account, in this step they will always be sent to the same server.
    • If the public folder is in a general-purpose public folder tree, the front-end server uses a hashing algorithm to select a server in the local routing group, and sends a GET request to that server. The store on that server follows the basic referral process, outlined earlier in this section.

  3. ExFront01 sends the request HTTP GET "HTTP://ExBack01/public/<folder>" to ExBack01.

  4. ExBack01 accesses its hierarchy information for the Public Folders tree, and finds that the closest available content replica is on the server ExBack02. ExBack01 sends the location of the content replica to ExFront01 in the form of the message:

    HTTP 305 "HTTP://ExBack02/public/<folder>"

  5. ExFront01 sends the request HTTP GET "HTTP://ExBack02/public/<folder>" to ExBack02.

  6. ExBack02 returns the requested content and an HTTP 200 OK message to ExFront01.

  7. ExFront01 forwards the content and an HTTP 200 OK message to Outlook Web Access.

Using this process, the Outlook Web Access user remains unaware of the topology behind the front-end server. If you do not use a front-end server, users would have to know the name of at least one of your public folder servers to use Outlook Web Access with public folders.

To speed up repeated client access to folders while minimizing network traffic, Exchange caches much of the information that it needs during the process. This information, including routing costs, replica locations, and server-down status, is cached for 10 minutes.