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

Steve Conn

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.




@Steve Conn

For Option 3,

1) what SfB Server infrastructure


2) what licensing

will be needed to pass the calls through to Exchange Online UM?

Thank you

Basically this stops all of our Office 365 deployment plans forever. Even in a small organization one year would be a laughable amount of time to make this change. How can we ever plan for future use if necessary services are dropped like this?  Please communicate that to those who made this decision.

From another of the few customers hit by this - I couldn't echo everything Greg said more.  We are in almost the exact same boat, and while we had a target painted on our PBX, it wasn't something we were hitting in a year.


I guess it was only a matter of time before drinking more of hte MS kool-aid bit us though, as sad as that reality is.

AudioCodes has also announced a solution to remedy this... it's actually pretty clever: 



I feel the same way - we were just about a week away from implementing an SBC and already purchased it (from AudioCodes). Now we have to go back to the drawing board to see what our options are. 

I'm in the same boat. Our primary voice platform is Cisco CallManager and we have SIP connect to on-premise Exchange Unified Messaging presently. We were trying to move that to Exchange Online (via an SBC) to accomodate moving our thousands of users to Exchange Online. Just bought the SBC. Just bought the subscription to SPE E3 so we could do all this. NOW we find out days later that they're dropping the SBC connection capability and don't have any other option (other than to upgrade to E5 so we can do Cloud PBX and drop our existing full phone system which would be millions of $ wasted). 


Microsoft, what about options like Azure Voicemail - could you make that a viable transition or include that capability for your E3/SPE E3 customers that might have other IP PBX on-prem? 

I do have a SfB on-premise environment but used primarily for IM/presence/conferencing. We could use that as an intermediary to get to Exchange Online UM (if that's even supported) but I can't just buy thousands of Enterprise Voice (EV) licenses for SfB either just to accomodate this thing. I'd rather not go full 3rd party voicemail either. 





+1 (with thousands of users currently on EUM), 1 year is way too quick and would be better if Microsoft had a competing product that could also fit the bill or allow us to transition to in the meantime (is Azure Voicemail a thing, something that could work for IP PBX/Exchange Online EUM customers?).


will Lync 2013 On-Premise need to upgrade prior to 7/2018?  Or, are we uneffected also.

If your company uses SBCs with Lync or Skype for Business to connect to Exchange UM for voicemail, you will be affected. You should begin planning now.


-Jeff Guillet [MVP | MCSM]



But if you're using Lync/Skype and connected with Exchange Online UM, you're most likely unaffected as this traffic will travel through your Edge server, and not a specific SBC (even if you use an SBC to connect to your phone company).  This is mostly for third party PBXs who connect an SBC to the O365 SBCs to get to Exchange Online UM.

Yes, my understanding is that we connect through the Edge for UM integration.  The blog didn't specify Lync 2013 under the "not affected" bullet points, so I was just confirming whether it was specific only to S4B.

Correct, this only affects customers who use SBCs to connect to Office 365. Some companies have more than one PBX and may use SBCs for O365 connectivity, even when they have Lync/S4B in their environment.

Just to clarify, Is Microsoft allowing us to still deploy SBC to Exchange UM currently? (Specifically in the .EDU space) provided we are fully understanding that support will end in July 2018?  The late disclosure of this after budgeting decisions and purchases have been made for the upcoming year is troubling.



I agree, most institutions (I am in Highter-Ed) have already commited to their fiscal year projects and implementation schedules. We are essentially being forced to allocate budget for a major infrastructure change with very little notice and adequate time to implement. The initial notification should give users the time to plan both technically and financially to this type of infrastructure change. Then, there should be some time allotted to allow for a migration to take place. I am both shocked and disapointed that this decision was made with little regard to the implications and effect this has on customers that invested and commited to using UM. 



You can if you set it up before July 2017 I think... otherwise, no.  If you had it set up before, you can continue to operate until 2018.  If you haven't started yet, the option shouldn't be there anymore.

Actually, there's nothing preventing customers from deploying SBC integration solutions up until the day the SBCs are decommissioned in Office 365. There's no mechanism to surface a warning to customers that the SBCs are being decommissioned, so hopefully customers will see the notifications posted in the O365 Message Center.

I stand corrected, thank you @Jeff Guillet.  I swear I remember that the creation of new IP Gateways was blocked after July.  I must have dreamed that.

No worries. I had to check with @Steve Conn directly on that.

This is still a huge issue for us, as it is the primary reason we can't currently deploy our Exchange Online subscription. This announcement was made 2 days after we made a multi-year commitment to SPE E3, predicated on the nature of our SBC design working. 

Now we're back at square one (only we're paying for it, dramatically).  Considering all the user feedback, is Microsoft considering a further reprieve or what other options might exist that would allow customers to still use Microsoft services for Exchange Online/Unified Messaging even if we aren't on the Microsoft Cloud PBX? 

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.

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?



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