Microsoft has released a new announcement regarding the discontinuation of support for Session Border Controllers (SBC) in Exchange Online Unified Messaging. You can find the announcement on the Exchange team blog (comments closed) and the Microsoft Tech Community (discussion open).
Update, April 25th 2018 – Microsoft has announced that April 2019 is the new deadline for this.
July 2018(see note above), 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 standard Exchange and Skype for Business protocols.
That’s only a year from now, which is a long time in the cloud but not very long at all for on-premises environments, particularly for large, complex on-premises environments which are the most likely to be impacted. As fellow MVP Jeff Guillet says:
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.
The transition to Sfb (Skype for Business) or SfBO (Skype for Business Online) that Jeff mentions above are two of the options that Microsoft suggests for customers who are impacted by this change.
- 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.Update, 1st March 2018 – Microsoft no longer recommends this option (post has been removed by Microsoft).
- 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.
Aside from the time pressure, all of those options involve a cost to the customer. Migrating to Office 365 Cloud PBX may be the least expensive option for customers who are already paying for Enterprise E5 licenses. But none of the options is likely to be cheap or simple. Either way, I see this simply as part of Microsoft’s grand strategy to jettison legacy platforms and solutions that are complex and not highly profitable, and focus on services like Cloud PBX that they can deliver more efficiently.
If you’re looking for some more technical detail I suggest reading Jeff’s blog post here that breaks down the situation and explains how customers are impacted by this change, and also expands on Option 3’s suggestion of using a third party connector.
I assume Microsoft’s version of “only a small number of customers” is the same as mine and this change doesn’t have widespread implications, so I don’t actually expect to see this news cause a big stir in the community. Such is life in the cloud. The energy is probably better spent on planning a migration before July next year.