Best Practices for Mobile Messaging Deployment with Exchange Server 2010

Article
07/02/2010

7/2/2010

This topic details the best practices for deploying Microsoft mobile messaging in a manner that will help meet your organization's security requirements.

Network Configuration

Regardless of the network configuration you implement, there are some network configuration best practices that will help strengthen your mobile messaging solution.

Distributed Server Roles in Microsoft Exchange Server 2010

Microsoft Exchange Server 2010 enables you to create Exchange Server roles that let you select which Exchange components are installed on each server. For Exchange ActiveSync, the Exchange component used to communicate with the phone, the Exchange Server role is the Client Access Server role. As a best practice, the Client Access Server role should be domain joined and in the same Active Directory site as the Exchange Mailbox role. Another best practice is to route Internet traffic through a reverse proxy or firewall, such as ISA 2006. ISA 2006 has built-in security functionality, such as SSL bridging, user authentication, and packet inspection.

In this network diagram, the Client Access Server is responsible for Exchange Server 2010 Exchange ActiveSync communication. ISA Server 2006 SP1 sits in the perimeter network and filters inbound requests to the Client Access Server. One advantage of using a distributed architecture is offloading CPU and memory utilization from a single server. Depending on the size of your organization, this topology may help to increase overall mobile messaging system performance. In smaller implementations, you can deploy both the Client Access Server and the Mailbox Server roles on the same machine.

For more information on server roles and planning an Exchange Server 2010 distributed deployment, see P under Microsoft Exchange Server 2010 on the Microsoft TechNet Web site.

Best Practice: Configuring your Firewall for Optimal Direct Push Performance

To optimize mobile client bandwidth, it is important to understand the consequences of HTTP timeout settings on your firewalls and other devices that are in line with your Exchange Client Access Server.

When a phone that is Direct Push enabled establishes a long-lived HTTPS connection with Exchange ActiveSync, there are only two ways that the connection is returned back to the client via a response. The first is when a change is made to the user’s mailbox and Exchange ActiveSync returns a response to the phone alerting it to synchronize with the Exchange server. The second case is when the Direct Push connection heartbeat interval expires and Exchange ActiveSync directs the phone to send up a new Direct Push request. If your firewall’s HTTP timeout is shorter than the Direct Push heartbeat interval, the phone will need to send up a new request. Over time, this can cause extra bandwidth utilization, so Microsoft recommends setting your firewall timeout to 30 minutes. The longer the timeout, the fewer timeouts will be experienced, thus improving bandwidth consumption.

The following illustration shows the recommended firewall settings.

Note

For a technical discussion of Direct Push Technology, see Understanding Direct Push and Exchange Server 2010.

Security Features: Authentication and Certification

Microsoft strongly recommends that you use SSL to encrypt the channel between the phone and Exchange ActiveSync. This deployment step is relevant regardless of the size of your organization. Some SSL vendors who sell less expensive SSL certificates already have their trusted root certificate on Windows® phones, so you may not need to “touch” each phone.

Another best practice is to pass all Internet traffic for Exchange ActiveSync through a reverse proxy and firewall, such as ISA 2006.

Best Practice: Use SSL for Encryption and Server Authentication

To help protect outgoing and incoming data, deploy SSL to encrypt all traffic. You can configure SSL security features on an Exchange server to help prevent internet attacks such as the "man in the middle" and certain server spoofing attacks. The Exchange server, just like any Web server, requires a valid server certificate to establish SSL communications.

Phones with Windows Mobile 6.5 are shipped with trusted root certificates. Check with your device manufacturer for a list of the certificate authorities that shipped with your devices. If you obtain a root certificate from one of the trusted services, your client phones should be ready to establish SSL communications with no further configuration. If you create your own certificates, you must add those certificates to the root store of each phone.

Note

Some server certificates are issued with intermediate authorities in the certification chain. If IIS is not configured to send all certificates in the chain to the phone during the SSL handshake, the phone will not trust the certificate because the phone does not support dynamically retrieving the other certificates.

For more information about Windows Mobile 6.5 and certificates, see Step 6: Certificate Enrollment and Device Provisioning.

Best Practice: Determine and Deploy a Device Password Policy

Microsoft Exchange Server 2010 includes existing security enforcements, such as password expiration and password history, which can be applied on Windows® phones. An IT professional can administer these settings using the Exchange Management Console. For more information on setting security policies, see Step 5: Configure and Manage Mobile Device Access on the Exchange Server.

Best Practice: Use Web Publishing with Basic Authentication

Many companies require basic authentication over an encrypted channel (SSL). These companies can further secure their mobile deployment by leveraging ISA 2006 to Web-publish the Exchange Server 2010 server. The benefit of leveraging ISA server's Web-publishing capabilities is that ISA server has built-in logic to distinguish well-formed requests, such as Exchange ActiveSync requests, which can help protect the Exchange Client Access server from malicious attacks.

As a best practice, Web publishing is easier to implement and provides a higher level of security than server publishing.