Configuring ISA Server 2004 to Support OMA and ActiveSync Access to Exchange

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:

• Outlook Mobile Access (OMA) OMA allows web-enabled phones and other mobile devices to have access to mailbox resources via a simple, streamlined interface that displays only simple text.

• Exchange ActiveSync (EAS) Exchange ActiveSync allows ActiveSync-enabled phones, such as those running Mobile 2003 or PocketPC 2002, to synchronize content remotely with the Exchange server wirelessly or while docked to a workstation. This combined with the "always up-to-date" functionality of Exchange Server 2003 allows ActiveSync-enabled devices to have full real-time send and receive capabilities, similar to that offered by products such as RIM Blackberry devices.

• RPC over HTTP(S) RPC over HTTP(S) is an extremely useful method of accessing Exchange servers from Outlook 2003 clients anywhere in the world. It uses secure SSL-encrypted web communications between the client and the server. RPC over HTTP(S) can be used in conjunction with Cached mode on Outlook 2003 to offer instant available access to up-to-date email, calendar info, and other mail data whenever a roaming laptop is connected to a network that has SSL access back to the Exchange server, which typically covers most networks on the Internet.

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:

1.	On any Exchange server in the Organization, open Exchange System Manager (Start, All Programs, Microsoft Exchange, System Manager).
2.	Navigate to Global Settings, Mobile Services.
3.	Right-click on Mobile Services and choose Properties.
4.	Check the boxes for ActiveSync and OMA, as shown in Figure 13.1. Enable partial or full access to the services by checking some or all of these check boxes. Click the Help (question mark) for more info on the options. Figure 13.1. Enabling OMA and EAS in an Exchange 2003 Organization.
5.	Click OK to save the changes.

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:

CAUTION

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.

1.	On the Exchange server, start IIS Manager (Start, All Programs, Administrative Tools, Internet Information Services (IIS) Manager).
2.	Expand SERVERNAME (local computer), Web Sites, and choose the OWA Web Site (usually Default Web Site).
3.	Right-click on the /exchange virtual directory and choose All Tasks, Save Configuration to a File.
4.	Enter a filename and a path to which the XML file should be saved, as shown in Figure 13.4. As an optional security precaution, a password can be entered to encrypt the XML file. Click OK. Figure 13.4. Exporting the Exchange virtual directory to an XML file.

After the XML file has been created, it can be imported as part of a new virtual directory via the following process:

1.	Right-click the OWA Virtual Server (Default Web Site) and choose New, Virtual Directory (from file).
2.	Type the path of the XML file created in the previous steps and click Read File.
3.	Select the Exchange configuration and click OK.
4.	When prompted that the virtual directory still exists, select Create a New Virtual Directory, enter ExchDAV as the alias, and click OK.
5.	Enter the password entered when exporting the file (if prompted).

Now the virtual directory is in place, and the authentication and IP restriction parameters can be inputted. To do this, proceed as follows:

1.	Right-click the ExchDAV virtual directory and choose properties.
2.	Select the Directory Security tab and click on the Edit button under the Authentication and Access Control section.
3.	Check only Integrated Windows Authentication and Basic Authentication; leave everything else unchecked and click OK.
4.	Under Secure Communications, click the Edit button.
5.	Make sure that SSL is not enabled (uncheck the boxes for Require Secure Channel if they are checked) and click OK.
6.	Under IP Address and Domain Name Restrictions, click the Edit button.
7.	Configure all connections to be denied by changing the setting to Denied Access. Enter an exception for the local Exchange server by clicking Add and entering the IP address of the local server, as shown in Figure 13.5. Figure 13.5. Locking down the ExchDAV folder so that only the local server can initiate DAV logon calls for OMA and EAS.
8.	Click OK and OK to save the changes.

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:

1.	Open regedit (Start, Run, regedit.exe, OK).
2.	Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MasSync\Parameters.
3.	Right-click the Parameters folder, and select New, String Value.
4.	Enter ExchangeVDir as the name of the value.
5.	Double-click on ExchangeVDir and enter /ExchDAV as the Value data; click OK to save the changes. The setting should look like what is shown in Figure 13.6. Figure 13.6. Configuring the Registry settings for the ExchDAV changes.
6.	Close Registry Editor, and restart IIS from IIS Manager (right-click the Servername and choose All Tasks, Restart IIS, OK).

NOTE

For more information on this particular solution, reference Microsoft KB Article #817379 at the URL:

http://support.microsoft.com/kb/817379/EN-US/

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 63.240.93.138. CompanyABC's ISA Server, which owns the 63.240.93.138 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.

Avoiding Dual Authentication Approaches

If forms-based authentication is not utilized directly on the ISA Server, this problem does not exist, and the OMA and ActiveSync publishing rules can be configured as part of the same OWA publishing rule itself, or a new rule can be configured to use the same Listener. In this scenario, the additional IP address, DNS A record, and additional certificate are no longer necessary; standard SSL-encrypted basic authentication can be used. The downside is that the increased security and functionality of FBA is lost and the user is prompted with the standard Username/Password dialog box.

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.

TIP

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:

• A need exists to have an SSL-secured OWA (for external clients) in addition to a standard HTTP OWA (for internal clients).

• Different SSL OWA web presences need to be implemented (such as mail. companyabc.com, mail2.companyabc.com, mail.companyxyz.com) with unique certificates.

• OWA with forms-based authentication and OWA without FBA need to be allowed.

• OWA with FBA through ISA, and OWA with FBA directly to Exchange, need to be set up.

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:

1.	From the OWA Server, click Start, Control Panel, Network Connection, then locate the OWA NIC from the list, right-click it, and choose Properties.
2.	On the General tab, double-click Internet Protocol (TCP/IP).
3.	Click the Advanced button.
4.	Under IP Settings, click Add.
5.	Enter the additional IP address and its corresponding mask and click Add.
6.	Add any additional IP addresses to the dialog box.
7.	Click OK three times to save the settings.

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:

1.	Open IIS Manager.
2.	Right-click the original OWA Virtual Server (often called Default Web Site) and choose Properties.
3.	Under IP Address, change the drop-down box to display only the first IP address on the server and click OK.

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:

1.	On the OWA Server, open Exchange System Manager (Start, All Programs, Microsoft Exchange, System Manager).
2.	Expand ORGNAME (Exchange), Administrative Groups, ADMINGROUPNAME, Servers, SERVERNAME, Protocols, HTTP.
3.	Right-click the HTTP folder and choose New, HTTP Virtual Server.
4.	Enter a descriptive name in the Name field, and change the IP address to match the additional IP address added to the server in the previous steps.
5.	Select the Access tab and click the Authentication button.
6.	Change the authentication settings to allow only basic authentication and clear Integrated Windows Authentication. Click OK twice when finished making changes.

After the virtual server is created, the virtual directories for Exchange need to be created. To do this, perform the following steps:

1.	Right-click the newly-created virtual server and choose New, Virtual Directory.
2.	Enter Exchange for the name, and leave the default path as Mailboxes for SMTP Domain, as shown in Figure 13.7. Figure 13.7. Creating a second instance of the Exchange virtual directory.
3.	Change the authentication settings under the Authentication button to support Basic authentication and click OK, OK.
4.	Right-click the virtual Server again and choose New, Virtual Directory.
5.	Enter a name of Public in the Name field, and choose Public Folder under Exchange Path, set the Access Authentication to Basic Only (no Integrated for the rest of the virtual folders), then click OK, OK.
6.	Right-click the virtual server again and choose New, Virtual Directory.
7.	Enter a name of oma in the Name field and choose Outlook Mobile Access under Exchange Path. This time, authentication does not need to be changed because it is inherited from the root. Click OK.
8.	Right-click the virtual server again and choose New, Virtual Directory.
9.	Enter a name of Exchange-Server-ActiveSync, and choose Exchange ActiveSync under the Exchange Path field. No need to change authentication, so click OK.
10.	Restart IIS by right-clicking the server name and choosing All Tasks, Restart IIS and clicking OK.

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:

NOTE

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.

1.	From the ISA Server, click Start, Control Panel, Network Connection, then locate the external NIC from the list, right-click it, and choose Properties.
2.	On the General tab, double-click Internet Protocol (TCP/IP).
3.	Click the Advanced button.
4.	Under IP Settings, click Add.
5.	Enter the additional IP address (see the note above about obtaining an additional Public IP) and its corresponding mask and click Add.
6.	Click OK three times to save the settings.

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:

1.	In the Details pane of the ISA console, double-click on the OWA rule previously created.
2.	Select the Listener tab.
3.	Click Properties.
4.	Select the Networks tab.
5.	Double-click on the external network.
6.	Select to listen for requests on specified IP addresses, select the primary IP address of the ISA Server, and click Add, similar to what is shown in Figure 13.8. Figure 13.8. Modifiying the OWA rule to use only the primary IP address on the server.
7.	Click OK, OK, OK, Apply, and OK to save the changes.

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:

1.	Open the ISA Management Console and select the Firewall Policy node from the console tree.
2.	In the Tasks tab of the Tasks pane, click the link for Publish a Mail Server.
3.	Enter a descriptive name for the rule, such as OMA-EAS Access, and click Next.
4.	Keep the default at Web Client Access and click Next to continue.
5.	Uncheck Outlook Web Access and check Outlook Mobile Access and Exchange ActiveSync instead, as shown in Figure 13.9. Figure 13.9. Setting up an OMA-EAS ISA publishing rule.
6.	Select to maintain a secure connection to both clients and server and click Next.
7.	Enter the mail server name (i.e. mail2.companyabc.com). Make sure the host name is addressable from the ISA server and that it points to the secondary IP of the OWA server. Click Next to continue.
8.	Enter the FQDN again (for example, mail2.companyabc.com) under the Public Name Details tab, as shown in Figure 13.10 and click Next to continue. Figure 13.10. Setting up the public name details of the OMA-EAS ISA publishing rule.
9.	Under Web Listener, click New.
10.	Enter a descriptive name for the Web Listener into the name field and click Next.
11.	Check to listen for requests from the External network and click the Address button.
12.	Select Specified IP Addresses on the ISA Server Computer in the selected network, and choose the secondary IP address configured in the previous steps. Click Add when selected and click OK.
13.	Click Next to continue.
14.	Uncheck Enable HTTP and check Enable SSL. Click the Select button to select the new certificate and click OK. Click Next to continue.
15.	Click Finish to create the new Listener.
16.	Click Edit to edit the settings of the newly created Listener.
17.	Select the Preferences tab.
18.	Under Configure Allowed Authentication Methods, click the Authentication button.
19.	Uncheck Integrated and click OK to acknowledge the warning.
20.	Select Basic by checking the box next to it, as shown in Figure 13.11. Figure 13.11. Configuring the OMA-EAS Listener.
21.	Click the Select Domain button.
22.	Enter the default domain name into the field, (for example, companyabc.com) if one will be needed. This enables users to simply enter a username instead of domain/username. Click OK three times to save the settings.
23.	Click Next to continue.
24.	Keep the default at All Users and click Next.
25.	At the completion screen, click Finish.
26.	Click Apply and OK to save the changes to ISA.

NOTE

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.