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 microsoft.public.exchange.tools. 

 
 

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.