Exchange Online Auto Attendant does not transfer calls to extensions in Skype for Business Server 2015

Update: Microsoft released CU 1 for Skype for Business which resolve the issue described below:

I’ve recently encountered a problem after upgrading my production environment Skype for Business Server 2015 with normalizing extension numbers coming from the Exchange Online Auto Attendant.

In my company we have integration between Exchange Online and Skype for Business Server 2015 On-Premises and one of the management requirements is to have granular Auto Attendant features with Menu navigation.

In order to achieve this, we are using the Exchange Online Auto Attendant features which allow you to transfer calls to Lync Users based on the user UM extension and the matching SIP address.

The Problem:

On Lync 2013 everything worked as expected and all calls were transferred to the right extension once the business hours menu navigation was on.

After upgrading to Skype for Business Server 2015, it turned out that during business hours when the Menu navigation was played, calls were not being transferred to Lync users, but just looping the Exchange auto attendant play message instead.

What was even weirder was the fact the if we switched the Auto Attendant to Off Business Hours when there is no menu navigation but just an option to enter a user extension, it did worked and the call was successfully transferred to the Lync user.

To make a long story short:

  • Setting Enabling Business hours menu navigation with different prompt options which result in Extension transfer stopped working.
  • Calling to the Auto Attendant on Non-Business hours where Menu Navigation is disabled result in a Voice command instructing you to type the actual extension of the user, once the extension was entered the call was transferred successfully.



Once we were able to reproduce the problem, we decided to take some logging on the Front-End’s to determine why there is a different behavior between typing an extension manually and choosing a menu selection for transfer a call to the exact same extension.

Scenario #1: Menu Navigation Enabled During Business Hours

In this scenario, I dialed to the Auto Attendant during Business Hours and selected option #4 in the menu navigation which supposed to transfer to me to extension 7089 which is my UM extension.

What you can see in the logs is that instead of translating my extension to my SIP address, the SfB server is trying to ring at 7089 number which does not resolve at a user and eventually a BYE is being sent back. You can also see it in the REFER messages that the REFER to is resolved to a number instead of SIP URI of my user.


Scenario #2: Menu Navigation Disabled During Non Business Hours

During Off Business Hours, the Auto Attendant does not play menu options, but just a general voice prompt saying: “Enter the extension of the person you calling”, once I hit the exact same extension number 7089, you can see it resulted in REFER TO that translated to the proper SIP Address of my user account and there the call is being transferred.



I’ve been told by a Microsoft engineer that it is seems to be a BUG within Skype for Business Server and the way it normalized those UM Extensions, and that they got a few calls already describing similar problem.

As of now, it seems the workarounds are either one of the following options until Microsoft will be able to fix it:

  1. Move the CsEXUmContact object back to a Lync 2010 / 2013 server if you have any server within the topology.
  2. Disable the Menu navigation option on the Exchange Auto Attendant side and allow to dialing direct extension with no key-mapping.

Update: Microsoft confirmed this behavior will be fixed in CU1 for Skype for Business Server.

1 Comment

  1. Mike McLachlan

    I have this problem too! We created a dummy user & enabled team calling for it & diverted the incoming lines to its sip address, so instead of the autoattendant we have a select few operators who can transfer the call to the appropriate person/group

Comments are closed.