Instead of using SMS messages, Microsoft Direct Push technology works by maintaining a constant HTTPS connection...
between mobile devices and Exchange Server. Because the connection is constantly available, new email messages can be delivered to mobile devices nearly instantaneously.
The pros and cons of Direct Push HTTPS connections
Having a constant HTTPS connection raises a few concerns. For starters, some mobile devices are unable to receive voice calls while data is being transmitted or received. Another common concern is that sending and receiving data consumes as much battery power as voice calls do.
Although these are some serious issues, Microsoft has taken steps to minimize the impact of sending and receiving data. Direct Push will not completely drain a mobile device's battery in a couple of hours. The mobile device does maintain a constant HTTPS connection with the Exchange Server, but it is not constantly sending or receiving data.
This is possible because the HTTP and HTTPS protocols were designed for distributed networks, and do not assume that HTTP or HTTPS messages will be delivered and responded to instantaneously.
Instead, there is a timeout value associated with an HTTP or HTTPS session. When a sender transmits a packet, it doesn't really matter how long it takes to receive a response, so long as the response comes before the session times out. Direct Push takes advantage of this by allowing the mobile device to go to sleep between packets.
Direct Push heartbeat messages
Direct Push uses heartbeat messages to keep a session alive between Exchange Server and mobile devices. A heartbeat is nothing more than a periodic transmission that keeps the session open and allows the mobile device to check to see if synchronization is necessary.
The process begins when the mobile device initiates a session with Exchange Server. Upon doing so, the mobile device transmits a heartbeat message to the server at a predefined interval. At this point, one of three things will happen:
- The Exchange server will respond with new synchronization data. In this case, the new data is synchronized with the data that's stored on the mobile device.
- The Exchange server will respond with an HTTP 200 OK message. This means that there wasn't any new data to be synchronized. More importantly, it means that the session did not time out.
When the mobile device receives this response it may try to dynamically adjust its heartbeat interval so that there will be a longer period of time between heartbeats. Remember that the longer the period of time between heartbeats, the lower the battery consumption. Longer heartbeat intervals also decrease the chances that heartbeats will be disruptive to attempted voice calls.
- The session times out before the heartbeat interval is reached. When this happens, Exchange automatically lowers he heartbeat interval in an effort to prevent the Direct Push session from timing out.
It's easy to see how a Direct Push session can be kept alive by transmitting a heartbeat and waiting for a response. However, based on my description above, it might seem like a lot is left to chance. For example, how does Exchange Server know how much to adjust the heartbeat interval? Or what if something happens that disrupts the communication process?
In reality, nothing is left to chance. Microsoft has built quite a bit of intelligence into the dynamic adjustment of Direct Push heartbeats.
Microsoft knows that there are factors that can cause heartbeats to occur abnormally. For example, if the Exchange server were to suddenly become busier than expected, then the server might not be able to respond to a heartbeat message before it expires. That being the case, Exchange Server is designed so that successive roundtrip heartbeats must occur before it adjusts the Direct Push heartbeat interval.
Another way that Microsoft has built intelligence into Direct Push is that Exchange Server is smart enough to know that it should not adjust the heartbeat interval if the heartbeat expires due to a known cause.
For example, if a user is talking on the phone when Exchange Server transmits a heartbeat response, the mobile device will never receive the response and the heartbeat will time out. However, Exchange Direct Push knows that the timeout only occurred because the user was on the phone -- so the heartbeat interval is not adjusted.
Direct Push heartbeat registry keys
The Direct Push heartbeat is controlled by four registry keys:
These values are stored within the registry at:
Keep in mind that editing the registry is dangerous, because making incorrect modifications can destroy Windows and/or your applications. Always make a full system backup prior to making any registry modifications.
HeartbeatDefault refers to the initial heartbeat interval before any adjustments are made. By default, the value for this registry key is set to 480 seconds, or eight minutes.
The HeartbeatMin registry key refers to the minimum amount of time between heartbeats. The minimum heartbeat interval is the same as Microsoft's default heartbeat interval; 480 seconds. Microsoft recommends that you do not adjust this value because lowering it can cause an excessive number of heartbeats to occur -- this will cause the mobile device to consume a lot more battery power. According to Microsoft, lowering this value nets a very small performance gain, which is not substantial enough to warrant the impact on battery life.
The HeartbeatMax value is the maximum amount of time between heartbeats. As I explained earlier, Exchange Server will dynamically increase the amount of time between heartbeats as the mobile device is able to prove that it can handle longer heartbeat durations without timing out.
There has to be a cutoff point though to prevent Direct Push from increasing the heartbeat interval indefinitely. By default, Microsoft sets the maximum heartbeat interval to 1,680 seconds (28 minutes). While researching this tutorial, I found posts on the Internet from administrators who claim to have been able to increase the HeartbeatMax value to 45 minutes, but Microsoft recommends that you do not exceed the default value.
The default value is designed to be just below the network timeout period of most networks. If you set the HeartbeatMax value too high, the mobile device will gradually increase its heartbeat period to the point that the heartbeat times out. When this happens, Exchange Server will lower the heartbeat interval to an acceptable level, but data will remain unsynchronized until this point is reached. It is better to leave the default value in place and prevent timeouts from occurring in the first place.
The most interesting of the four registry keys is HeartbeatIncrement. This key determines how much the heartbeat interval is adjusted at a time. By default, the HeartbeatIncrement value is set to 300 seconds (five minutes). This is also Microsoft's recommended value.
You can adjust the HeartbeatIncrement registry key, but doing so is a little tricky. If you set the heartbeat increment too high, Exchange Server will make large adjustments to the heartbeat interval that could potentially result in timeouts occurring (if the network's timeout threshold is unknown or the HeartbeatMax value has not been set accordingly).
If the heartbeat increment is set too low, then there is less danger of causing a timeout. But, it may take Direct Push a long time to adjust the heartbeat interval to an optimal value. This wouldn't be a big deal except that it means that the mobile device is consuming more battery power than is necessary during the adjustment period.
TUTORIAL: MICROSOFT EXCHANGE DIRECT PUSH TECHNOLOGY
Part 1: How Microsoft Exchange Direct Push technology works
Part 2: Configuring Direct Push technology on Exchange Server 2003 SP2
Part 3: Configuring Direct Push technology on Windows Mobile devices
|ABOUT THE AUTHOR:|
| Brien M. Posey, MCSE
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.