The Outlook Mobile Access (OMA), Exchange ActiveSync, and Remote Procedure Call over Hypertext Transport Protocol (RPC over HTTP) services are similar to Outlook Web Access in that they all use web protocols to provide access to mail resources. Each of these services provides for unique methods of access to an Exchange server, as follows:
OMA and ActiveSync can be enabled in an Exchange organization relatively easily: All that's required is that a box be checked. RPC over HTTP access is more complex, however, and is described in the upcoming section of this chapter, titled "Configuring ISA Server to Secure RPC over HTTP(S) Traffic."
Specific requirements to enabling these types of mail access mechanisms must be taken into account. Getting a better understanding of how these access methods can be secured with ISA is therefore important.
Enabling and Supporting OMA and ActiveSync on the OWA Server
Enabling OMA and ActiveSync is a relatively straightforward process, but one that requires that certain special steps be taken in particular circumstances. Particular attention needs to be taken when SSL is used and when Exchange front-end servers are not. First and foremost, the Exchange Mobile Services must be enabled in an Exchange organization.
Enabling OMA and ActiveSync in Exchange System Manager
OMA and EAS can be enabled in an Exchange organization by an Exchange Administrator via the following procedure:
Enabling or Disabling OMA and EAS on a Per-Mailbox Basis
By default, all mailbox-enabled users in an Exchange organization have OMA and EAS individually enabled. If OMA and EAS access needs to be disabled for an individual user, or to verify that it is indeed enabled for that user, the individual setting can be found on the Exchange Features tab of an individual user account in Active Directory, as shown in Figure 13.2.
Figure 13.2. Validating OMA and EAS per-mailbox settings.
Supporting OMA and ActiveSync on an OWA Server Configured as a Backend Mailbox Server
One of the most misunderstood and confusing topics with OMA and EAS has to do with how to enable mobile services on an Exchange OWA server that operates both as an Exchange SSL-enabled OWA server and an Exchange mailbox server. In these cases, mobile services fail to work properly, with error messages such as Synchronization failed due to an error on the server... or Currently your mailbox is stored on an older version of Exchange Server.... To understand why these error messages occur, and how to fix them, it is important to understand how EAS and OMA access mail resources, and how specific SSL or forms-based authentication settings can break this.
A standard IIS Virtual Server for web-based mail access uses specific virtual directories to make calls into the Exchange database. For example, the /exchange virtual directory is used to display individual mailboxes; the /public virtual directory is used for public folders; and the /exchweb virtual directory is used for mailbox maintenance tasks, such as rule configuration and out-of-office settings. When Secure Sockets Layer (SSL) encryption is forced on an OWA server, however, the /exchange and /public directories are modified to force all connections made to them to use SSL only.
Now, this is all fine when OWA is the only web-based access mechanism used. OWA users negotiate SSL encryption and open a secured tunnel directly to the secured Virtual Directories. Figure 13.3 illustrates this concept.
Figure 13.3. Understanding how OMA and EAS work.
OMA and EAS, however, work in a different way. They have their own virtual directories (/oma and /Microsoft-Server-ActiveSync). As a throwback to the origins of OMA and EAS (which were previously part of a separate product called Mobile Information Server), the server decrypts the OMA and EAS traffic, then opens up a DAV logon from the Exchange server itself to the /exchange virtual directory on the server where the mailboxes for that user are located. The problem arises when the /exchange directory on the server with the mailbox is encrypted via SSL. The DAV logon cannot establish an encrypted session with the virtual directory, and communications fails.
For environments with front-end servers, this is not a problem because the DAV calls are made to the back-end server with the user's mailbox on it. Because front-ends can only communicate to back-end servers over the HTTP Protocol, an Exchange back-end mailbox server would not be configured with SSL anywhere on the virtual server, and OMA and EAS would not have a problem accessing the mailboxes.
For many organizations, however, a single Exchange server is the only system in place, and it performs the duties of both an Exchange front-end and back-end server. These organizations may require the use of SSL or forms-based authentication, and subsequently encrypt the /exchange virtual directory, breaking OMA and EAS traffic.
The solution to this problem is to configure a separate virtual directory for mobile services that has the same functionality as the /exchange virtual directory, but without SSL enabled on it. If the Registry is modified, the Exchange server makes the DAV call to this additional virtual server instead. To avoid having users bypass SSL encryption on the server, this virtual directory must be configured to allow only the local OWA server to access it and to deny connections from other IP addresses. To start the process, the configuration of the /exchange virtual directory must first be saved to an XML file, so it can be used to make a copy of itself. To do this, perform the following steps:
Remember, the entire ExchDAV procedure is necessary only if the environment is configured with a single Exchange server. If front-ends are used, this procedure is not necessary and can interfere with the default front-end/back-end topology.
After the XML file has been created, it can be imported as part of a new virtual directory via the following process:
Now the virtual directory is in place, and the authentication and IP restriction parameters can be inputted. To do this, proceed as follows:
The final step to set this up on the Exchange server is to edit the Registry to point mobile services DAV logons to the ExchDAV virtual directory. To do this, follow this procedure:
For more information on this particular solution, reference Microsoft KB Article #817379 at the URL:
Supporting Mobile Services in ISA when Using Forms-Based Authentication for OWA
For environments that have Outlook Web Access configured to use forms-based authentication through ISA, there is somewhat of a catch-22 in regard to enabling OMA, ActiveSync, and RPC-HTTP (commonly referred to as the Exchange mobile services). The problem arises from the fact that the Listener that the FBA-enabled OWA site uses must be the only Listener that can be bound to the IP address and port where it is assigned, and that the mobile services cannot support FBA authentication tied to the Listener that they use.
To illustrate with a hypothetical situation, say that CompanyABC hosts an OWA presence on the Internet that corresponds to mail.companyabc.com. In this scenario, DNS lookups to this address correspond to 184.108.40.206. CompanyABC's ISA Server, which owns the 220.127.116.11 IP address, is configured with an HTTPS Listener that corresponds to that IP address and answers to all HTTPS requests sent to it.
The problem arises when OMA, RPC-HTTP, and/or ActiveSync traffic need to be sent through the same connection. It fails because the traffic sent to the virtual directory for these mobile services cannot understand FBA authentication. Fortunately, however, there is a workaround for this, but it involves installing and configuring an additional IP address on the external interface of the ISA Server. This IP address is then used by ISA to create an additional Listener that uses basic authentication (encrypted via SSL), which is supported by OMA and ActiveSync.
The only additional requirement is that this traffic be directed to an additional DNS namespace, such as http://mail2.companyabc.com, so that it can be configured to point the external A record for mail2 to the different external IP address. Of course, this requires installing a separate certificate for the additional presence, which may add additional cost to the environment, depending on whether third-party CAs are used. To finish the example, in this case, CompanyABC would install and configure a certificate for mail2.companyabc.com and associate all non-FBA traffic with that particular FQDN.
This solution provides a less than elegant, but fully supported solution to the problem of enabling OMA, ActiveSync, and OWA with FBA at the same time.
If it is not feasible to obtain an additional external IP, DNS name, and certificate, the fallback solution to the problem would be to simply use standard basic authentication with OWA. This would allow all services, including OWA, OMA, ActiveSync, and RPC over HTTPS, to be enabled on the same virtual server and with the same ISA rule.
Deploying Multiple OWA Virtual Servers
To make things more complex, an ISA rule that uses SSL to access OMA across a different Listener requires an Exchange server to have a different web "identity," so that it can use the new certificate name (for example, mail2.companyabc.com). There are a few ways to do this, but the most straightforward way is to configure an additional virtual server on the Exchange OWA server. This configuration can also be used in other scenarios, such as the following:
Fortunately, these scenarios can be accommodated on the OWA server through the creation of additional OWA virtual servers that are associated with a different IP address on the OWA server.
Once again, as previously mentioned, this step can be avoided if basic authentication (without FBA) is used for OMA and EAS and the main OWA publishing rule includes support for the \oma and \Exchange-Server-ActiveSync paths.
Adding IP Addresses to an OWA Server
To start the process of configuring the OWA server to support the second certificate for OMA-EAS, a second IP address needs to be added to the OWA server. Follow the procedure outlined here:
Before a new virtual server can be created, the original OWA Virtual Server must be configured to use the first IP address, rather than all the IP addresses on the server (the default setting). To change this, do the following:
Creating an Additional OWA Virtual Server
After additional IP addresses have been added, they can be used to create the additional OWA presence. After it is created, the additional OWA presence can be individually configured from the original virtual server, enabling an administrator to have two or more instances of OWA running on the same server. This procedure should be performed in Exchange System Manager, not in IIS Manager. To set up an additional virtual server on the OWA server, do the following:
After the virtual server is created, the virtual directories for Exchange need to be created. To do this, perform the following steps:
The capability to create multiple virtual servers for an OWA server gives a great deal of flexibility in supporting a heterogeneous environment that requires different types of authentication mechanisms, access methods, and certificate identities.
Assigning a Second SSL Certificate to the New OMA-EAS Virtual Server
Before SSL can be enabled for the new virtual server, an SSL certificate must be installed and enabled on the site. In addition, the virtual directories must be configured to require SSL. Follow the steps in Chapter 12, in the section that is titled "Enabling Secure Sockets Layer (SSL) Support for Exchange Outlook Web Access," to create the new certificate (for example, mail2.companyabc.com). The only additions to the steps in Chapter 12 are to ensure that the OMA and EAS virtual directories are configured to force SSL, and the Exchange virtual directory is configured not to force SSL, per the reasoning described in the section of this chapter titled "Supporting OMA and ActiveSync on an OWA Server Configured as a Backend Mailbox Server."
After the certificate is installed, it must be exported and imported to the ISA server, via the same procedure described in Chapter 12, in the section "Exporting and Importing the OWA Certificate to the ISA Server." Only then can an additional ISA rule be configured with a separate Listener for non-FBA traffic.
Assigning a New IP Address on the ISA Server for the Additional Web Listener
The first step to enabling support for OMA and ActiveSync on an ISA Server that supports OWA with FBA is to add an additional IP address to the ISA Server for the additional Listener to attach itself to. To do this, perform the following steps on the ISA Server:
If the ISA Server is directly connected to the Internet, an additional public IP address needs to be obtained directly from the Internet Service Provider (ISP) to support this process. In addition, the additional DNS A record must be registered for the new namespace.
Setting Up an Outlook Mobile Access (OMA) and ActiveSync Publishing Rule
After the necessary IP prerequisites and Listener requirements have been satisfied, the OMA and ActiveSync publishing rule can be created.
As an initial cleanup step, the original OWA rule needs to be modified to use only the first IP address, and not all IP addresses on the server (the default). To set this up, do the following:
After setting the primary OWA rule to use only the IP associated with the FBA traffic, the following process can be used to set up the OMA-EAS rule in ISA:
The concept described in this section could easily be extended to create multiple presences for an organization, depending on the type of service being set upfor example, owa. companyabc.com, oma.companyabc.com, eas.companyabc.com, rpc.companyabc.com, pop.companyabc.com, imap.companyabc.com, and the like. The only limitation is the number of IP addresses and certificates that can be created.