Forum Discussion
Steve_Conn
Microsoft
MicrosoftDiscontinuation 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
Skype for Business Server Enterprise Voice
Note: this post is also on the Exchange Team (EHLO) blog.
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.
:(
- Steve_Conn
Prabhat Nigam Hi Mr. Nigam - thank you for your kind thoughts. Please note that my original post at the top of this thread was placed here as a courtesy notification. The official notice was via Message Center post, and echoed via the Exchange Team blog. Also note that there has been change in the recommendations, etc. from the time that we did the initial notification, so the post at the top of this thread has been superceded. Thanks! Steve
Steve_Conn Thank you for the quick response.
Not sure what makes Tony mad, just my presence or something in my text.
My text was the words from PG (Nathan's) and I am just a messenger who is delivering them to get this technical issue fixed for everyone.
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-messaging/Screenshot of of original Technet article attached to this post..
- 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 any third party recommendation from microsoft. we are looking into the options of AVST and Avaya
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.
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.
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.
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.
- 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 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?- I agreed you Chris.
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.
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.
Steve,
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.
AudioCodes has also announced a solution to remedy this... it's actually pretty clever:
http://online.audiocodes.com/exchange-online-unified-messaging-x-um
Does the AudioCodes solution require CloudPBX licensing? https://tsoorad.blogspot.com.au/2017/09/audiocodes-x-um.html suggests it does.
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.
