Exchange 2007 SP1 Unified Messaging (UM) is currently the only officially supported voicemail solution for Office Communications Server 2007 and 2007 R2. Exchange UM offers three different codecs to store voicemails. A description can be found here.

When a company has many mobile users accessing emails (incl. Exchange UM voicemails) using their mobile (cell) phones, it makes sense to think about which voicemail codec to use as data plans for mobile devices are sometimes based on data volume. Also international data roaming can become costly so that the company can potentially reduce costs using smaller voicemail messages.

The three different codecs are:

• Windows Media Audio (WMA)
• Group System Mobile (GSM) 6.10
• G.711 Pulse Code Modulation (PCM) Linear

Before changing the voicemail codecs, an administrator needs to make sure that most of the currently used mobile phone devices are actually able to play these voicemail messages with that particular codec. One way to ensure this would be to send three emails to the mobile device with sample files of voicemail messages using the three different codecs.

In order to make this simple for you, you can download here samples of the same voicemail message recorded using the three different codecs. (It’s German and my voice, so don’t think there is something wrong with the file :-) )

We are excited to unveil today a software product suite that will help global enterprises optimize their UC investments by monitoring and driving OCS usage, integrating with billing and chargeback information, and enabling comprehensive bandwidth planning across the enterprise. Our new Unify² PowerView offering comes as a result of direct customer input and discussions about the measurement and billing support they need to better understand and maximize their UC investments.

PowerView is a sophisticated product for global enterprises looking to better track and measure OCS deployments based on business division or geography. Of particular interest are integrated billing options that can track and charge-back costs across business units. 

Complimentary to PowerView is Unify² PowerPlan, which enables an enterprise to determine its expected OCS bandwidth consumption across its entire network infrastructure--based on enterprise-specific usage parameters--to “right-size” its network and facilitate a quality OCS end-user experience.

PowerView generates detailed reports on enterprise OCS adoption, identifying usage patterns and estimated cost savings achieved through the use of enterprise voice, video conferencing, instant messaging, and application sharing. Snapshot of customizable reports:  

1. OCS Usage Analysis: Tracks OCS usage across the enterprise over time, adoption of OCS workloads and features, customized around organization hierarchy, department, business divisions or geography.
2. OCS Operations Optimization: Tracks communications device and client usage, and provides inbound and outbound voice call trends by geography or organization, which is geared towards reducing infrastructure costs.
3. OCS Billing Integration: Provides two options for implementing departmental billing, with subscriber fixed-fee or usage-based billing models. Enterprises can calculate and share costs assigned to different business units, and optionally export the data to corporate finance applications.
4. OCS ROI Tracking: Tracks cost savings of deploying OCS for internal and PSTN dial-in conferences based on per-user per-minute savings.

Complimentary to PowerView is PowerPlan, which allows global OCS enterprises for the first time to develop a comprehensive bandwidth model for their actual OCS bandwidth consumption across all the network nodes and links of interest, including all branch offices in the enterprise.

PowerPlan lets enterprises simulate the impact of OCS workloads across a representation of their entire enterprise network, and thereby estimate the maximal bandwidth consumption on each link in actual operation. PowerPlan factors in current network consumption by other applications on the enterprise network, and can provide an integrated picture of network needs, both in the planning phase itself and on an ongoing basis as OCS usage and other network applications change over time.  By understanding actual usage, enterprises can refine bandwidth consumption models using PowerPlan.

Used together, PowerPlan and PowerView enable an enterprise to “right-size” its network for OCS on a continuous basis. Read more about PowerPlan and PowerView on our Product page. Let us know how you're managing your OCS usage today, what's working, what's not, and if you think PowerView and PowerPlan can help.

In the middle of a deployment - an OCS R1 to R2 migration - we noticed that the LM functions were not working.  LM worked for the individual workstations when connecting to a remote session initiated by a federated partner.  The meeting policy at the global level was created, edited, and assigned correctly.

We noticed that we had neglected to run the Web Conferencing validation tests.  We had a tick box on our checklist, we had just overlooked it.  Running the validation wizard revealed that the validation connection checks were failing to successfully contact the MCU on either of the Front End servers.  We double-checked everything, and concluded that everything on the OCS side was correct.

“Aha,” says we.  “Must be a certificate issue.”  Except that we were using good public certificates on all the interfaces for the FE servers.  Bummer.  Except, I then read this blog article.

Oddly, this was so on target it floored me.  I used the solution that changed the usage on the Trusted Root Certificate to “ALL” - voila!  problem resolved.  I don’t know who exactly wrote this, and what follows is a cut ‘n paste and edit of the relevant parts of that blog that fixed my issue. Many thanks to the unknown CSS engineer (Dave) who took the time to write this up.

Event Type:    Error
Event Source:    OCS MCU Infrastructure
Event ID:    61013
User:        N/A
Computer:    OCS1
Description:
The process DataMCUSvc(2596) failed to send health notifications to the MCU factory at https://OCS1.contoso.com:444/LiveServer/MCUFactory/.
Failure occurrences: 3491, since 3/24/2009 10:05:18 PM.

If you run the Web Conferencing validation wizard from the OCS Pool, you may find the following error in the output log:

MCU Type: meeting
URL: https://OCS1.contoso.com:444/LiveServer/MCUFactory/
HTTP Connectivity Error : ReceiveFailure
HTTP Connectivity Error : Receive failure typically indicates that the connection was closed by
the remote host. This can happen if the remote server does not trust the certificate presented by the
Local Server.

HTTP Connectivity Error : Ensure that the certificate of the local server and remote server are both
valid, have not expired, and contain valid subject name. In addition, ensure that the certificate chain
of both Server(s) are valid. Ensure that the certificate chain of the local server is installed
on the remote server and vice-versa. The most up-to date certificate chain that was used to issue
the server certificate must be present.

When you see errors like these, it usually indicates that a certificate-related authentication problem exists with the OCS Pool (or with a particular OCS Front End server).  Most of the time, this turns out to be a problem with the certificate from an issuing Certification Authority.  To troubleshoot this issue, you would typically perform the following steps:

1. Log in to the affected OCS 2007 Front End server either locally or remotely using Remote Desktops.
2. If the issuing CA is a Root CA (the top of the list), expand Trusted Root Certification Authorities > Certificates
1. If the issuing CA is an Intermediate CA (not the top of the list), expand Intermediate Certification Authorities > Certificates
2. From the list of CA certificates, right click on the certificate and choose Properties
3. Under the General tab, verify that Enable all purposes for this certificate is selected (or, if Enable only the following purposes is selected, verify that both Server Authentication and Client Authentication are enabled)
4. Click OK to close the properties of the CA certificate.
5. If this was an Intermediate CA certificate, repeat steps 6 through 10 until these settings from all certificates in the trusted certification chain are verified
6. Close the Certificates Management Console (be sure to restart services if you made any changes)

Why this occurred on a brand new R2 installation on server 2008 SP2 is beyond me.  The OCS R1 system (on Server 2003 SP2 R2) did not have this issue, but the brand new setup did.  Go figure.