Requirements and Best Practices for Using MSFP
This section presents the requirements and best practices for MSFP.
- MSFP Requirements
- Network Requirements
- Best Practices for the Direct Push Technology
- Performance Considerations
- Exchange Server 2003 SP2 or later.
- Device synchronization directly with the Exchange Server. PC synchronization is needed only for Certificate-based Authentication, which requires a one-time connection to ActiveSync for certificate deployment and periodic connection at certificate renewal time.
- ActiveSync 4.1 or later for the Windows XP or Windows 2000 desktop.
An MSFP device includes the correct version of ActiveSync.
To use the GAL functionality, users must have some type of data connection (GPRS or desktop pass-through using ActiveSync 4.1).
- Port 443 must be open (this is the port for SSL/HTTPS).
- The idle connection timeouts on port 443 must be 1800 seconds (30 minutes).
Best Practices for the Direct Push Technology
Raise the timeouts on network firewalls to 30 minutes
Firewall HTTP connection timeouts to the ActiveSync virtual directory should be raised to 30 minutes.
Users should have a long-lived data connection
Users should have a service that allows them to maintain a long-lived connection for direct push. This allows the client to keep an IP based HTTP connection with the server alive within the coverage area, which allows for a faster and more reliable E-mail experience.
Keep the HeartbeatMin at the Microsoft default value of 8 minutes when possible.
Microsoft Recommends that Mobile Operators consider keeping HeartbeatMin at the Microsoft default value of 8 minutes. The heartbeat algorithm adjusts to maintain the longest time possible. The HeartbeatMin value is the minimum number of seconds that a client waits between issuing heartbeat commands. The default value is 480 seconds (8 minutes). Typically, a client does not operate at the minimum heartbeat, but tunes automatically to the highest value supported by the Enterprise firewall and operator network.
For information about the impact of changing this setting, see The Impact of Changing the Direct Push Settings.
The following table discusses performance considerations.
Bandwidth needed for heartbeat
Currently, each heartbeat roundtrip is about 600 bytes.
Assuming a heartbeat interval between 15 and 30 minutes, and if no E-mail arrives, then direct push would consume 0.53 to 1.06 MB per month. Since this value assumes that no E-mail arrives, it is not realistic, but can be used as a baseline. This value does not reflect any optimization and does not reflect the bandwidth used by other features, such as downloading large attachments or Web browsing. The bandwidth used by this service will also depend on what the user has chosen to synchronize.
Initial testing has indicated that device battery life is good when using the recommended values for the configuration parameters.
The rate at which the client transmits to the server, the heartbeat interval, is adjusted dynamically according to configuration parameters that you can set.
For information about the configuration parameters, see Parameters Used for Dynamically Adjusting the Heartbeat Interval in Heartbeat Interval Adjustment.
If the client does not receive a heartbeat response from the server within the current heartbeat timeout window, it must open a new HTTP connection and reissue the heartbeat. If the phone is in suspend mode, it must wake up to perform this action, consuming additional battery power.
Microsoft has done extensive battery life testing and trials of the direct push solution, and has found that, battery usage is good when using the recommended values for the configuration parameters.
The longer the connection can remain idle on the operator network, the less often the device will have to wake up and re-transmit, and the longer the battery life will be.
Microsoft recommends that the operator network have an idle timeout of at least 30 minutes to ensure optimal battery life.
By default, the notification sound that plays when an item is synchronized is turned off. This behavior helps to preserve battery life because a user is less likely to turn on the device's backlight to see the new item, causing an additional drain on the battery.