NOTE: The content of this article has been published in the official Exchange 2007 documentation. We recommend that you check the documentation for the most up-to-date version. Please go here:

http://technet.microsoft.com/en-us/library/bb885041.aspx

EDIT: We have updated this post on 2/15/07 to include additional detail about public folder access.

To get started, let me take you on a trip down memory lane to dark ages of computing and e-mail. Journey with me to the years 2000 and 2003, when Exchange was a much different product. In Exchange 2003 and 2000, there were two server configurations: front-end (FE) and back-end (BE). From OWA's point of view, the FE server was little more than a proxy. It accepted requests and forwarded them to the BE server. The BE handled all the business logic and rendered the UI. If you looked at the IIS metabase on an FE or BE server, you'd see three virtual directories normally associated with OWA:

/exchange: handles mailbox access requests for OWA and WebDAV
/public: handles requests for public folders
/exchweb: contains resource files used by OWA and WebDAV

If you accessed /exchange on an FE server, you would be prompted to enter your credentials and then proxied to /exchange on the BE server, which would serve up OWA.

Fast forward to 2007, where we made a great leap forward with Exchange. We did away with the FE and BE roles in favour of the CAS and Mailbox roles. The key difference between CAS and FE is that CAS contains the business logic and renders the OWA UI. This presented us with a challenge: how do we allow Exchange 2007 CAS servers to coexist with Exchange 2007 Mailbox and Exchange 2003/2000 Mailbox servers? The solution depends on how the server is configured.

First things first, though:

  • If you intend to keep E2007 and E2003/2000 servers running side by side, we recommend that you keep the E2007 CAS and E2007 Mailbox servers on separate machines. If you want to combine CAS and Mailbox on a single server while still maintaining E2003/2000 servers, you will need to expose two URLs. One goes to the E2007 server (e.g., https://e2007.contoso.com/owa), while the other goes to the E2003/2000 servers (e.g., https://e2003.contoso.com/exchange).
  • We don't support putting an Exchange 2003/2000 FE server in front of an Exchange 2007 Mailbox server. OWA 2007 also doesn't support Exchange 2007 public folders yet. Look for it in an Exchange 2007 Service Pack. In addition, you should replace all your E2003/2000 FE servers with E2007 CAS servers before moving your mailboxes to E2007 (see this page in Exchange 2007 documentation). Note that a CAS will require more powerful hardware than an FE server, so account for that in your planning (see this blog post for details).

If you look at IIS on CAS-only, Mailbox-only, and CAS+Mailbox servers, you'll see that they look very similar:

CAS-only

Mailbox-only

CAS+Mailbox

/owa

/exchange

/public

/exchweb

/exchange

/public

 

/owa

/exchange

/public

/exchweb

Looks, in this case, are deceiving. /owa, which handles OWA 2007 business logic and UI rendering, is the only one that behaves the same wherever it appears. The remaining virtual directories, affectionately dubbed "legacy virtual directories", handle Exchange 2003/2000 and WebDAV requests. They work differently based on which server roles are installed.

By reserving /owa for OWA 2007, we made the Exchange 2007 legacy virtual directories analogous to Exchange 2003/2000 virtual directories. From the legacy virtual directory point of view, the CAS role acts like an Exchange 2003/2000 FE server. That is, it takes requests and proxies them to a BE server. The logic for this is in exprox.dll, which is applied as a scriptmap on the legacy virtual directories. Exprox doesn't do anything beyond proxy requests from the CAS to the Exchange 2007/2003/2000 Mailbox server.

All the intelligence for handling legacy requests lives in davex.dll, which is the scriptmap on the Mailbox server's legacy virtual directories. Davex contains logic for handling DAV requests, redirecting Exchange 2007 mailbox users to /owa, and serving up the Exchange 2003/2000 OWA experience. It is important to understand that exprox only directs traffic to davex on a mailbox server. Davex figures out what the right or the best server to use is.

There are two important caveats when working with davex:

  1. Davex responds to both DAV and OWA requests. If you are pointing your browser to a URL, such as https://mail.company.com/exchange, and davex responds to it, it is treating it as an OWA request.
  2. Davex 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.

To understand how it all fits together, let's take a look at a few examples:

Example #1
1 Exchange 2007 CAS-only server
1 Exchange 2007 Mailbox-only server
All mailboxes are Exchange 2007

  • Requests for /owa return the OWA 2007 experience
  • Requests for /exchange: exprox proxies requests to /exchange on the Mailbox server, where davex redirects the user to /owa on the CAS
  • Requests for /public: exprox proxies the user to /public on the Mailbox server. Davex then looks for an E2003 PF server but doesn't find one. It then returns an error message.
  • Requests for /exchweb: exprox either proxies them to /exchange or /public on the Mailbox server, or does nothing with them (more on this later)

Example #2
1 Exchange 2007 CAS-only server
1 Exchange 2003 BE server
All mailboxes on the BE server

  • Requests for /owa returns the following error since there are no Exchange 2007 mailboxes.

Outlook Web Access could not find a mailbox for DOMAIN\USER. If the problem continues, contact technical support for your organization and tell them the following: The mailbox may be stored on a Microsoft Exchange 2000 or Microsoft Exchange 2003 server, or the Active Directory user account was created recently and has not yet replicated to the Active Directory site where this Client Access server is hosted.

  • Requests for /exchange on the CAS are proxied to /exchange on the BE server, which returns the OWA 2003 experience
  • Requests for /public on the CAS are proxied to /public on the BE server, which returns the OWA 2003 PF experience
  • Requests for /exchweb: exprox either proxies them to /exchange or /public on the Mailbox server, or does nothing with them

Example #3
1 Exchange 2007 CAS-only server
1 Exchange 2007 Mailbox-only server
1 Exchange 2003 BE server
Mailboxes on both Exchange 2007 and 2003 servers

If the your mailbox is on an E2007 server

  • requests to /owa will return the OWA 2007 experience
  • requests to /exchange on the CAS or Mailbox server will redirect the user to /owa. Authentication credentials transparently passed through.
  • requests to /exchange on the BE will direct the user to the CAS, but the user may need to be authenticated again
  • requests to /public will be directed to /public on the BE server
  • requests to /exchweb will be directed to the BE server or return nothing

If your mailbox is on an E2003 server

  • requests to /owa will yield the error message from Example 2
  • requests to /exchange or /public on a CAS will be proxied by exprox to /exchange or /public on the BE server and yield the OWA 2003 experience
  • requests to /exchange or /public on the BE server will yield the OWA 2003 experience
  • requests to /exchweb will be directed to the BE server or return nothing

Example #4
1 Exchange 2007 CAS+Mailbox server

  • requests for /owa yield the OWA 2007 experience
  • requests for /exchange will be redirected by davex to /owa
  • requests for /public will return an error since there are no E2003 PF servers

Example #5
1 Exchange 2007 CAS+Mailbox server
1 Exchange 2003 BE server

If your mailbox is on the E2007 server

  • Requests to /owa will yield the OWA 2007 experience
  • Requests to /exchange will redirect to /owa
  • Requests to /public will likely yield an error because DAV will not redirect OWA requests to the E2003 PF server correctly.

If your mailbox is on the E2003 server

  • Requests to /owa will yield the Example 2 error message
  • Requests to /exchange redirect to the E2003 server and yield the OWA 2003 experience
    • If accessing /exchange on the E2007 server, you will need to reauthenticate after being redirected to the E2003 server
  • Requests to /public will likely yield an error because DAV will not redirect OWA requests to the E2003 PF server correctly.

Accessing OWA

With all the virtual directories floating around on different servers, it can be a little confusing for users to understand which one to access. Here's the summary:

Users with Exchange 2007 users should access /owa or /exchange on the CAS. /owa will take the user directly to OWA. /exchange will use DAV to redirect the user to /owa.

Users with Exchange 2003 or 2000 mailboxes should access /exchange on the CAS to get the OWA2003/2000 experience. Again, DAV will redirect the user to the right server, if necessary.

Authentication

Between exprox and davex, requests can be bounced all over the place. To make things easier for the user, we've done a lot of work so that users only need to authenticate once in most cases. The only places where you need to reauthenticate are when you are directed from /exchange on an E2007 mailbox server to /exchange on an E2003 BE, and when you're directed from /exchange on an E2003 BE to /owa on a CAS.

Another authentication issue to be aware of is that legacy virtual directories on a CAS (i.e., the ones that use exprox) really are the same as the virtual directories on an E2003 FE server. This means that you can only use forms-based authentication (FBA) or basic authentication. The reason for this is that we need your credentials to authenticate to the virtual directories on the E2007 mailbox or E2003 BE server. On those servers, you can use all supported authentication types (FBA, basic, digest, and Windows Integrated).

Mixing and Matching Virtual Directories

In the past, we supported creating multiple OWA virtual directories within a single website (virtual server). This isn't exactly the case anymore. There can be at most one OWA 2007 virtual directory (i.e, /owa) per website (i.e., at most one /owa per website). You can continue to create as many legacy virtual directories per website as you need, with whatever names you want. There is a caveat, though: for FBA to work properly, all virtual directories that use it must be in the same website and in the same app pool. If you're not using FBA, you can put legacy virtual directories anywhere you want. The OWA 2007 virtual directory must be called "/owa". The legacy virtual directories can be called anything, as long as there is a one-to-one mapping between legacy virtual directories on a CAS and on a Mailbox/BE server.

Public Folders

Exchange 2007 OWA doesn't support Exchange 2007 PF yet. We're planning on adding it in a service pack, though. Until then, E2007 mailbox users who need to access to PF through OWA must have an Exchange 2003/2000 home PF server. This is because /public will automatically load the user's home PF server. If that server is running Exchange 2007, the user will get an error. Also make sure that all content is replicated on E2003/2000 PF servers so that referrals work properly. If your OWA users don't need PF access, it doesn't matter if you use E2007 or E2003/2000 PF servers. DAV requests will be redirected to the correct PF server.

- Rahul Dhar

Share this post :