Introduction
This article does not show you how to configure Outlook Web Access (OWA), Outlook Mobile Access (OMA) or Exchange ActiveSync (EAS). Instead it discusses the technical functionality behind providing remote HTTP access to Exchange 2003 mailboxes. As such, this document is going to be quite wordy, technical and perhaps a little ‘heavy’.
So why bother with it? Well the HTTP mechanisms used to access mailboxes are somewhat bizarre! Although Exchange does its best to hide these abstract ideas from us, they still remain waiting to catch out the unwary. Here you may well find answers to why some HTTP mailbox access methods cause so much trouble, and understanding these facts will dramatically improve the ease of configuring these features.
The article also covers changes made in SP1 for Exchange which went a step further towards obscuring some of these weird mechanisms, but at the time of writing these changes remain ‘work-in-progress’. At least there is a glimmer of hope for the future!
Understanding Exchange HTTP Mailbox Access
The key concept to grasp in understanding Exchange HTTP mailbox access is that email addresses and SMTP domains are very important to providing that access: Although a user is authenticated by their logon credentials, access to the mailbox data is dependant on their email addresses. Providing an understanding of this somewhat abstract concept is the main purpose of this guide.
Many of us will have configured OWA, OMA and EAS without understanding these concepts, although everyone will have experienced the problems they generate! The real difficulties await those in organisations with multiple identities that express those identities with multiple email addresses such as [email protected] and [email protected]. With Exchange supporting multiple SMTP domains, providing HTTP mailbox access becomes increasingly tricky, but with an appreciation of the concepts you can avoid many of the common configuration errors.
The Exchange Web Store
An Exchange Store (sometimes called the Web Store) is the structure maintaining mailbox and public folder data. The Store is exposed to programmers through something called the Exchange OLE DB Provider (ExOLEDB) which registers with the OLE RootBinder to allow it to be accessed through a Uniform Resource Locator (URL). URLs to access the Exchange Store are prefixed:
file://./BackOfficeStorage/
To access a user’s mailbox, the URL must contain globally unique information to describe the user. You could be forgiven for thinking that this information would be a domain and username or a user’s UPN, but it isn’t. Instead, typically Exchange focused properties of default SMTP domain and mailbox alias are used. For example, a file URL to access items in a user’s Inbox is:
file://./BackOfficeStorage/DefaultSMTPDomain/MBX/MailboxAlias/Inbox/…
The ‘MBX’ bit indicates this URL is accessing the mailbox stores. An URL to access Exchange public folder stores is very similar, but in place of MBX is the name of the top-level folder followed by any further public folders in the hierarchy. ‘Public Folders’ is the default top level folder:
file://./BackOfficeStorage/DefaultSMTPDomain/Public Folders/…
The M: Drive
ExOLEDB can be accessed, as its file URL suggests, as if it were part of the server’s file system. Exchange 2000 mapped drive M to BackOfficeStorage allowing mailbox contents to be accessed as if they were files. People then began running virus checkers and backup utilities on the drive with disastrous results! Exchange 2003 does not map a drive to BackOfficeStorage!
If you are really curious (remember ‘curiosity killed the cat’!) you can explore the Exchange Store by running subst m: \\.\BackOfficeStorage at the command-line and navigating the resultant virtual M drive. Note the backslashes in place of forward ones; here we need the Universal Naming Convention (UNC), not a file URL. Run subst /D m: after you’ve finished ‘just looking’.
Access to the Exchange Web Store using HTTP URLs
File URLs may provide local access for local applications, but useful remote access needs to be provided by HTTP protocols. To do this we can configure a virtual directory (or server) in Internet Information Server (IIS) on the Exchange server with its local path set to \\.\BackOfficeStorage and allow browsing: Again, such a procedure is for the curious only!
Figure 1: Property sheets of a test IIS virtual directory configured to browse the Web Store
Having basic HTTP access is of little value beyond just viewing the contents, therefore the likes of OWA use server-side applications to render the basic content into something far more useful for the client. OWA also employs advanced techniques known as Web Distributed Authoring and Versioning (WebDAV). WebDAV is an extension of HTTP allowing file operations such as copy, move, delete, and drag-and-drop, over the Internet.
Web applications like OWA work with more specific locations than the BackOfficeStorage root. For example, a virtual directory configured to access mailboxes, such as the default ‘Exchange’ virtual directory configured by Exchange for OWA, will have a local path of:
\\.\BackOfficeStorage\SMTPDomain\MBX
Now explanations have been fairly straight-forward up until this point, but its about to take a turn for the worse! In the line above an SMTP domain is used, but it doesn’t have to be the default SMTP domain as suggested earlier in this section; in fact it doesn’t have to be an SMTP domain at all, any old string will do! Whatever appears here is translated somewhere in the guts of IIS and Exchange into the valid location containing the default SMTP domain.
This ‘feature’ is put to use by OWA. A virtual directory for OWA is configured for a specific SMTP domain, and this domain appears in its local path. When an OWA client directly accesses a user’s Inbox, it uses an URL containing not the user’s mailbox alias or username, but the left-hand side (LHS) of one of the user’s email addresses (left of the ‘@’ that is):
HTTP://ServerName/Exchange/LHSofSMTPAddress/Inbox
The OWA application takes this LHS bit and marries it up to the SMTP domain it is configured for (effectively the right-hand side of the email address). The user must have this resultant email address or else OWA returns a ‘not found’ error.
Of course, we don’t normally specify the LHS bit when accessing OWA, but when OWA returns it’s constructed Web page to the client it will have links in it much as described above. To do this OWA finds a suitable email address in the configured SMTP domain. If the user has many suitable email addresses, OWA doesn’t care which email address it uses, but if the user doesn’t have an email address in the configured domain, OWA returns a ‘not found’ error and login fails.
There must be people out there that understand why Exchange HTTP access works in this way!
Exchange 2003 Service Pack 1
If that all sounded crazy, you’re not the only one to think so. Even Microsoft finds the problems these mechanisms create too much to bear and is working to remove them. Exchange 2003 SP1 introduced support for another form of HTTP URL that doesn’t care what SMTP domain the user’s email address is in. This format is:
HTTP://ServerName/Exchange/Emailname@SMTPDomain/Inbox
Here there is no LHS or RHS, the entire SMTP email address (including the ‘@’) is used. The OWA virtual directories can be left configured for the default SMTP domain because it is no longer important what domain it is configured for.
At the time of writing only OWA supports this new format; OMA and EAS are stuck with the old format (and worse!).
Figure 2: The Status Bar will display the links used in Outlook Web Access when you move the mouse cursor over them. Here we see a link in the more recent Exchange 2003 SP1 format
RPC over HTTP
So where does RPC over HTTP fit in to all this?
The first thing to say about RPC over HTTP is that it isn’t anything to do with Exchange 2003! RPC over HTTP on the client-side is a Windows XP feature that an Outlook 2003 client exploits. The server-side ‘RPC Proxy’ can be any Windows 2003 server with or without Exchange Server installed. An RPC Proxy doesn’t care which SMTP domain you belong to, or even that you are accessing an Exchange server! The proxy just takes HTTPS requests from clients and acts on their behalf as an RPC client on the local network. Exactly what you’d expect from a ‘RPC proxy’.
This point-of-view is confused somewhat following SP1 for Exchange 2003 which introduced ‘managed’ RPC over HTTP for Exchange: Exchange System Manager can now be used to configure a RPC over HTTP arrangement for Exchange. However you can still configure this feature without System Manager’s interference, and gain a little more flexibility by doing so.
RPC over HTTP is a very important tool for remote access of Exchange 2003 mailboxes, but the subject is well covered by other articles and doesn’t need repeating here.
Continued…
You are now armed with a basic understanding of how HTTP clients can extract mailbox data from Exchange 2003. In Part 2 we’ll look at how OWA, OMA and EAS use these mechanisms.
If you would like to be notified when Paul Baldwin releases Part 2 click here to sign up to our Real-time article update.
