In Exchange 2003 and Exchange 2000, there were two server configurations: front-end and back-end. The primary role of a front-end server was to proxy client requests for Outlook Web Access content. The front-end server accepted requests and forwarded them to the back-end server. The back-end server hosted content and handled all the business logic and display of the Outlook Web Access user interface.

In the Internet Information Services (IIS) metabase on a front-end or back-end server, three virtual directories are typically associated with Outlook Web Access:

• /exchange   Handles mailbox access requests for Outlook Web Access and WebDAV
  
• /public   Handles requests for public folders
  
• /exchweb   Contains resource files that are used by Outlook Web Access and WebDAV
  

If you access the /exchange virtual directory through a front-end server, you will be prompted to enter your credentials. You will then be proxied to /exchange on the back-end server. This will display the Outlook Web Access user interface.

Significant changes to the Exchange architecture were made in Exchange 2007. Exchange 2007 provides Outlook Web Access through the Client Access server role instead of relying on the front-end/back-end architecture of Exchange 2003 and Exchange 2000. The key difference between the Client Access server role in Exchange 2007 and the front-end configuration used for earlier versions of Microsoft Exchange is that the Client Access server contains the business logic and also displays the Outlook Web Access user interface. For an Exchange 2007 server that is running the Client Access server role to provide Outlook Web Access to Exchange 2000 and Exchange 2003 mailboxes, the Client Access server must emulate an Exchange 2000 or Exchange 2003 front-end server.

The deployment considerations depend on how the servers in your particular organization are configured.

Consider the following as you plan the deployment of Outlook Web Access in your environment:

• If your organization will include Exchange 2007, Exchange 2003, and Exchange 2000 computers, we recommend that you install the Exchange 2007 Client Access server role and the Exchange 2007 Mailbox server role on separate computers. However, if you want to combine the Client Access server role and the Mailbox server role on a single computer while still maintaining Exchange 2003 and Exchange 2000 computers, you must expose two URLs, as follows:
  
  • One URL goes to the Exchange 2007 computer. For example, https://<Exchange2007ComputerName>.contoso.com/owa.
    
  • The other URL goes to the Exchange 2003 or Exchange 2000 computer. For example, https://<Exchange2003ComputerName>.contoso.com/exchange.
    
• Deploying Exchange 2007 by using an Exchange 2003 or Exchange 2000 front-end server in front of an Exchange 2007 Mailbox server is not supported.
  
• The original release (RTM) version of Exchange 2007 does not support access to Exchange 2007 public folders through Outlook Web Access. Support for public folders in Outlook Web Access for Exchange 2007 was added in Exchange 2007 Service Pack 1 (SP1). For more information, see "Public Folders" later in this topic.
  
• You should replace all existing Exchange 2003 and Exchange 2000 front-end servers with Exchange 2007 Client Access servers before you move your mailboxes to Exchange 2007. Exchange 2007 Client Access computers generally require more powerful hardware than Exchange 2003 and Exchange 2000 front-end servers. For more information, see Sizing Client Access Servers.
  

 Virtual Directories

The following table shows the virtual directories that are installed by default on an Exchange 2007 computer. The virtual directories that are installed vary depending on which server roles are installed on the computer.

Exchange 2007 virtual directories installed in different configurations

Only Client Access server role installed	Only Mailbox role installed	Client Access server role and Mailbox role installed
/owa /exchange /public /exchweb	/exchange /public /exadmin	/owa /exchange /public /exchweb /exadmin

Note:

The steps that you perform to view and modify the properties of virtual directories are different depending on whether you are running the RTM version of Exchange 2007 or Exchange 2007 SP1. The steps that you perform also depend on whether you have installed the Mailbox server role on the computer on which the Client Access server role is installed. For more information, see Managing Outlook Web Access Virtual Directories in Exchange 2007.

In Exchange 2007, the /owa virtual directory is used to return Exchange 2007 Outlook Web Access requests. The legacy virtual directories handle Exchange 2003 Outlook Web Access requests, Exchange 2000 Outlook Web Access requests, WebDAV requests, and some administrative functions. With legacy virtual directories, the Client Access server role functions like an Exchange 2003 or Exchange 2000 front-end server. That is, the Client Access server takes requests and proxies them to a back-end server. For more information about the role of each of the virtual directories in Exchange 2007, see Managing Outlook Web Access Virtual Directories in Exchange 2007.

The logic for taking requests and proxying them to a back-end server is provided by Exprox.dll. Specifically, Exprox.dll proxies client requests from the Client Access server to the Exchange 2007 Mailbox server, the Exchange 2003 back-end server, or the Exchange 2000 back-end server.

The logic for handling legacy requests is provided by Davex.dll. Davex.dll handles Distributed Authoring and Versioning (DAV) requests, redirects Exchange 2007 mailbox users to the /owa virtual directory, and displays the Exchange 2003 and Exchange 2000 Outlook Web Access experience.

Exprox.dll only directs traffic to Davex.dll on a mailbox server. Davex.dll decides which server is the correct one to use.

Be aware of the following when you work with Davex.dll:

• Davex.dll responds to both DAV and Outlook Web Access requests. If you are pointing your browser to a URL, such as https://mail.contoso.com/exchange, and Davex.dll responds to it, your browser is treating the request as an Outlook Web Access request.
  
• Davex.dll will redirect a request based on the internal (intranet) name of the server. This means that users on the Internet may receive a DNS error because the internal name of a server may not be the one that is exposed on the Internet.
  

The following deployment scenarios offer examples of how you might configure Outlook Web Access by using Exchange 2007 and one or more earlier versions of Microsoft Exchange.

Note:
The scenarios in this section are based on environments that include the RTM version of Exchange 2007 and not Exchange 2007 SP1. Support for public folders in Outlook Web Access for Exchange 2007 was added in Exchange 2007 SP1. For information about access to public folders in Exchange 2007 SP1, see "Public Folders" later in this topic.

 Scenario 1

You deploy one Exchange 2007 computer that has only the Client Access server role installed.

You deploy one Exchange 2007 computer that has only the Mailbox server role installed.

All mailboxes are Exchange 2007.

Requests are received by four virtual directories as follows:

• Requests for /owa return the Exchange 2007 Outlook Web Access experience.
  
• Requests for /exchange are handled as follows:
  
  1. Exprox.dll proxies requests to /exchange on the Mailbox server.
     
  2. Davex.dll redirects the user to /owa on the Client Access server.
     
• Requests for /public are handled as follows:
  
  1. Exprox.dll proxies requests to /public on the Mailbox server.
     
  2. Davex.dll looks for an Exchange 2003 public folder server but does not find one. Then it returns an error message.
     
• Requests for /exchweb are handled as follows:
  
  • Exprox.dll either proxies the request to /exchange or /public on the Mailbox server. Or, Exprox.dll does not respond.
    

 Scenario 2

You deploy one Exchange 2007 computer that has only the Client Access server role installed.

You deploy one Exchange 2003 back-end server.

Requests are received by the virtual directories as follows:

• Requests for /owa return an error message because there are no Exchange 2007 mailboxes. For example, you may receive the following error message:
  Outlook Web Access could not find a mailbox for <DOMAIN\USER>.
  
• Requests for /exchange on the Client Access server are proxied to /exchange on the back-end server. This provides the Exchange 2003 Outlook Web Access experience.
  
• Requests for /public on the Client Access server are proxied to /public on the back-end server. This returns the Exchange 2003 Outlook Web Access public folder experience.
  
• With requests for /exchweb, Exprox.dll either proxies requests to /exchange or /public on the Mailbox server, or does not respond.
  

 Scenario 3

You deploy one Exchange 2007 computer that has only the Client Access server role installed.

You deploy one Exchange 2007 computer that has only the Mailbox server role installed.

You deploy one Exchange 2003 back-end server.

You have mailboxes on both Exchange 2007 and Exchange 2003 servers.

If the mailbox is located on an Exchange 2007 server:

• Requests to /owa return the Exchange 2007 Outlook Web Access experience.
  
• Requests to /exchange on the Client Access server or Mailbox server redirect the user to /owa. Authentication credentials are passed through transparently.
  
• Requests to /exchange on the back-end server direct the user to the Client Access server. However, the user may have to be authenticated again.
  
• Requests to /public are directed to /public on the back-end server.
  
• Requests to /exchweb are directed to the back-end server or do not return anything.
  

If the mailbox is located on an Exchange 2003 server:

• Requests to /owa return the error message shown in Scenario 2.
  
• Requests to /exchange or /public on a Client Access server are proxied by the Exprox.dll to /exchange or /public on the back-end server and provide the Exchange 2003 Outlook Web Access experience.
  
• Requests to /exchange or /public on the back-end server provide the Exchange 2003 Outlook Web Access experience.
  
• Requests to /exchweb are directed to the back-end server or do not return anything.
  

 Scenario 4

You deploy one Exchange 2007 computer that has both the Client Access and Mailbox server roles installed. Therefore, requests are handled as follows:

• Requests for /owa return the Exchange 2007 Outlook Web Access experience.
  
• Requests for /exchange by internal users are redirected by Davex.dll to /owa.
  
• Requests for /public return an error because there are no Exchange 2003 public folder servers.
  

  Note:

  External users who request /exchange will receive the following error message: "Page Cannot Be Displayed." This behavior occurs because Davex.dll redirects the request to the URL that is defined in the InternalURL parameter for the /owa virtual directory in the Exchange Management Console. However, remote users cannot access the internal FQDN that is defined in the InternalURL parameter. To resolve this issue, change the URL that is defined in the InternalUrl parameter to the external URL that external users use to access Outlook Web Access through the Internet. Or, instruct external users to use /owa instead of /exchange to access Outlook Web Access.

 Scenario 5

You deploy one Exchange 2007 computer that has both the Client Access and Mailbox server roles installed.

You deploy one Exchange 2003 back-end server.

Caution:
If you deploy both the Client Access and Mailbox server roles on the same computer in environments that include versions of Microsoft Exchange earlier than Exchange 2007, redirection failures may occur in all virtual directories. You should deploy the Client Access and Mailbox server roles on separate computers.

If your mailbox is located on the Exchange 2007 server:

• Requests to /owa return the Exchange 2007 Outlook Web Access experience.
  
• Requests to /exchange by internal users are redirected by Davex.dll to /owa
  
• Requests to /public are likely to return an error because Davex.dll does not redirect Outlook Web Access requests to the Exchange 2003 public folder server correctly.
  

Note:

External users who request /exchange will receive the following error message: "Page Cannot Be Displayed." This occurs because Davex.dll redirects the request to the URL that is defined in the InternalURL parameter for the /owa virtual directory in the Exchange Management Console. However, remote users cannot access the internal FQDN that is defined in the InternalURL parameter. To resolve this issue, change the URL that is defined in the InternalUrl parameter to the external URL that external users use to access Outlook Web Access through the Internet. Or, instruct external users to use /owa instead of /exchange to access Outlook Web Access.

If your mailbox is located on the Exchange 2003 server:

• Requests to /owa return the error message shown in Scenario 2.
  
• Requests to /exchange by internal users redirect to the internal URL of the Exchange 2003 server and return the Exchange 2003 Outlook Web Access experience.
  If you access /exchange on the Exchange 2007 server, you must authenticate again after you are redirected to the Exchange 2003 server. Remote users who request /exchange will receive a "Page Cannot Be Displayed" error message. This occurs because Davex.dll redirects the request to the URL that is defined in the InternalURL parameter for the /owa virtual directory. In this case, remote users cannot access the internal FQDN that is defined in the InternalURL parameter.
  
• Requests to /public will likely return an error because Davex.dll does not redirect Outlook Web Access requests to the Exchange 2003 public folder server correctly.
  

Because there are multiple servers and virtual directories involved in these coexistence scenarios, it can be difficult to understand which virtual directories users should access. Users should access virtual directories as follows:

• Users who have mailboxes on Exchange 2007 computers should access /owa or /exchange on the Client Access server.
  
  • /owa will take the user directly to Outlook Web Access.
    
  • /exchange will use DAV to redirect the user to /owa.
    
• Users who have Exchange 2003 or Exchange 2000 mailboxes should access /exchange on the Client Access server. This will return the Exchange 2003 Outlook Web Access experience or the Exchange 2000 Outlook Web Access experience. Davex.dll will redirect the user to the correct server if it is necessary.
  

The simplest strategy in a coexistence scenario is to have all users access the /exchange virtual directory and let the Client Access server redirect users to the correct virtual directory if it is necessary.

Microsoft Exchange uses Exprox.dll and Davex.dll to redirect requests that are submitted to virtual directories on Exchange 2007, Exchange 2003, and Exchange 2000 computers to the correct URL. This logic reduces how frequently a user must authenticate. However, in e-mail environments that include both Exchange 2007 and Exchange 2003 computers, Outlook Web Access users who have mailboxes on Exchange 2007 computers may have to enter their user names and passwords two times. The following are the cases in which an Outlook Web Access must authenticate multiple times:

• When a user is directed from /exchange on an Exchange 2007 Mailbox server to /exchange on an Exchange 2003 back-end server. For example, after a user who has an Exchange 2007 mailbox logs on to Outlook Web Access, they will be prompted to provide credentials again after they add a user who has a mailbox on an Exchange 2003 computer to a meeting request. This occurs when the computer that is running Exchange 2007 contacts the /public virtual directory to obtain free/busy information for the Exchange 2003 user.
  
• When a user is directed from /exchange on an Exchange 2003 back-end server to /owa on a Client Access server.
  

Another authentication issue to consider is that legacy virtual directories on a Client Access server (for example, the virtual directories that use Exprox.dll) are the same virtual directories that are located on an Exchange 2003 front-end server. You will only be able to use forms-based authentication or Basic authentication to authenticate to the Client Access server because Microsoft Exchange needs credentials to authenticate to the virtual directories on the Exchange 2007 Mailbox server or Exchange 2003 back-end server. On Exchange 2007 Mailbox servers or Exchange 2003 back-end servers, you can use all supported authentication types: forms-based authentication, Basic authentication, Digest authentication, and Integrated Windows authentication.

In versions of Microsoft Exchange earlier than Exchange 2007, you could create multiple Outlook Web Access virtual directories within a single Web site (virtual server). This is no longer possible in Exchange 2007. Consider the following as you use virtual directories:

• There can be at most one Exchange 2007 Outlook Web Access virtual directory named /owa per Web site. The Exchange 2007 Outlook Web Access virtual directory must be named "/owa".
  
• You can create as many legacy virtual directories per Web site as you want. However, for forms-based authentication to work, all virtual directories that use it must be in the same Web site and in the same application pool. If you are not using forms-based authentication, you can put legacy virtual directories anywhere you want.
  
• The names that you use for the legacy virtual directories on the Client Access server must match the names of the virtual directories on the Exchange 2003 or Exchange 2000 back-end servers. There should be a one-to-one mapping between the legacy virtual directories on a Client Access server and the virtual directories on an Exchange 2007 Mailbox server or an Exchange 2003 or Exchange 2000 back-end server.
  

The version of Outlook Web Access that was included with the RTM version of Exchange 2007 did not support Exchange 2007 public folders. Support for public folders in Outlook Web Access for Exchange 2007 was added in Exchange 2007 SP1. For information about how to access public folders from Exchange 2007, see How to Enable Users to Access Public Folders from Outlook Web Access.

If you have not yet deployed Exchange 2007 SP1, your Exchange organization must have an Exchange 2003 or Exchange 2000 public folder server to enable users who have mailboxes on Exchange 2007 Mailbox servers to access public folders through Outlook Web Access. This is because /public will try to load the default public folder database that is associated with the user's mailbox database. If the server that contains the user's default public folder database is running Exchange 2007, the user will receive an error. Also, you must make sure that all content is replicated on Exchange 2003 and Exchange 2000 public folder servers so that referrals work correctly.

If your Outlook Web Access users do not have to have public folder access, you do not have to use Exchange 2007, Exchange 2003, or Exchange 2000 public folder servers.

For more information about how to deploy Exchange 2007 server roles, see Deploying Server Roles.

For more information about how to manage virtual directories, see Managing Outlook Web Access Virtual Directories in Exchange 2007.