Understanding Direct Push and Exchange Server 2010

7/2/2010

Direct Push Technology uses Exchange ActiveSync to keep data on a Windows® phone synchronized with data on a Microsoft Exchange server. There is no longer a reliance on SMS for notification.

Direct Push Technology

Direct Push Technology has two parts: one resides on the phone (client), and the other resides on an Exchange Server 2010 mail server. The following list describes these parts of the technology:

• Windows® phones and other devices that don’t necessarily use Windows Mobile technology use Direct Push. Exchange ActiveSync technology on the phone manages Direct Push communication with the Exchange server. It establishes an HTTP or HTTPS connection with the server for a specified time, and then goes to sleep while waiting for the server to respond. The server responds with either a status indicating that new items were received or that no new items arrived. The phone then sends either a synchronization request or another Direct Push request. The rate at which this occurs is dynamically adjusted based on parameters set by the OEM or mobile operator and how long an idle HTTP or HTTPS connection can be maintained on the operator's network and the customer's enterprise network.
• Exchange Server 2010 (Client Access Server role installed). This version of Exchange server includes a Direct Push component that augments the Exchange ActiveSync infrastructure by supporting manual and scheduled synchronization. Exchange Server uses IP-based notifications to deliver e-mail, contact, calendar, and task updates to a phone as soon as the information arrives at the server.

When data changes on the server, the changes are transmitted to the phone over a persistent HTTP or HTTPS connection that is used for Direct Push. The time-out value in the mobile operator's network specifies how long the persistent connection will be maintained with no activity.

To keep this connection from timing out between updates, the phone reissues a request when the server responds. This periodic transmission is referred as the heartbeat. The heartbeat is what maintains the connection to the server for Direct Push; each heartbeat alerts the server that the phone is ready to receive data.

The Direct Push Process

Direct Push traffic looks like small HTTP requests to an Internet Web site that take a long time to issue a response. Microsoft recommends that the content of the packets be encrypted using Secure Sockets Layer (SSL) to make it difficult to identify Direct Push traffic by sniffing.

The following steps describe the Direct Push process:

1. The client issues an HTTP message known as a ping request to an Exchange server, asking that the server report whether any changes that occurred in the user’s mailbox within a specified time limit. In the ping request, the client specifies the folders that Exchange should monitor for changes. Typically these are the inbox, calendar, contacts, and tasks.
2. When Exchange receives this request, it monitors the specified folders until one of the following occurs:
   • The time limit expires. The time limit is determined by the shortest time out in the network path. If this occurs, Exchange issues an HTTP 200 OK response to the client.
   • A change occurs in one of the folders, such as the arrival of mail. If this occurs, Exchange issues a response to the request and identifies the folder in which the change occurred.
3. The client reacts to the response from the Exchange server in one of the following ways:
   • If it receives an HTTP 200 OK response indicating that no change occurred, it re-issues the ping request.
   • If it receives a response other than HTTP 200 OK, it issues a synchronization request against each folder that has changed. When the synchronization is complete, it re-issues the ping request.
   • If it does not receive a response from the Exchange server within the time specified, it lowers the time interval in the ping request and then re-issues the request.

Direct Push Adjustment

During the Direct Push process, the phone waits for successive round trips before attempting to adjust the amount of time it needs to keep a connection open with the server. The amount of time that the server should wait for Personal Information Manager (PIM) changes or new mail to arrive before sending OK to the client is called the heartbeat interval.

The heartbeat interval is specified by the client and is sent as part of the ping request. The heartbeat begins at the default rate. The Direct Push algorithm on the client then dynamically adjusts the heartbeat interval to maintain the maximum time between heartbeats without exceeding the time-out value. The adjustment is based on network conditions and on how long an idle HTTP or HTTPS connection can be maintained on the mobile operator's or corporation's network, as well as some settings that the mobile operator can specify.

To determine the optimal heartbeat interval, the algorithm keeps a log of ping requests. If a ping request receives a response, the algorithm increases the interval. If no response is received at the end of the interval, the client determines that the network timed out and decreases the interval.

Using this algorithm, the client eventually determines the longest idle connection possible across the wireless network and corporate firewall.

The following illustration shows how the heartbeat interval is adjusted during typical Direct Push communication between the client and the Exchange server.

The following steps describe the communication. Numbers correspond to the numbers in the illustration above:

1. The client wakes up and issues an HTTP request over the Internet to the Exchange server, and then goes to sleep. To keep the session active, the request states the heartbeat interval, which is the amount of time that the server should wait for PIM changes or new mail to arrive before sending OK to the client. In this illustration, the heartbeat interval is 15 minutes.
2. Because no mail arrived during the heartbeat interval, the server returns an HTTP 200 OK. In this example, the response is lost because either the operator network or the enterprise network was unable to sustain the long-lived HTTP connection; the client never receives it.
3. The client wakes up at the end of the heartbeat interval plus 1 minute (15 + 1 = 16 minutes total).

4. Because no mail arrived during the heartbeat interval, the server returns an HTTP 200 OK.
5. The server response wakes up the client. Because the connection did not time out during the interval, the client determines that the network can support idle connections for at least this length of time. If this was a successive round trip, the client determines that it can increase the interval for the next request.

The Impact of Direct Push on Networks and Exchange Servers

The algorithm that sets the heartbeat also minimizes bytes sent over the air and helps maximize battery life.

Implementing data compression will reduce the packet sizes sent between the Exchange server (Client Access Server role) and the client. However, the amount of bandwidth consumed and whether it will impact the user’s data plan greatly depend on the following factors:

• What the user chooses to synchronize, such as more than the default folders
• How much data is changed in the mailbox and on the Windows® phone

The Impact of Changing the Direct Push Settings

To help you maintain adequate device performance during Direct Push, Microsoft recommends values for the various Direct Push settings.

Heartbeat Interval

The heartbeat interval is set on the phone by the mobile operator. Using a heartbeat interval of 30 minutes helps conserve battery life and reduces bandwidth consumption. When Direct Push sessions are permitted to live longer (such as 30 minutes), there are fewer HTTP round trips, less data sent and received, and less power consumed by the phone.

A heartbeat interval that is too short will keep the user more up to date, but will shorten battery life because of the constant pinging to the server.

Minimum Heartbeat

If a phone that has a heartbeat below the minimum heartbeat level requests a connection to the Exchange server, the server logs an event to alert the administrator that Direct Push is not working.

Exchange Session

To keep phone information up to date while helping to maximize battery life, the Exchange server session duration should be a little greater than the maximum heartbeat setting. If the server session is shorter, it may reach idle timeout, causing it to drop the session. This would result in mail being undelivered until the client reconnects, and the user could be unsynchronized for long periods of time.

Firewall Timeouts

The network idle connection timeout indicates how long a connection is permitted to live without traffic after a TCP connection is fully established.

The firewall session interval must be set to allow the heartbeat interval and enterprise session interval to communicate effectively. If the firewall closes the session, mail would be undelivered until the client reconnects, and the user could be unsynchronized for long periods of time. By setting the firewall session timeout equal to or greater than the idle timeout on the mobile operator's network, the firewall will not close the session.

Set the firewall's idle connection timeouts:

• Microsoft recommends that mobile operators set the idle connection timeouts on outgoing firewalls to 30 minutes
• Organizations need to set timeouts on their incoming firewalls to 30 minutes

Web servers, network security appliances, and system network stacks have several time-based thresholds that are intended to insulate them from insufficiently tested or malicious clients. You can safely increase the idle connection timeout setting without compromising the security of the network.

In a Direct Push scenario, the connection is idle between the time that the HTTP request is made and either 1) the time that the heartbeat interval expires, or 2) the server responds to the request with a change (such as when mail is received). Direct Push makes no assumption as to the length of its sessions; e-mail is delivered rapidly whether the heartbeat interval is one minute or 30 minutes.

Increasing the idle connection timeout typically does not increase or decrease exposure to attack. The following table shows examples of attacks and describes how other settings are used to mitigate exposure to them.

Denial of service (DoS) threat	Mitigation of exposure to attacks
A DoS attack is launched by failing to complete the handshake that is implicit in the creation of a TCP connection. The attacker attempts to create a large number of partially open TCP connections.	Increasing the idle connection timeouts is unrelated to this type of attack. The time within which a TCP handshake must be completed is a separate threshold that is governed by the Windows TCP/IP stack.
A DoS attack is launched against IIS by opening a large number of TCP connections but never issuing an HTTP request over any of them.	Increasing the idle connection timeouts is unrelated to this type of attack. IIS mitigates this threat by requiring that a client submit a fully-formed HTTP request within a certain time before dropping the connection. The name of the connection timeout setting in the IIS management console is misleading; TCP connections are closed when the connection timeout value is exceeded (120 seconds by default).
An attacker establishes a large number of TCP connections, issues HTTP requests over all of them, but never consumes the responses.	Increasing idle connection timeouts is unrelated to this type of attack. This threat is mitigated by the same timeout as the previous scenario. The connection timeout setting in IIS defines the time within which a client must issue either its first request after a TCP connection is established or a subsequent request in an HTTP keep-alive scenario. Note: Applies to Exchange Active Sync listener only.

See Also

Concepts

Deploying Mobile Messaging for Microsoft Exchange Server 2010