Best Practices for Mobile Messaging Deployment

6/2/2010

This section 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 Exchange 2007

One of the changes in Exchange Server 2007 is the creation of Exchange Server roles that enable you to select which Exchange components are installed on each server. For Exchange ActiveSync, the Exchange component used to communicate with the mobile device, 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, responsible for Exchange Server 2007 ActiveSync communication, is a front-end to the Mailbox Server (back-end). ISA Server 2006 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 2007 distributed deployment, see Planning and Architecture under Microsoft Exchange Server 2007 at https://go.microsoft.com/fwlink/?LinkID=87058&clcid=0x409.

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 inline with your Exchange Client Access Server.

When a mobile device 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 mobile device 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 mobile device to send up a new Direct Push request. If your firewall’s HTTP timeout is shorter than the Direct Push heartbeat interval, the device 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.

For a technical discussion of Direct Push Technology, see Understanding Direct Push in this document.

Security Features: Authentication and Certification

Microsoft strongly recommends that you use SSL to encrypt the channel between the mobile device 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 Mobile devices, so you may not need to “touch” each mobile device.

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.

Windows Mobile 6 devices 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 mobile devices 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 mobile device.

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

Best Practice: Determine and Deploy a Device Password Policy

Exchange Server 2007 has added security enforcement, such as password expiration and password history, which can be applied on Windows Mobile 6 devices. 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 2007 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.