Discontinuation of support for Session Border Controllers in Exchange Online Unified Messaging

Microsoft

In July 2018, we will no longer support the use of Session Border Controllers (SBC) to connect 3rd Party PBX systems to Exchange Online Unified Messaging (UM).  We're making this change to provide a higher quality of service for voicemail, using Exchange standard and Skype for Business protocols. Customers considering a new deployment of this scenario should be aware that they will have a little less than a year to complete one of the migrations below.  Customers with existing deployments remain fully supported until July 2018, including moving voicemail-enabled mailboxes from Exchange on-premises and voicemail-enabling new mailboxes.

 

The following configurations are not affected by this change:

  • Skype for Business Server (on-premises) connected to Exchange Online UM
  • 3rd party voicemail solutions that deposit voicemail messages into Exchange Online mailboxes through APIs, rather than an SBC connection
  • All forms of Exchange Server UM (on-premises)

 

There are several alternative solutions for impacted customers, one or more of which must be implemented prior to July 2018.

 

  • Option #1: Complete migration from 3rd party on-premises PBX to Office 365 Cloud PBX. 
  • Option #2: Complete migration from 3rd party on-premises PBX to Skype for Business Server Enterprise Voice on-premises.
  • Option #3: For customers with a mixed deployment of 3rd party PBX and Skype for Business, connect the PBX to Skype for Business Server using a connector from a Microsoft partner, and continue using Exchange Online UM through that connector. For example, TE-SYSTEMS anynode UM connector can be used for that purpose.
  • Option #4: For customers with no Skype for Business Server deployment or for whom the solutions above are not appropriate, implement a 3rd party voicemail system.

 

Although only a small number of customers are affected by this change, we know that planning for changes to voice platforms requires time to evaluate options, and to implement the selected option.   We encourage you to start this process soon.  For more information, please visit the following pages:

 

Exchange Online Unified Messaging

Exchange Online UM support for 3rd party PBX via SBC

Cloud PBX

Skype for Business Server Enterprise Voice

 

Note: this post is also on the Exchange Team (EHLO) blog.

62 Replies
We have a hybrid cisco/Lync/SfB environment with Hybrid Exchange and we have managed to retarget the Cisco UM through the Lync/SfB infrastructure to Exchange UM online using Sip Dial Plans with managed sip code on the FE's. Cisco environment dials an allocated pilot number which is a simple ExUMContact entry.

Are you willing to share the managed code?

The version i have at the moment is customer specific, i'll generalise it and then publish it. 

 

Effectively what i am doing is taking the diversion header where the to header contains the pilot number, I then take the diversion number and look up the number in a generic list held in memory for the users sip address associated with UM, I then remove the to and diversion headers.  I then re-create the to header as <sip:user@domain.com;opaque=app;voicemail;local-resource-path=voicemail>, then recreate the diversion header as <sip:user@domain.com>;reason=unknown I then retarget the request to sip:user@domain.com;opaque=app;voicemail;local-resource-path=voicemail, this method doesn't matter whether is user has EV or AV but it is dependant on the user being Lync/SfB enabled and having the hostedvoicemail policy for o365.

 

The server application has to be put in above the ExUmRouting service for two reasons,

1 ExUMRouting strips the diversion header

2 ExUMRouteing redirects the voicemail to the relevant service.

 

 

I've found about 3 different ways to bounce it through so far, was only given the task last Friday.

This highly impacts on organizations which are using third party enterprise telecomm systems. For those organizations, they've already invested on third party PBXs and SBCs and they are not as fast as to switch Skyype's enterprise voice for Exchhange online UM within a year. If they go with third party solutions like anynode, they will lose Exchange online UM features that areincluded in the Office 365 licnese bundle. MS should reconsider to support third party SBCs and/or postpone the discotinuation date to next couple of years.

This still requires Skype for Busioness enterprise voice license and technically it is doable but it doesn't make sense in terms of cost-effective.

We're very disappointed in Microsoft with this move.  I think if there were some reasonable options moving forward, we could chalk it up to technical innovation.  Unfortunately, every single option for the 'small number of customers impacted' is expensive, time intensive and worst of all has little to no strategic advantage for the customer other than putting more $$$ in MS pockets.  The time frame also is unreasonably short.  We are very disappointed in the lack of options at this point.

I saw a technet post done on 2/28/2018 that said the same thing as what this vendor says but the Technet article has been removed recently, but it also stated that AnyNode from TE-SOLUTIONS is no longer recommended. Is this still true and why?

https://blogs.perficient.com/microsoft/2018/02/discontinuation-of-support-for-sbc-in-exo-unified-mes...

 

Screenshot of of original Technet article attached to this post..

 

The message was retracted, and the original recommendations stand.  However, even though this was retracted, be advised that ultimately Exchange Unified Messaging is a dead product based upon very old technologies and will very likely never see new development or updates.  It's not a direction you'd want to head unless you have no other option.  I suppose there's a chance that the vendor products that connect with it will be able to leverage Azure VM in future versions, but that's pure speculation on my part at this point.

anynode is already able to use Azure VM and Exchange UM. That was the initial approach to use Skype for Business instead of a direct connection in the cloud. Maintain 2 solutions for the same feature does not make any sense. 

Depending on the user´s home anynode (the call) will end up in Exchange UM or Azure Voicemail. 

We expect more changes in the backend to get a 100% feature parity. 

 

Oliver

 

any third party recommendation from microsoft. we are looking into the options of AVST and Avaya

Thanks Anthony.  From what I can tell, Azure VM requires Phone System PBX licensing.  It doesn't make sense to license Phone System while simultaneously attaching your users to an external PBX (essentially double-paying), except perhaps in a migration scenario.


I think customers who leverage Exchange UM with a 3rd party PBX are still looking for solution to go to the cloud.  I was disappointed to confirm that X-UM requires Enterprise Voice CALs, and am currently trying to find out whether anynode has the same requirement.

 

Anynode will have the same requirement I suspect, it's just the way it's designed to communicate.  It's basically an trusted application bolt-on to Skype that delivers direct to voicemail from what I understand.

Yep, that is the case. We are now looking at AVST as there is no cost effective alternative solution that avoids the extra licensing.

I like AVST, I've used them on deployments even in the Lync days when the corporation wasn't fully on Exchange. 

Check out my article explaining your voicemail options for Exchange Server and Skype for Business on-premises, as well as Office 365.

http://www.expta.com/2018/07/say-bye-bye-to-exchange-unified.html

@Steve Conn Sorry to hear that you moved from Exchange Team Manager role.

 

I just spoke to Nathan Abennet and he explained that this is not an official place to accept the technology solutions. For the years, we learned from many Microsoft employees about their opinion and accepted as an official word but these are just their personal views which can't be taken as official Microsoft statement.

 

So, the final word from my call is, option 3 is not supported for Message Waiting Indicator and we have to develop EWS for this functionality.

:(