Tag Archives: Unified Messaging

A colleague who earned his Exchange 2010 last year recently contacted me with a bit of an odd UM question. Here’s the basic scenario: Steve Secretary answers the phone for Betty Bosswoman. This was set up in Cisco Call Manager such that Steve’s phone has two extensions: 1000 (Betty’s extension) and 1001 (Steve’s extension). When someone calls Betty, both phones ring, and Steve can answer it as necessary. Sometimes Steve would answer the phone and the caller would ask for Betty’s voicemail; Steve could oblige by doing a blind transfer to Betty’s extension and the call would be routed to the voicemail system.

Things were all fine with this configuration until the advent of Exchange UM. Call answering and delivery worked fine until Steve tried to transfer a call to Betty’s voicemail, now hosted on Exchange UM. The caller whose call was transferred was getting Steve’s voicemail.. not at all the right result.

This was happening because when the call was transferred, CUCM was emitting a diversion header that indicated that the call was being sent to Steve. Why? Because Steve had Betty’s extension assigned as a secondary extension! Remember, Exchange UM uses the SIP diversion information to determine where the call’s from, who it’s to, and why Exchange is getting it. If any of these three data are incorrect or missing, Exchange will fall back to assuming that the call is to the voicemail pilot number, and you’ll hear “Welcome to Microsoft Exchange. Please enter your mailbox extension” (or whatever; the exact phrase escapes me) instead of the correct greeting.

My interlocutor wanted to know if there was a way to change this behavior on the Exchange side. Sadly there isn’t– whatever diversion header information is provided, Exchange will consume. There’s no way to rewrite, edit, or otherwise control the diversion data on the Exchange side, nor can you create rules or filters that modify the actions that Exchange takes. That’s what the call coverage map on the PBX is for, see?

Anyway, after a little head scratching, some consultation with a CUCM engineer, and the sacrifice of a chicken, it was discovered that CUCM had a way to modify the extension information sent as part of a blind transfer. The change was made so that transferring a call from Steve’s phone emitted Betty’s extension instead, and the problem was solved. Unfortunately I don’t know exactly what change was made, or I’d document it here. Such are the perils of not being a CUCM guy…

Exchange 2010 offers protected voice mail that works roughly like the “mark as private” option that many legacy voicemail systems provide. The difference is that Exchange 2010 uses Active Directory Rights Management Service (AD RMS) to apply restrictions to the message that prevent clients from forwarding it. This gives the same protection as legacy VM systems, which implemented message privacy by keeping VM recipients from forwarding messages.

This is a nifty idea, given that it ties together Exchange UM with AD RMS in a logical way. It has some implications, though, that may not be obvious at first glance.

First, of course, is that you have to use a compatible client to play the voice message. A client that doesn’t support AD RMS won’t even see that the message has an audio attachment. It just shows up as the familiar “this message is protected with…” text. In this context, “compatible” means Outlook 2007, Outlook 2010, or OWA 2010. There’s no Mac client (yet; the forthcoming version of Outlook for Mac is alleged to support AD RMS messages), nor are there mobile clients.

Second, when you play the message, the way you play it may vary according to the policies in effect on your system. The UM mailbox policy defines a setting named “Allow multimedia playback of protected voice messages“. When this setting is false (e.g. when it does not allow multimedia playback), users can only play protected voice mail messages through the Exchange Play on Phone mechanism or through Outlook Voice Access (e.g. over the phone), not through the inline media players in Outlook and OWA. This is useful in some contexts to prevent users from playing sensitive messages on their laptop speakers at the coffee shop, at high volume in a cubicle farm, and so on.

Unfortunately, the documentation says this setting is set to false by default… in other words, the default settings (according to the docs) only let you play protected VMs on the phone. In reality, the settings is true by default, so that users can play protected messages back on the phone or through the local media player. In other words, the docs are 100% wrong. I blame this on the fact that the attribute name in the UM mailbox policy is RequireProtectedPlayOnPhone– the opposite wording. If “require X” is false, that’s the same as “allow not-X” being true. So, this is now bugged with the Exchange UE team.

In playing with this feature, I also wasn’t able to make Exchange protected voice mail messages show up consistently in Communicator’s VM notification system. I think that’s because my test machine was using Outlook 2007, in cached mode; the protected VMs didn’t show up in its “Voice Mail” search folder either. I’ll have to test this some more with an Outlook 2010 machine to see what happens, but my expectation is that Communicator should show protected VMs just like it does normal ones.

You may have heard that Exchange 2010 won’t support inbound fax. I have yet to find an Exchange 2007 deployment that actually uses Exchange UM faxing for one simple reason: it’s inbound-only. If you have to do all the work of deploying an outbound fax solution anyway, the value of inbound fax support in Exchange UM is quite a bit lower.

Exchange 2010 won’t create fax messages itself. However, there’s a twist: you can outsource your fax over IP (FoIP) capabilities. Exchange 2010 will honor any existing Exchange 2007 UM fax configuration properties, and it will continue to recognize fax CNG tones. However, instead of answering the call itself, UM will look at a new configuration property defined on UM mailbox policy objects: FaxServerURI. If this property exists, UM  will try to hand off the call to the specified fax solution. The external fax solution will establish a fax media session with the sender, create a fax message, and send it to the UM-enabled user’s mailbox.

Messages created by this approach will look basically just like Exchange 2007 UM fax messages, and they’ll appear in the Fax search folder just as existing messages do.

The foregoing discussion might lead you to wonder who’s going to offer FoIP services that work with Exchange 2010. I haven’t seen a list yet. However, Concord Technologies sent out a press release at the Worldwide Partner Conference touting the fact that they’d be offering an Exchange 2010-compatible solution, so I guess we can count them in.