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


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

As one of the "small number of customers" affected by this, I am finding it hard to understand this decision and even harder to stomache the options.  Looks like it's either migrate everyone from 3rd party PBX to Skype for Business Online, migrate them to on-prem Skype for Business, set up some sort of hybrid Skype for Business connection, or stop using Exchange UM.  And do this all in 1 year.  Wow...

There's another option as well, which is: use an SBC that can deliver to Exchange UM Online without needing Microsoft's cloud based session border controllers.  I believe AnyNode has this capability.

Thanks for the reply.  My basic understanding of the traffic flow for a solution like AnyNode is...


3rd Party PBX --> AnyNode --> On-Prem Skype for Business --> O365 (Skype/Exchange Online)


This would mean I still need to have Skype for Business on-prem, right?  Or am I missing something?

To add on to that.  Is anynode doing something special any other SBC that connects between a PBX and Skype does? It just seems like it would be a normal scenario where if a user was homed on Skype on prem with a PBX in front of it that the skype client would leverage Exchange UM (on prem or online) to connect to voicemail. 



Does Option 3 require S4B Enterprise Voice to be active?  

We have S4B on-prem, but only use it for IM/Presence. We are also one of the minority (just about to implement SBC's to support our move to O365), and Options 1/2/&4 are all problematic. 

Whilst I understand there's little future in Exchange UM, I'm a little disappointed the onus is on the customer to solve this problem.

Far better would have been a solution from Microsoft to extend Azure voicemail to meet this requirement, or similar.

Whilst the number of customers that use this is low (I've done.. three) it's been talked about with more customers than it used to be, mainly because the complex Exchange Online projects are the norm now.

Replacing voicemail for a strategic PBX system with Exchange UM, and therefore Exchange Online UM has been part of some customers TCO, and those using this have in some cases invested large sums of money in SBCs to meet this need.

I have to agree with you, Steve Goodman.  This is very painful for a several of my customers.  The timeframe is too short to move gracefully to Skype for Business, and there's not proper budgeting to do much else.  

While this affects "only a small number of customers", those customers tend to be really, REALLY, big. We're talking some Fortune 100 companies here. Transitioning completely to SfB or SfBO in a year's time is no trivial task.


TE-SYSTEMS anynode is a SIP-to-SIP software SBC solution. Great if your PBX already does SIP, but a number of large customers have analog PBXs. Traditional SBCs can convert analog PSTN calls to SIP using a Voice Gateway feature, and then trunk it over to Skype for Business or SfBO.


Whatever direction you go, you will need to decide SOON, and start planning and executing immediately.

Thanks Jeff,


That's what I had understood too.  However would that still require the Skype account being ev enabled and then being able to have the call at the PBX being forked to both the deskphone and the skype account?  I've never seen an SBC that can just take the voicemail sip invite message and send it through to Exchange Online.  It's definately not the same as just sending a SIP invite to a pilot number, that's for sure :)

Hi Anthony--


Yes, that is Option #3 above.



Steve, perhaps you can expand on the requirements for option 3 and give a bit more detail on how that would work?

As a happy O365/Unified Messaging mixed environment customer I would like to express my displeasure with Microsoft's decision to end support for SBC's as of July 2018. I completely understand Microsoft's strategy in doing this but I believe setting a 1 year time frame will hurt Microsoft (and its customers). I would have liked to see a 3-5 year transition time. Here is why I say that. We're a college system with multiple campuses using an Avaya VoIP system. We've been using Microsoft UM as a voicemail solution for 4 years, first on-prem and now in the cloud. Our users love Microsoft UM and we have been beginning to deploy Skype for Business Cloud PBX to a few pilot users and so far we really like it to the extent we have begun to consider moving toward a Skype for Busienss Enterprise Voice solution in the future. But due to certain conditions, namely issues with our network infrastructure in some locations, our requirement for advanced Call Center and routing features, and certain cultural challenges within our various campus IT divisions it would be impossible for us to make the switch to Skype for Business within 1 year. So if Microsoft insists on this inadequate time constraint we may be forced to adopt a less than ideal temporary solution which could upset and/or complicate our plan to move toward Skype for Business. Microsoft's Discontinuation of Support notice states that only a small number of customers will be affected by this change but I'm sure the list of customers affected is actually quite substantial.

As I said before I completely understand Microsoft's strategy. They have a good product and deserve to unify their products but Skype for Business Cloud PBX is only beginning to gain enterprise grade features. And rumors of future branding changes are causing further anxiety for potential customers. Microsoft should extend the End of Support notice for SBC's to no sooner than 2020.



This is a pretty big deal for us as well.  We are a hybrid on premise Cisco Call Manager & Skype for Business on-prem w/ Enterprise voice.  We were going to migrate all of our voicemail to Exchange UM from Cisco but now this is a halt and we have to revert users we just moved recently.


I agree with everyone else that 1 year timeline is surprisingly low for an enterprise.   Our budget process has already occurred for next year, and now we'll have to insert a large add-on for voicemail.  MSFT should give at least 2-3 years notice.


I would also like to see a statement of committment to on-prem Exchange UM or if they'll be abandoning that as well in future versions. 



As a customer that uses this type of environment with an EA, I find this completely unacceptable.


  1. Tansitioning to Microsoft PBX is a significant capital expense and would take several years to implement.
  2. On-prem Skype for Business implementations are bloated and require way too much management overhead. I took out my Skype for Business server and went to strictly Skype online for this exact reason.
  3. Please see the above.
  4. A third party voicemail system is another significant capital expense.

Also, how does installing Skype for Business on-prem fit into "Cloud First"? You are requiring even MORE on-prem infrastructure by forcing this change, with little or no increase to your bottom line.


This will make me reconsider the services that I currently have included with my EA.





I didnt realize that Microsoft had become the biggest Ransomware threat on my network.  I'm sure we'll have to true up next year with a bitcoin account.  Thank you Microsoft for proving that you really do not care about your customer base or the large time and money investments they have made in order to make your product fit within their business. Not only is this going to cost us a large amount of money to transition to our 3rd party VM software, we only have 1 year to figure out how to make it happen.  In addition, all of the time and money we have spent on redundant session border controllers over the last couple of years are now going to become worthless. This is completely unacceptable.

I am all for change and advancement of technology, but question the short lead time and question the viable options.  1 year is not very long to change out voicemail for enterprise level organizations.  Especially when they're already in the middle of other projects and budget cycles.  


It will take some time to compare solutions, pilot, plan for change, communicate to users, document telephone admin operational changes, document end user changes, document user workflow changes, and then implement.  In order to meet this window, it will cost money.  And partners have to be ready to engage.  


It would have also been good to announce a solid transition plan.  When we last compared voicemail services in SfB Online, it was not close to UM's capabilities.  Hoping this has changed.  It would be useful to have a comparison matrix of features between the two.