Applies to: Exchange Server 2007 SP3, Exchange Server
2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2009-02-18
Direct Push is a feature that is built into Exchange Server 2007. Direct Push is designed to keep a mobile device up-to-date over a cellular network connection. Introduced in Exchange Server 2003 Service Pack 2, Direct Push provides notification to the mobile device when new content is ready to be synchronized to the device.
For Direct Push to work, you must have a device that is Direct Push capable. These devices include the following:
- Cellular telephones that have Windows Mobile® 5.0 and the
Messaging & Security Feature Pack (MSFP) and later versions of
Windows Mobile software.
- Cellular telephones or mobile devices that are produced by
Exchange ActiveSync licensees and are designed specifically to
be Direct Push compatible.
By default, Direct Push is enabled in Exchange 2007. Mobile devices that support Direct Push issue a long-lived HTTPS request to the Exchange server. The Exchange server monitors activity on the users’ mailbox and sends a response to the device if there are any changes, such as new or changed e-mail messages or calendar or contact items. If changes occur within the lifespan of the HTTPS request, the Exchange server issues a response to the device that states that changes have occurred and the device should initiate synchronization with the Exchange server. The device then issues a synchronization request to the server. When synchronization is complete, a new long-lived HTTPS request is generated to start the process over again. This guarantees that e-mail, calendar, contact, and task items are delivered quickly to the mobile device and the device is always synchronized with the Exchange server.
Direct Push Topology
Figure 1 illustrates a typical Exchange Server 2007 topology that is configured for Direct Push. This figure assumes that you have the Client Access server role and the Mailbox server role installed on two separate Exchange Server computers. You can also install both server roles on the same physical Exchange 2007 computer.
Figure 1 Direct Push Network Design
Direct Push operates in the following way:
- A mobile device that is configured to synchronize with an
Exchange 2007 server issues an HTTPS request to the server.
This request is known as a ping. The request tells the server to
notify the device if any items change in any folder that is
configured to synchronize in the next 15 minutes. Otherwise, the
server should return an HTTP 200 OK message. The mobile device will
then stand by. The 15-minute time span is known as a heartbeat
- If no items change in 15 minutes, the server returns a response
of HTTP 200 OK. The mobile device receives this response, resumes
activity (called waking up), and issues its request again.
This restarts the process.
- If any items change or new items are received within the 15
minute heartbeat interval, the server sends a response that informs
the mobile device that there is a new or changed item and the name
of the folder in which the new or changed item resides. After the
mobile device receives this response, it issues a synchronization
request for the folder that has the new or changed items. When
synchronization is complete, the mobile device issues a new ping
request and the whole process starts over.
Direct Push depends on network conditions that support a long-standing HTTPS request. If the carrier network for the mobile device or the firewall does not support long-standing HTTPS requests, the HTTPS request is stopped. The following steps describe how Direct Push operates when a mobile device's carrier network has a time-out value of 13 minutes.
- A mobile device issues an HTTPS request to the server. The
request tells the server to notify the device if any items change
in any folder that is configured to synchronize in the next 15
minutes. Otherwise, the server should return an HTTP 200 OK
message. The mobile device then stands by.
- If the server does not respond after 15 minutes, the mobile
device wakes up and concludes that the connection to the server was
timed out by the network. The device reissues the HTTPS request,
but this time uses a heartbeat interval of eight minutes.
- After eight minutes, the server sends an HTTP 200 OK message.
The device will then try to gain a longer connection by issuing a
new HTTPS request to the server that has a heartbeat interval of 12
- After four minutes, a new e-mail message is received and the
server responds by sending an HTTPS request that tells the device
to synchronize. The device synchronizes and reissues the HTTPS
request that has a heartbeat of 12 minutes.
- After 12 minutes, if there are no new or changed items, the
server responds by sending an HTTP 200 OK message. The device wakes
up and concludes that network conditions will support a heartbeat
interval of 12 minutes. The device will then try to gain a longer
connection by reissuing an HTTPS request that has a heartbeat
interval of 16 minutes.
- After 16 minutes, no response is received from the server. The
device wakes up and concludes that network conditions cannot
support a heartbeat interval of 16 minutes. Because this failure
occurred directly after the device tried to increase the heartbeat
interval, it concludes that the heartbeat interval has reached its
maximum limit. The device then issues an HTTPS request that has a
heartbeat interval of 12 minutes because this was the last
successful heartbeat interval.
|Windows Mobile 6.1 includes improvements to the synchronization process. With Windows Mobile 6.1, the concept of "parking a request" remains. However, Windows Mobile 6.1 supports Exchange ActiveSync version 12.1. Exchange ActiveSync 12.1 supports parking the actual synchronization request, not only the ping request. Therefore, if new content arrives within the configured time limit, the HTTP response to the synchronization request will contain content. This behavior speeds content transfer and helps extend battery life on the device.
The mobile device tries to use the longest heartbeat interval the network supports. This extends battery life on the device and minimizes the amount of data that is transferred over the network. Mobile carriers can specify a maximum, minimum, and initial heartbeat value in the registry settings for the mobile device.
Configuring Direct Push to Work Through Your Firewall
For Direct Push to work through your firewall, you must open the following port:
- TCP port 443 is required for Secure Sockets Layer (SSL) and
must be opened between the Internet and the Exchange Server
computer that has the Client Access server role installed.
In addition to opening ports on your firewall, for optimal Direct Push performance, you should increase the time-out value on your firewall from the default to 15 to 30 minutes. The maximum length of the HTTPS request is determined by the following settings:
- The maximum time-out that is set on the firewalls that control
the traffic from the Internet to the Exchange server that has the
Client Access server role installed
- The firewall time-outs that are set by the mobile carrier
A short time-out value causes the device to initiate a new HTTPS request more frequently. This can shorten battery life on your device. For more information about how to configure your firewall, see the ISA Server Product Documentation.
For More Information
For more information about Direct Push and how to synchronize mobile devices with Exchange 2007, see the following topics: