Jul 18 2017 09:01 AM
Jul 18 2017 09:01 AM
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:
There are several alternative solutions for impacted customers, one or more of which must be implemented prior to July 2018.
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:
Note: this post is also on the Exchange Team (EHLO) blog.
Sep 25 2017 02:40 PM
Sep 26 2017 11:49 AM
Are you willing to share the managed code?
Sep 26 2017 02:54 PM
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:email@example.com;opaque=app;voicemail;local-resource-path=voicemail>, then recreate the diversion header as <sip:firstname.lastname@example.org>;reason=unknown. I then retarget the request to sip:email@example.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.
Sep 26 2017 11:43 PM
Does the AudioCodes solution require CloudPBX licensing? https://tsoorad.blogspot.com.au/2017/09/audiocodes-x-um.html suggests it does.
Oct 03 2017 07:49 AM
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.
Oct 03 2017 07:51 AM
Mar 09 2018 04:36 PM
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.
Mar 15 2018 06:42 AM
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..
Mar 15 2018 07:15 AM
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.
Mar 15 2018 07:48 AM
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.
Mar 16 2018 11:39 AM
any third party recommendation from microsoft. we are looking into the options of AVST and Avaya
Mar 26 2018 07:11 AM
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.
Apr 02 2018 02:49 PM
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.
Apr 02 2018 03:07 PM
Apr 03 2018 08:39 AM
I like AVST, I've used them on deployments even in the Lync days when the corporation wasn't fully on Exchange.
Jul 27 2018 10:19 AM
Mar 26 2019 11:37 AM
@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.