Friday, September 22, 2006

Filling the "Direct Push" Gap for Windows Mobile 2003 Devices

Similar to the Messaging Security & Feature Pack (MSFP) for Windows Mobile 5.0 devices, RoadSync is now available for Windows Mobile 2003 SE handsets.
• Secure, wireless and "Direct Push" synchronization of corporate e-mail, attachments, calendar and contacts with Microsoft Exchange Server 2003 SP2
• Global Address List (GAL) Look-up
• IT Policies including Remote Wipe & Device Passwords
• Mass Configuration Tool available for faster and more managed deployments
Looks like I may have to dig out one of my old 5600's to give this a test. If someone out there using a 2003se device and exchange, has the chance, give this a shot and let us know what you think. I will try it myself, schedule permitting once I can find a phone to get charged up.

Get the Full Detail from Dataviz

Source: MoDaCo

Monday, September 18, 2006

Updated (ver 8.0) of the MS IT Message Hygiene

An updated detailed discussion on how Microsoft IT manages the large quantities of unwanted e-mail (a.k.a. spam) and malware-infected messages in its inbound Internet e-mail traffic. The paper documents how Microsoft IT uses Microsoft Exchange Server 2003 technologies, Microsoft Office Outlook 2003, and third-party solutions to both reduce the quantity of spam routed through the corporate messaging infrastructure by filtering at the gateway layer and then remove the threats in remaining messages posed by viruses, worms, and their common distribution vectors, such as file attachments.


Get the updated Version 8.0 here:

Thursday, June 29, 2006

The Size of UM Messages in Exchange Server 2007

Recently, Michael Wilson posted this blog entry on the size of UM messages….

When talking about Exchange Server 2007 Unified Messaging (UM), we often get a question: "Just how big will those messages be?"

 The size of UM voice messages depends on the size of the attachment that holds the voice data. In turn, the size of the attachment depends on three factors:

           (1) the duration of the recording

          (2) the audio codec used

          (3) the audio storage format

 UM uses one of three codecs for creating voice messages: WMA (Windows Media Audio), GSM 06.10 and G.711 PCM Linear. The WMA codec is always stored in Windows Media format (the attachment is a file with a .wma extension). Audio encoded as GSM or PCM is always stored in RIFF/WAVE format (the attachment is a file with a .wav extension).

 The graph below shows how the size of the audio depends on the duration, for the three codecs used:


PCM is uncompressed, and therefore occupies the most space at a given duration (just over 160,000 bytes for each 10 seconds of audio). It has the highest audio quality of the three. However, WMA and GSM are both acceptable to the vast majority of listeners.


GSM is compressed (just over 16,000 bytes for each 10 seconds).

WMA is the most highly compressed codec (about 11,000 bytes for each 10 seconds). However, the WMA format has a much larger header section than the WAV format (about 7K, compared to less than 100 bytes). WMA recordings become smaller than GSM recordings for durations of about 15 seconds and above. The average call-answered voice message is about 30 seconds long.

WMA is the default setting. GSM or PCM can be used where interoperability with other platforms is of great importance (the WAV format and GSM codec are widely supported).

Wednesday, June 21, 2006

More Exchange analyzer TLA's*

* TLA = Three Letter Acronym


In September 2004, we released the Exchange Best Practices Analyzer (ExBPA).  We followed up on this success in November 2005 with the Performance Troubleshooter (ExPTA) and the Disaster Recovery Analyzer (ExDRA).  Over recent months we have been working on a new analyzer called the Mailflow Troubleshooter (ExMFA).  Looking at our overall tool set, we decided that rather than continue to ship these tools as entirely independent entities, we would unify most of them together under a single umbrella application.  This is how the Exchange Troubleshooting Assistant (ExTrA) was born. 


ExTrA is essentially a union of ExDRA, ExPTA, and the new ExMFA, with a few additional things thrown in.  ExBPA is not currently part of ExTrA.  While we may consider this in the future, the current thinking is that ExBPA is a more proactive tool to be run at any time, and the others are more reactive to be run in response to a particular problem occurring.  All of our analyzer/troubleshooter tools are built off of the same configuration-driven engine, so combining them together was actually a very simple process that did not require us to do any rewriting of the existing logic.  We have essentially just packaged them all together and added a single additional screen that allows you to choose which tool to launch.  This first screen has two sections: a set of symptom-based selections, and a set of related functionality selections.  The initial symptom-based selections will be for troubleshooting mailflow issues, performance issues, or database issues (such as storage mounting problems).  The related functionality will include things like trace control, message tracking search and disaster recovery management (some may be available only for Exchange 2007 servers, however). 


Over time, we will be adding to these selections, and creating deeper integration between the components (like ExBPA, ExTrA is configuration driven and will be updated on a regular - probably monthly - basis).  Initially, when you select, for example, performance troubleshooting, the experience from that point on will be exactly the same as if you had launched ExPTA independently.  We will eventually blur the lines a little bit to make them function more as a whole.  For instance, mailflow and performance troubleshoot overlap to some degree.  Both areas will eventually branch back to the same symptom/root cause branch when tracking down the same type of problem (i.e. slow mailflow).  Another example of this would be if you are troubleshooting a store mounting issue and it concluded a database corruption was the root cause, it would branch automatically over to disaster recovery management to allow you to begin that process seamlessly.


ExTrA is intended to eventually become the one-stop shop for all Exchange troubleshooting needs, and in turn it will get more heavily integrated into the Exchange product itself.  We are very excited about releasing this tool, and are committed to following through with it over the upcoming years in the same way we've done with ExBPA in the past. 


Now, a little more about the new mailflow troubleshooting functionality we're adding.   Like performance, mailflow is controlled by many interacting processes and settings, and when something is not working right discovering the root cause can be quite difficult and requires a good deal of product expertise to do.  The mailflow troubleshooter attempts to walk a user through the process by starting with a symptom and working towards root cause.  The initial set of symptoms we will deal with are:


·         Non-delivery reports (NDR's) are being received.

·         Mail from an external source is slow or blocked.

·         Mail to an external source is slow or blocked.

·         Mail queues are backing up.


For example, when a remote delivery queue is backing up, the mailflow troubleshooter analyzes DNS for incorrect configurations, checks network connectivity (e.g. black hole routers), throws a series of SMTP commands to remote hosts, diagnoses link state data and more to identify possible root causes. Similarly, different sets of troubleshooting steps are prepared to tackle each symptom.


Like the other troubleshooters, we will be adding more sophistication into the logic over time.  New symptoms will be added and more root causes will be automatically identified.  We have been beta testing this functionality within our support team, and the early results indicate that this will have as immediate and positive an impact as ExBPA and ExPTA have had.


ExDRA has not yet enjoyed the same kind of success as the other analyzer/troubleshooter tools have had, largely due to the nature of the area it is addressing: disaster recovery.  We are investing quite a bit of effort in this area, however, particularly for Exchange 2007.  Most of the top Exchange disaster recovery experts at Microsoft are involved in the design and development of this tool.  We think the expanded feature set will make this as useful as any of the other tools we have.  A couple of examples of new functionality are steps to reset the log generation number, and a set of database repair steps that includes running defrag and isinteg to get the database consistent again.  We are also branching out some functionality from this area to do more symptom based analysis, such as identifying root causes of store mounting problems.  We are particularly eager to hear from anyone who has experience using this tool and are looking for feedback - both positive and negative - on its effectiveness and what we can do to make it even more useful.  If you have such feedback to give, please post a reply to this entry or to our newsgroup at 


ExPTA development continues apace as well.  We are adding more and more sophistication in this area, and this will continue for both the Exchange 2003 scenarios and the new Exchange 2007 scenarios.


There are no major new features coming up in the next release of ExBPA; just more rules, but the next release is going to be fully localized, (for ExBPA only - the other tools will be localized when Exchange 2007 releases).  Another thing that is going to be new when Exchange 2007 Beta 2 hits the streets is a new 'Exchange 2007 Readiness Check' scan type. You can run this against your existing Exchange 2000/2003 deployment to find out if there are any changes or decisions that need to be made before Exchange 2007 is introduced. This will allow you to plan for, and implement changes well-ahead of time, giving you a gentle glide-path to deploying Exchange 2007


All of the new functionality discussed here is expected to be released this summer.  It should also be a part of the toolbox in Exchange 2007 and available directly from the Exchange Management Console.  As I hope is apparent, we are devoting quite a large number of resources into the area of operational support tools here in Exchange, and we hope everyone who uses Exchange is happy with the progress we've made over the past couple of years, and we look forward to continuing this effort.  We've gotten a lot of positive feedback on these tools, and that makes it all worthwhile.  Thanks for the support.

Thursday, May 25, 2006

New Blog test Post

This is a post from the new Word 2007 Beta 2

Friday, April 07, 2006

Exchange Performance Troubleshooting Analyzer (ExPTA) 1.1 has shipped

This release of ExPTA includes the following:


1.    Perfmon data collection:  Collect performance data to log file or analyze previously collected logs.  ExPTA can collect for durations between 5 minutes to 8 hours. Collection works remotely. Data is analyzed in 20 minute time ranges, and results are grouped by the time in which the problem occurred.  You can analyze logs previously collected by ExPTA or via perfmon.  ExPTA will expect that the performance counters listed below are included in any log that is analyzed.


2.    Queue thresholds: SMTP Server\Categorizer Queue Length, Epoxy(IMAP)\Queue length, EPOXY(POP3)\Queue length, LDAP times, MSExchangeIS Public\Replication Receive Queue Size, SMTP Server\Remote Queue Length, SMTP Server\Remote Retry Queue Length, SMTP Server\Local Queue Length, Virus scan queue length


3.    Network thresholds:  Network Interface\Packet Outbound errors, Network Interface\Output Queue Length, Network Interface\Bytes Total/sec


4.    LDAP latency checks:  MSExchangeDSAccess Domain Controllers\LDAP Search Time and MSExchangeDSAccess Domain Controllers\LDAP Read Time thresholds were added to detect problems due to bottlenecks on the AD server.


5.    RPC requests: Max RPC requests, average RPC request thresholds are now dependent on the number of users per server


6.    Memory changes: Validate that the Database Cache Size Peak < 1.2 GB.  In addition, most of the memory rules have been changed to work off the maximum rather than the average values.


7.    Improved reporting: Reporting of results between steps and the summary are now displayed in a consistent fashion, using tabbed pages for the different reports.


Pick up the latest version from here.


Performance counters analyzed by this version of ExPTA:


\Database(Information Store)\Database Cache Size

\Database(Information Store)\Database Page Fault Stalls/sec

\Database(Information Store)\Log Record Stalls/sec

\Database(Information Store)\Log Threads Waiting

\LogicalDisk(*)\Avg. Disk Queue Length

\LogicalDisk(*)\Avg. Disk sec/Read

\LogicalDisk(*)\Avg. Disk sec/Write

\LogicalDisk(*)\Disk Reads/sec

\LogicalDisk(*)\Disk Writes/sec

\Memory()\Available Mbytes

\Memory()\Free System Page Table Entries


\Memory()\Pool Nonpaged Bytes

\Memory()\Pool Paged Bytes

\MSExchangeIS Mailbox(_Total)\Active Client Logons

\MSExchangeIS Public(_Total)\Active Client Logons

\MSExchangeIS()\Active User Count

\MSExchangeIS()\Exchmem: Number of Additional Heaps

\MSExchangeIS()\Exchmem: Number of heaps with memory errors

\MSExchangeIS()\Exchmem: Number of memory errors

\MSExchangeIS()\RPC Averaged Latency

\MSExchangeIS()\RPC Operations/sec

\MSExchangeIS()\RPC Requests

\MSExchangeIS()\VM Largest Block Size

\MSExchangeIS()\VM Total 16MB Free Blocks

\MSExchangeIS()\VM Total Free Blocks

\MSExchangeIS()\VM Total Large Free Block Bytes

\Paging File(_Total)\% Usage

\Process(*)\% Processor Time

\Process(emsmta)\Private Bytes

\Process(inetinfo)\Private Bytes

\Process(lsass)\Private Bytes

\Process(mad)\Private Bytes

\Process(store)\Private Bytes

\Process(System)\Private Bytes

\Processor(_Total)\% Processor Time

\System()\Context Switches/sec

\System()\Processor Queue Length

\Epoxy(IMAP)\Client Out Queue Length

\Epoxy(IMAP)\Store Out Queue Length

\Epoxy(POP3)\Client Out Queue Length

\Epoxy(POP3)\Store Out Queue Length

\MSExchangeIS Public(_Total)\Replication Receive Queue Size

\SMTP Server(_Total)\Categorizer Queue Length

\SMTP Server(_Total)\Remote Queue Length

\SMTP Server(_Total)\Remote Retry Queue Length

\SMTP Server(_Total)\Local Queue Length

\MSExchangeIS()\Virus Scan Queue Length

\MSExchangeDSAccess Domain Controllers(*)\LDAP Search Time

\MSExchangeDSAccess Domain Controllers(*)\LDAP Read Time

\Network Interface(*)\Output Queue Length

\Network Interface(*)\Current Bandwidth

\Network Interface(*)\Packets Outbound Errors

\Network Interface(*)\Bytes Total/sec

\MSExchangeDSAccess Domain Controllers(*)\LDAP Read calls/Sec

\MSExchangeDSAccess Domain Controllers(*)\LDAP Search calls/Sec

\MSExchangeDSAccess Caches(*)\Cache Hits/Sec

\MSExchangeDSAccess Caches(*)\LDAP Searches/Sec

\MSExchangeIS()\Virus Scan Files Scanned/Sec

\MSExchangeIS()\Virus Scan Files Quarantined/Sec

\MSExchangeIS()\Virus Scan Messages Processed/sec


Hope you like it! Let us know if you have feedback on the tool!


- Nicole Allen


Microsoft Exchange Server Profile Analyzer Web Release 2.5 Now Available



A while ago, I blogged about Exchange Server Profile Analyzer tool here. We now have some updates!

We are pleased to announce the availability of the Exchange Server Profile Analyzer WR2.5. The new version can be downloaded from the Microsoft Download Center.

List of enhancements included in EPA WR2.5:

- Dumpster collection - EPA now includes message content from mailbox "dumpster" folders when calculating message frequencies. Dumpster folders contain deleted content which has not yet been purged out of the database. The frequency data is reported with and without the additional dumpster content analysis in the output report.

- Message permanently deleted frequency - Because of the our new ability to analyze content in dumpster folders, EPA will now report how often messages are deleted permanently.

- Overall mailbox size reported regardless of time restriction - The calculation of overall mailbox size, rules and folder related statistics is not restricted by timeframe anymore. The timeframe restriction will only be applied to statistics related to individual messages, such as message frequency, attachment, recipient, etc. This change should result in faster EPA analysis runs and also removes the need to potentially run EPA twice against the same environment to gather statistics.

- Timestamp in the log - EPA now shows a time stamp for each entry in the log and console output. This allows tracking of how much time is spent on collecting data from individual mailboxes.

- Immediate data report before Ctrl-C - EPA will save whatever data it collects at the time a scan is cancelled with Ctrl-C to exit from the program for any reason. This feature allows you to still take advantage of any statistics that EPA has collected up to that point.

Feedback is appreciated!!

- Jessie Zhu


Wednesday, April 05, 2006

ExBPA 2.6 released - many great changes!


We wanted to announce the new major build of ExBPA that we released today: v2.6 (U.S. English).


We did a lot of work to improve usability of the tool in this release. Here are the major differences and improvements that we have made since ExBPA v2.5:


1. Tabbed reporting interface instead of a drop-down control. Viewing reports is now much more intuitive with this cool reporting structure.


2. Scan types are presented through radio buttons, so the different scan types available are much more obvious.


3. Group by "Issue" option when viewing list reports. For example, if you find that multiple servers are showing the same Error, you can now easily display a list of all servers affected rather than having to manually go through the entire list of items.


4. An ExBPA shell extension which allows you to right-click on an XML in Explorer (or apps like WinZip) and "View with Exchange Server Best Practices Analyzer".


5. ExBPA now works through proxy servers that require authentication.


6. New 'Permission Structure Check' scan type. This iterates through both the domain naming context and Exchange section of the configuration naming context and will notify you if inheritance has been blocked at any level. In addition, ExBPA will also check for inheritance blocks in the configuration naming context during a regular 'Health Check'.


7. Better reporting of cluster resources and groups. In the detailed view, you will now see a great hierarchical display of:


           - Cluster resource groups with current owner

                   - Cluster resources and properties

                             - Dependent resources

                             - Antecedent resources

                             - Possible owners


We have also implemented dependency checks. For example, if the System Attendant is not dependent on every physical disk resource in the same resource group, a warning will be displayed.


8. Very latest rule set, including all the updates made to v2.5, which include the IIS metabase / transport event sink checks. In addition, we have introduced some new rules including:

- If you look in the "Information Items" report, the very first info rule details the version of ExBPA that was used to capture and analyze the data.


- A new object processor that uses DsGetSiteName to ascertain the AD site membership of the Exchange server and all DC/GCs in the DSAccess topology.


- Certificate checking. For every SMTP domain defined, we attempt to obtain the SSL cert. If we find it, we'll check that the principal matches the host name and if the cert is close to expiry (or has already expired).


- For connectivity errors, ExBPA now displays the underlying exception (e.g. Access Denied) in the Error rule itself. You no longer need to manually go through the Run Time log to see the actual error string.


9. All XML files are digitally signed to improve security and prevent tampering/spoofing. On startup, ExBPA will check that a valid signature (and Microsoft certificate) is on each XML. If the XML has been modified, a popup error will be seen and ExBPA will refuse to run.


As usual, to get ExBPA, please go here or just go to! The direct download is here.


- Paul Bowden


U.S. Census Bureau buys 500,000 Windows Mobile Devices



Microsoft Wins Biggest Phone-Software Order, Rivals BlackBerry

April 4 (Bloomberg) -- Microsoft Corp. won its biggest-ever contract for mobile-phone software, an order from the U.S. Census Bureau that covers 500,000 handsets.

Microsoft, the world's biggest software maker, plans to unveil the deal today, general manager Scott Horn said in an interview. Redmond, Washington-based Microsoft expects to increase its mobile unit's sales to $1 billion in one to three years, from $337 million last year, and break the dominance of Research In Motion Ltd.'s BlackBerry.

``Up until now, BlackBerry had the market for themselves,'' Peter Knook, a Microsoft senior vice president, said in an interview. ``That landscape has changed.''

Sales of handsets with Windows will double to 20 million units in 2007 as corporate customers opt for those devices instead of the BlackBerry, Knook said. They still would be just a fraction of Microsoft's almost $40 billion in annual sales.

The company declined to disclose the value of the Census Bureau contract for Windows Mobile phones, which can link to the Internet, run Office, read e-mail and play music. Census takers will use them in collecting information door-to-door during the 2010 U.S. census.

Microsoft already won contracts to supply software for Palm Inc.'s Treo and Motorola Inc.'s new Q, after five years of delays and problems with its product.

Playing Catch-Up

It's still an uphill challenge for Microsoft. Researcher IDC expects shipments of Windows-based phones to double in each of the next two years. Even then, the software will account for only 13 percent of the total market, which includes business and consumer users, Framingham, Massachusetts-based IDC said.

``They're nowhere right now,'' said analyst Kevin Burden at IDC. ``RIM is still the mobile enterprise solution that all others should be measured against.''

Research In Motion spokeswoman Marisa Conway declined to comment. The Census Bureau phones will be built by Taiwan's High Tech Computer Corp.

The first sign that Microsoft was cracking the market came in September, when Palm said its new Treo would use Windows, after three years of clandestine meetings. During the project code-named Hendrix, staff referred to Microsoft as Woodstock and Palm as Purple Haze to keep it secret, Knook said. The companies had been rivals, and they didn't want workers to find out too soon.

Close Call

The secret almost came out in March 2004 in a private dining room at Arnaud's Creole restaurant during the CTIA trade show in New Orleans. In the next room, a Microsoft salesman met with phone retailers the companies didn't want to know about the pact, Knook said.

As six executives from Microsoft and Palm sat in the bar pretending not to recognize each other, restaurant workers ran upstairs to shut windows and doors connecting the rooms. Over a platter of oysters, executives hashed out sales, marketing and pricing strategy for the device.

The result: Microsoft won a spot in a device that sapped the strength of BlackBerry. Palm's Treo gained 564,000 users last quarter, almost as many as BlackBerry. Palm doesn't break out how many Treos have Windows. Research In Motion forecast BlackBerry user growth of 620,000 to 630,000 last quarter.

Being in the Treo is ``critical for Microsoft,'' said Page Murray, Palm's vice president of marketing. ``Nobody came out with a terribly viable Windows Mobile device prior to this. There was plenty of hardware out there, but nothing that captured the hearts and minds of people.''

Microsoft shares rose 35 cents to $27.56 yesterday in Nasdaq Stock Market composite trading. They've risen 9.1 percent since the Palm deal was announced.

Motorola Inc., the world's No. 2 mobile-phone maker, was the first company to put the software in phones in the U.S., in 2003. In the next several weeks, Schaumburg, Illinois-based Motorola will begin selling its BlackBerry rival, the Q, with a full keyboard and fast Web access.

Getting it Right

``We had a good understanding that sooner or later Microsoft would get it right,'' said Scott Durchslag, general manager in Motorola's mobile-devices division. ``We thought we could help make it sooner. It was a bet that paid off.''

Some analysts are optimistic. Delivering e-mail to Windows phones will cost less and the devices offer a wider array of features, Forrester Research Inc. analyst Ellen Daley said.

Windows runs 5 percent of high-end devices, which cost $300 or more, at large businesses in North America, she estimated. By 2010, Microsoft may have 60 percent, taking customers from BlackBerry, which now has 80 percent, according to her estimates.

Out of Parking

Knook added 150 people to his staff of more than 2,000 this year. Parking hasn't been able to keep up. With almost two cars for every space, one of his four buildings moved to valet parking.

He wants to enter the consumer market, where he also will fight top handset maker Nokia Oyj, which focused on software for consumer phones and is now also targeting BlackBerry. Espoo, Finland-based Nokia in February bought e-mail software maker Intellisync Corp. and formed a joint venture with Sanyo Electric Co. to improve sales of high-end phones in the U.S.

Knook's group is spending $25 million through June 30 on its first advertising campaign targeted at users. Since February, banners in airports and bus stops in cities from New York to Los Angeles to Paris ask travelers whether that's ``Microsoft Office in your pocket.''

``You may have the best technology, but if you've never told anybody you don't get any credit for it,'' Knook said. ``That's not something you fix overnight.''



Tuesday, April 04, 2006

Direct Push is just a heartbeat away

Another good explanation of Direct Push posted at EHLO… 



Exchange 2003 introduced the Always Up To Date notification feature (AUTD) that kept devices up to date by sending SMS triggers to the device. The triggers were sent from the enterprise as SMTP messages to the SMTP front end at the mobile operator. They were then sent through the SMS gateway as SMS messages to the device. This approach had some limitations since not all mobile operators did the SMTP to SMS conversion. Even when they did, there was latency involved with SMS messages and there were end-to-end reliability issues. Also some mobile operators charged for each incoming SMS message so that added an extra dimension to the cost of staying up to date. To alleviate these issues, Exchange 2003 SP2 introduced Direct Push.


Direct Push Architecture


Direct Push is a client initiated HTTP connection to the server where the device opens a connection to the Exchange Server and keeps it alive for a duration known as the heartbeat interval.  Basically the client sets up the connection, chooses the appropriate heartbeat interval and tears down and reestablishes the connection if and when necessary. The server sends notifications about new items over this connection and the client synchronizes to get the new items.


A new AirSync command called PING has been introduced for Direct Push. This command is sent as part of the POST request from the device.

Summary of Interaction between the client, EAS server and Exchange

1. Device issues a PING command.

2. When the EAS server receives a PING command it does the following:

·         If the Ping command contains the heartbeat interval or folder list, it stores the information in AUTDSTATE.XML in the user's mailbox. The device does not need to send these parameters up again unless they change.

·         If the Ping command did not contain the heartbeat or folder list, it retrieves them from the mailbox server.

·         EAS subscribes to notifications for the folders. It issues DAV subscriptions using the SUBSCRIBE command.

·         Since there is a small window between the last SYNC and the SUBSCRIBE where changes could have occurred, EAS checks for changes. If there is a change, the server immediately notifies the client to sync by issuing a response to the PING command with a Status of 2. It does an UNSUBSCRIBE to delete the DAV subscription. If no changes have occurred, the server continues to wait for UDP notifications from the mailbox server.

·         If a notification arrives within the heartbeat interval, the server will inform the client to sync. A response to the PING command is issued with a Status of 2 indicating that there are changes. Otherwise, after the heartbeat interval elapses, the server will return a response to the PING command with a Status of 1 indicating that there are no changes. It does an UNSUBSCRIBE to delete the DAV subscriptions before issuing the PING response.


Deployment Considerations for Direct Push


1. In order to use Direct Push, only the Exchange 2003 Front End servers need to be upgraded to SP2. However it is highly recommended that SP2 be installed on all Exchange Front End and back end servers. 


If the Front End servers are load balanced, all the Front End servers need to be upgraded around the same time.


2. When there is new mail, the BE sends a UDP notification to the FE.  Direct Push requires that UDP port 2883 be open from the BE to the FE. The port can be configured using the registry value UDPListenPort under HKLM\SYSTEM\CurrentControlSet\Services\MasSync\Parameters. If this value is set through the registry, the value must be greater than or equal to 1 and less than or equal to 65535. 


3. With Direct Push, the device keeps a connection open to the Exchange server. If you have a firewall between the device and the Exchange server, you must increase the idle connection timeout on the firewall. Please note that this is the idle connection timeout (i.e.) when there is no data transfer between client and server. For more information, please refer to KB titled "Enterprise firewall configuration for Exchange ActiveSync Direct Push Technology" available at


4. If you are using ISA 2000, you need to add a registry key on the ISA server to use direct push. Please refer to  the KB titled "The ISA Server response to client options requests is limited to a predefined" available at for information on how to add the registry key.


Heartbeat Interval


The device specifies the heartbeat interval as part of the PING command. This dictates how long the server must keep the connection alive. The device will dynamically converge to the highest possible heartbeat interval for a given network, based on the mobile operator timeouts, firewall timeouts etc. The higher the heartbeat interval, the better it is for battery life. So the heartbeat is optimized for a given network.


You can change the minimum and maximum heartbeat interval settings on the server through the registry.


The settings are MinHeartbeatInterval and MaxHeartbeatInterval under



The defaults are 1 and 45 minutes respectively. Note that the maximum is hard coded to 59 minutes since the maximum possible DAV subscription lifetime is 60 minutes.


You can also specify a heartbeat alert threshold. The server maintains a sliding window of the last 200 heartbeat intervals supplied by clients. If the average from this sample is less than or equal to the alert threshold, there will be a warning in the event log  


"The average of the most recent heartbeat intervals used by clients is less than or equal to x. Please check your firewall settings to ensure that they permit requests to Exchange ActiveSync to live for at least 15 minutes."


The alert threshold and sample size can be configured through the registry. The settings are HBiSampleSize and HbiAlertThreshold under



Configuring Direct Push on the Server


By default, Direct Push is enabled in Exchange 2003 SP2. However you can enable/disable it in Exchange System Manager. In ESM expand Global Settings, right-click on Mobile Services, Properties and check/uncheck the box for "Enable Direct Push over HTTP(S)"



You can also change this setting on a per-user basis using Active Directory Users and Computers.  In ADU&C, click on the user, Properties, Exchange Features tab, under Mobile Services enable/disable Up-to-Date Notifications. This controls both SMS based AUTD and Direct Push for the user.


Configuring Direct Push on the client


A Direct Push capable device will automatically negotiate the protocol with the server and configure itself to use Direct Push. The sync schedule is set to "As new items arrive".


Direct Push Initialization


1. Verify that Exchange ActiveSync is loaded and IP-based AUTD is initialized by checking the application log on the FE for events below. Exchange Activesync gets initialized on the first sync attempt.


Event Type: Information

Event Source:     Server ActiveSync

Event Category:   None

Event ID:   3002

Date:       3/19/2006

Time:       12:44:08 PM

User:       N/A

Computer:   1B25A


Microsoft Exchange ActiveSync has been loaded: Process ID: [3048].


Event Type: Information

Event Source:     Server ActiveSync

Event Category:   None

Event ID:   3025

Date:       3/19/2006

Time:       12:44:19 PM

User:       N/A

Computer:   1B25A


IP-based AUTD has been initialized.


2. Verify that the FE is listening on port 2883.


To check if the server is listening on the AUTD port, you can run "netstat -ano". Here are results before and after IP-based AUTD has initialized.




Proto       Local Address     Foreign Address   State       PID


UDP      *:*                           1928

UDP      *:*                           3356




Proto       Local Address     Foreign Address   State       PID


UDP      *:*                           1928

UDP      *:*                           3048

UDP      *:*                           3356


Netstat provides the Process ID which matches the EAS process per the initialization event in the application log.


Another way to check if the server is listening on the AUTD port is to use PortQry(available on This lists the process that is listening on the port


Process ID: 3048 (w3wp.exe)


PID   Port        Local IP          State             Remote IP:Port

3048  TCP 31479      ESTABLISHED

3048  TCP 31480      ESTABLISHED

3048  UDP 2883                             *:*


Troubleshooting using logs


1. Enable device side logging. The logs are saved in text format in the Windows\ActiveSync folder. PING commands will be logged in "Ping Exchange Server x.txt" where x =1,2,3.  You should see commands similar to the one below.


POST Microsoft-Server-ActiveSync?User=administrator&DeviceId=6F24CAD599A5BF1A690246B8C68FAE8D&DeviceType=PocketPC&Cmd=Ping

MS-ASProtocolVersion: 2.5


The POST command is also logged in the IIS log on the FE.


The Ctrl log on the device can also be used to troubleshoot Direct Push although the format of this file may change with device updates.


2. Check the IIS logs on the BE to see if AUTDState.XML is being created or updated. You should see an entry something similar to the one below.


PUT /exchange/Administrator@1b1domain.lab/NON_IPM_SUBTREE/Microsoft-Server-ActiveSync/PocketPC/6F24CAD599A5BF1A690246B8C68FAE8D/AutdState.xml


Note: The AUTDState.XML is created on receipt of the 1st PING request and is updated only when the heartbeat or folder list changes. So you may not see this command for every Ping request.


AUTD state information is maintained on the mailbox server in the NON_IPM_SUBTREE of each user's mailbox. 


In IE, you can Choose File, Open, check the box to "Open as Web Folder" and type in



Sample AUTDState.XML


<?xml version="1.0" encoding="utf-8"?>

-<AutdState xmlns="Ping:">








  - <Folder>








3.  Check the IIS logs on the BE to see if SUBSCRIBE commands are being issued from the FE to the BE(ie) if DAV subscriptions are being created.


For example, you should see something similar to


SUBSCRIBE /exchange/Administrator@1b1domain.lab/Inbox/


4. You can run a netmon on the FE to see if UDP notifications are being sent over port 2883 from BE to FE.


551 16.781250 LOCAL 000E0C06CAC0 UDP Src Port: Unknown (33660); Dst Port: Unknown (2883); Length = 162 (0xA2) BE FE IP


UDP: Src Port: Unknown (33660); Dst Port: Unknown (2883); Length = 162 (0xA2)

    UDP: Source Port = 0x837C

    UDP: Destination Port = 0x0B43

    UDP: Total length = 162 (0xA2)

    UDP: UDP Checksum = 0xC233

    UDP: Data: Number of data bytes remaining = 154 (0x009A)

00000:  00 0E 0C 06 CA C0 00 D0 B7 24 86 2B 08 00 45 00   ....ÊÀ.÷$†+..E.

00010:  00 B6 C8 73 00 00 80 11 07 3A AC 1D 09 71 AC 1D   .¶Ès..€..:¬..q¬.

00020:  08 DE 83 7C 0B 43 00 A2 C2 33 4E 4F 54 49 46 59   .Þƒ|.C.¢Â3NOTIFY

00030:  20 68 74 74 70 75 3A 2F 2F 31 62 32 35 61 2E 31    httpu://1b25a.1

00040:  62 31 64 6F 6D 61 69 6E 2E 6C 61 62 3A 32 38 38   b1domain.lab:288

00050:  33 2F 33 35 33 39 35 63 65 34 2D 31 35 30 34 2D   3/35395ce4-1504-

00060:  34 61 63 34 2D 39 37 32 31 2D 66 31 35 32 63 36   4ac4-9721-f152c6

00070:  34 36 65 61 33 35 20 48 54 54 50 2F 31 2E 31 0D   46ea35 HTTP/1.1.

00080:  0A 53 75 62 73 63 72 69 62 65 2D 67 72 6F 75 70   .Subscribe-group

00090:  3A 20 55 73 50 43 57 77 46 4C 32 30 71 37 44 2B   : UsPCWwFL20q7D+

000A0:  6E 61 76 6F 4D 71 79 41 3D 3D 0D 0A 53 75 62 73   navoMqyA==..Subs

000B0:  63 72 69 70 74 69 6F 6E 2D 69 64 3A 20 32 37 0D   cription-id: 27.

000C0:  0A 0D 0A 00        


Frequently Asked Questions and Answers


1.    Does Direct Push work for folders other than inbox?


Yes, Direct Push is available for mail folders, Contacts, Calendar and Tasks. The list of folders for Direct Push is the same as the list of folders that have been configured for sync.


2.    What devices support Direct Push?


Windows Mobile 5 devices require the Messaging and Security Feature Pack(MSFP) for Direct Push. MSFP is included with AKU2.2. So any Windows Mobile 5 device that has AKU2.2 supports Direct Push.  The AirSync protocol has been licensed to several companies such as Palm, Motorola, Nokia, Symbian, Dataviz and SonyEricsson. Please contact the licensees to see if Direct Push capable devices are available.


3.    Is Direct Push supported over Wi-Fi?


No. Direct Push requires a cellular data connection. It is not supported over Wi-Fi or Desktop Passthrough(when the device is cradled).


Due to hardware limitations, Wi-Fi cannot go into standby mode and receive notifications. So in order to support Direct Push over Wi-Fi, the Wi-Fi connection would have to be kept alive which in turn would drain the battery very rapidly.


4.    Does Direct Push work with SecurID?


RSA has an update to their agent to allow it to work with Direct Push. RSA Authentication Agent 5.3 for Web for IIS enables you to use Exchange ActiveSync without having to reauthenticate every time ActiveSync is invoked. For more details, please read this and contact RSA.


5.    Does Direct Push have an impact on server performance?


A typical FE services several thousand connections from clients using OWA, OMA, EAS, and RPC/HTTP clients. Based on the testing done by Microsoft IT, the additional connections opened by Direct Push did not require the deployment of any additional FE or BE servers. It also did not require an upgrade of hardware on existing servers.


For more information please refer to the whitepaper titled "Microsoft IT Scalability Experience with Windows Mobile 2003 and Exchange Server 2003 Mobile Messaging" available at


- Vanitha Prabhakaran