Introduction
Part 1 of this article looked at how HTTP clients can access and manipulate the Exchange ‘Web Store’. In this article we’ll look at how Outlook Web Access (OWA), Outlook Mobile Access (OMA) or Exchange ActiveSync (EAS) uses these mechanisms to provide remote users with Exchange messaging and collaboration services.
This isn’t a lesson in configuring OWA, OMA or EAS; instead it discusses the workings behind these services. Part 1 illustrated the somewhat bizarre mechanisms used to access Exchange data, and in this article we’ll have our understanding stretched even further because OWA, OMA and EAS all use these mechanisms in a different way! If you have struggled making these HTTP access methods work together, you may well find the reason why in the following words and be able to use the knowledge to figure out the problems you’re having.
This article also covers improvements to OWA made in SP1 for Exchange.
Outlook Web Access Technical Overview
OWA is an application consisting of executable DLL files configured by default on an IIS virtual directory called ‘Exchange’ in the IIS virtual server ‘Default Web Site’ (if you have Exchange on a server cluster, the default ‘Exchange’ directory is created in a virtual server called ‘Exchange Virtual Server’ instead). Users access OWA by typing the default URL of:
HTTPS://ServerName/Exchange
When a new OWA request arrives on a server the user is prompted for their credentials and authenticated against the Active Directory (AD). The OWA server-side application then performs LDAP requests to obtain user information from AD, which includes the user’s SMTP addresses (proxy addresses), mailbox alias and Exchange home server (the one storing the user’s mailbox). What happens next depends on whether this server is also the user’s home server or not.
If the server receiving client requests is not the user’s home server the server responds with a redirection (HTTP 302 response). However, if the server is an Exchange frontend it communicates with the appropriate backend on the client’s behalf, effectively becoming a Web proxy. Whatever the route, the actual home server will repeat the LDAP process when it gets the redirected request, just as if the client connected to it directly.
Figure 1: Initial OWA communications, here with multiple backend servers.
The OWA application on the home server (be that a different server or not) checks the user’s SMTP addresses for any one matching the SMTP domain configured for the ‘Exchange’ virtual directory. The left-hand side (LHS) of this matched address is used to build links into the HTML page it is preparing for the client. These links look something like:
HTTPS://ServerName/Exchange/LHSofSMTPAddress/…
Prior to SP1 for Exchange 2003, if the OWA application could not match an email address to the SMTP domain configured for the ‘Exchange’ virtual directory, the login would fail. Since SP1 OWA deals with this situation by taking the entire primary SMTP address for the user (found during the LDAP process) and create links in the format of:
HTTPS://ServerName/Exchange/PrimarySMTPAddress/…
When the client receives the page it is these links that provide access to the mailbox content and some of these links are WebDAV requests that perform various mailbox functions too. The page will also contain links to static content such as graphics found in the ‘ExchWeb’ directory.
OWA can also view public folders and it does this through the default ‘Public’ virtual directory. The process is very similar to mailbox access, including the proxy requests when content isn’t on the server, but LDAP searches for home server, email addresses and so forth aren’t required so a ‘Public’ virtual directory isn’t configured for an SMTP domain like the ‘Exchange’ virtual directory.
Exchange Frontends
When a frontend is involved requests are proxied to the backend home server. The exception is static content requests that are handled by the frontend. The proxied requests use a modified URL along the lines of:
HTTP://HomeServerName/Exchange/…
The important thing to note is that these proxy requests use HTTP, never HTTPS, and that the user will again need authenticating on the target server. The frontend uses the credentials already requested from the client and employs ‘Integrated’ authentication (Kerberos or NTLM) to obscure the password that would otherwise appear plain-text in the HTTP transmission.
With frontends the ‘Exchange’ directory on both servers should be configured for the same SMTP domain or else the matching of LHS and SMTP domain will probably be lost and the request will fail. Dissimilar configurations will work if a user has an address in both configured SMTP domains with an identical LHS, but this is not a recommended configuration. Likewise the SP1 changes that can ignore all that LHS business may allow dissimilar configurations, but not always, so just don’t do it!
Figure 2: Initial OWA communications, here in a frontend-backend environment. Note the HTTP (not HTTPS!) proxy requests between frontend and backend.
OWA and Delegate Access
You can short-circuit some of this process by using a more specific URL for your original request. This trick is very useful if you are a delegate of, say, a colleague’s calendar. For example:
HTTPS://ServerName/Exchange/LHSofColleaguesSMTPAddress/Calendar
Your colleague’s SMTP address must be in the SMTP domain configured for the ‘Exchange’ directory used in the URL, and you will have to know that LHS bit. This is all a bit painful, but since Exchange 2003 SP1 you can forget about which SMTP domain is configured for which URL and use any of your colleague’s email addresses in the format:
HTTPS://ServerName/Exchange/Colleague@SMTPDomain/Calendar
You still log on as yourself, but OWA knows to modify its LDAP requests to find your colleague’s home server and not yours.
OMA and Exchange ActiveSync Technical Overview
Exchange 2003 introduced new functionality not found in Exchange 2000, including the OMA and EAS components that were previously offered by a separate server application called Mobile Information Service (MIS). When these MIS components were ported to Exchange 2003, they were given the same administrative ‘look and feel’ as is used for OWA.
OMA and EAS have default IIS directories to which the clients connect, namely ‘OMA’ and ‘Microsoft-Server-ActiveSync’. The ‘OMA’ directory contains Active Server Pages (ASP) that call executable (DLL) files to do the job of requesting mailbox content and rendering the response pages for the client. The EAS directory handles all requests with an application (massync.dll) that requests and supplies mailbox content for the client. EAS content is not rendered for a browser because it is viewed through specific applications on the client. The OMA and EAS applications perform some functions like the OWA application, including authentication and the LDAP searches for the user’s home server, SMTP addresses, etc. If frontends are involved, these processes occur on the frontend as OMA and EAS do not proxy requests to a backend like OWA does. Another difference to OWA is that both applications request mailbox content on behalf of the client by preparing HTTP and WebDAV requests looking something like:
HTTP://HomeServerName/Exchange/LHSofSMTPAddress/…
Note ‘Exchange’ in this URL; the OMA and EAS applications employ OWA to execute these requests. This is very important to understand because, like frontend-backend OWA communications, these OMA and EAS requests use HTTP, not HTTPS, together with ‘Integrated’ authentication: The OWA ‘Exchange’ virtual directories on all backend servers must accept ‘Integrated’ authentication and non-SSL connections, and it is irrelevant whether you have frontends or not because OMA and EAS create these requests in single Exchange server deployments too!
Figure 3: Initial OMA communications. Here the frontend fetches content from the home server rather than proxies the entire client request like OWA. The ‘oma’ (and ‘exchange’) directory has been configured for the ‘abc.tld’ SMTP domain so ‘bob’ is selected from the user’s SMTP addresses because the domains match. A backend only scenario would work just the same except that the content requests will occur within the same server.
‘OMA’ virtual directories are configured for specific SMTP domains much the same as for OWA and should be configured the same as the ‘Exchange’ directory handling its HTTP and WebDAV requests sent on behalf of the client. EAS tackles things a little differently and ‘Microsoft-Server-ActiveSync’ virtual directories handling EAS requests are not configured for a specific SMTP domain. Instead when EAS performs the initial LDAP searches for user attributes it only selects the user’s primary SMTP address and subsequent WebDAV requests use the LHS of this address. This means that the SMTP domain used as a primary address must be configured for the ‘Exchange’ virtual directory that handles the WebDAV requests. It requires some clever configuration to make this work in an environment with multiple SMTP domains where users have different primary SMTP addresses!
Figure 4: As figure 3 but in this case a PDA is attempting an Exchange ActiveSync. All proceeds as with OMA but EAS, which isn’t configured for an SMTP domain, selects the user’s primary SMTP address of ‘[email protected]’. The backend ‘exchange’ directory being configured for ‘abc.tld’ cannot match ‘[email protected]’, so the frontend’s content request will fail!
Fortunately EAS can be configured for a specific SMTP domain with a registry setting to make it work a little more like OWA and OMA: In this mode it can only ever handle one SMTP domain. Despite this obvious disadvantage in a multiple SMTP domain environment, the single domain mode is the easiest to administer and solutions should work around the limitation by other means.
The registry setting is a REG_SZ value called ‘SMTPProxy’ (you will need to create it) which has a value matching the SMTP domain you wish to lock EAS to. This value must appear on all your frontends (or backends if you don’t use frontends) and is located here:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MasSync\Parameters
As always, don’t make registry changes unless you have backups and know what you’re doing.
The Future of Mobile Access?
Why were OMA and EAS not updated with SP1 like OWA? I’d like to think they are both undergoing a major overhaul. OMA was designed for early mobile phones with dreadful data download speeds and not the GPRS/3G full colour toys of today. EAS now competes with numerous third-party offerings that have many more bells and whistles. Maybe that’s the explanation, but we’ll have to wait and see.
Managing Exchange 2003 Sites in IIS
HTTP virtual servers and directories used for remote access to Exchange are configured using two Microsoft Management Console (MMC) plug-ins; the Exchange System Manager (ESM) console and the Internet Information Service (IIS) Manager console. At first this can seem confusing and what’s more it can draw you into to making some very baffling mistakes. Changes made in ESM console always have priority over changes made in IIS Manager console yet changes made with the latter console seem to over-ride the former. This illusion is due to the asynchronous way Exchange applies the configurations it knows about.
The DB2MB Process
The big difference between the two consoles is that ESM applies its changes to Active Directory’s Configuration ‘naming context’ (partition) while IIS Manager applies changes directly to the IIS Metabase, an XML file containing the configuration for IIS. ESM configurations stored in AD are applied to the IIS Metabase by an Exchange process known as Directory Service to Metabase (DS2MB). This process occurs whenever Exchange is restarted, or when DS2MB notices any relevant AD changes (not necessarily instantaneously). DS2MB applies configurations with a blanketing approach that has no respect to any existing configuration made by any other means!
Not all of the configurations made by Exchange are visible from IIS Manager, including the applications behind OWA and the entire configuration of SMTP, NNTP, IMAP and POP. These aspects at least are kept hidden from meddling with the IIS Manager tool!
The trick is to always use ESM console to configure those options that it can perform, such as creation of virtual directories and servers, authentication and access control, and execute permissions. Use IIS console only for the remaining functions such as SSL certificates and IP restrictions. Be aware that some of DS2MB’s influence goes beyond what is visible in ESM console, including the configuration of the ‘ExchWeb’ virtual directories.
Summary of Gotchas
The following list summarises some of the problems mentioned above and adds one or two more. Microsoft may address these issues in the future, and they certainly have made changes in that direction with SP1.
Microsoft did publish a Knowledge Base article numbered 817379 that addresses some of these issues. This fix is not very pretty and there may be better ways of dealing with the problems. However, Microsoft has revealed some of their intended route for Exchange HTTP access in SP1, so in the meantime don’t expect any alternatives to the KB817379 fix from Microsoft.
- OWA has the option for a ‘forms based’ authentication method. If this is enabled on a backend server the ‘Exchange’ directory will be automatically configured for Basic authentication only and SSL only will be recommended. OWA frontend servers, OMA and EAS all require ‘Integrated’ authentication and no SSL on the ‘Exchange’ directory so will fail to work when ‘forms based’ authentication is enabled in this way.
- The OMA application creates its WebDAV and content requests without the host-header from the original client requests. As a result only one HTTP virtual server configured with no host headers on port 80 can pick up these requests. Therefore OMA can only support one configured SMTP domain.
- EAS uses a different mechanism for handling requests than does OWA and OMA. That difference makes handling multiple SMTP domains very awkward if EAS is left in its default configuration state. The work-around involves tricky registry editing, and prevents EAS from working with more than one SMTP domain.
- The default ‘Exchange’ directory that Exchange creates in IIS is configured for the default SMTP domain and this cannot be changed. When dealing with multiple SMTP domains prior to SP1 for Exchange 2003 this was irritating when configuring OWA (see next); it remains an irritant with OMA and EAS if these features are left configured in the default manner.
- Prior to SP1 for Exchange 2003, virtual directories and servers for OWA would only be accessible to users who had an email address in the SMTP domain configured for that virtual directory or server. This may have been useful to control access on a hosted Exchange system, but with SP1 Microsoft have removed this restriction anyway.
Because OMA only works with one SMTP domain and EAS is best configured to work with one SMTP domain, it is reasonable to configure OWA that way too even when supporting multiple SMTP domains! The way of doing this is to give everyone a secondary email address in a common SMTP domain so that you are effectively only having to support a single SMTP domain.
Conclusions
Since Exchange 2003 was released configuring the new HTTP access methods has caused many a headache for administrators. Most of these problems were due to the barely documented and sometimes bizarre way in which these features work. This article has tried to explain many of mechanisms behind the features in the hope of enlightening readers to what is going on and allowing them to work-around some of the problems when configuring HTTP access.
The introduction of SP1 for Exchange 2003 provides some relief to problems configuring OWA, but the relevant changes in SP1 are very much ‘work-in-progress’ and do not offer a complete solution; OMA and EAS are still stuck with the old way of doing things. Perhaps by SP2 we’ll see OMA and EAS catch up with these improvements; or perhaps be reinvented into something even better?
