locked
Skype for business Auto attendant call send to random Exchange server and then rejected. RRS feed

  • Question

  • Hi Team, I have a very strange issue.

    I have a Skype for Business Server 2015 with an Auto Attendant setup.

    The call is associated with one out of 5 Exchange 2016 servers and always worked as expected.

    All of a sudden the Auto Attendant stopped working and going through event logs I can see the call is now forwarded to an exchange server which is not associated with the  dial plan.

    The Exchange server then rejects the call with event log:

    The Unified Messaging server rejected an incoming call with the ID "f286e16c-fb48-471a-bb80-4a0228214c87". Reason: "This Unified Messaging server isn't associated with UM dial plan "XYZ"."

    

    The only workaround I can find is to associate all Exchange servers in my domain with the dial plan. Which is not desired.

    Can a dial plan be associated with just one out of many Exchange servers in a flat domain?

    Thanks

    Tuesday, November 13, 2018 5:55 AM

All replies

  • Hi Seppwa,

    Based on my research and understanding, it should be supported. You could refer to this blog: EXCHANGE UM ARCHITECTURE & EXCHANGE UM DIAL PLAN

    In this blog, it shows that Dial Plan also is attached to one or many Exchange UM Servers. This makes Skype servers know where to route the calls. Say that Skype wants to leave a voice mail to User A, and the want to locate an UM server, to deliver that voice mail. Skype servers will check the UM Dial Plan that User A is assigned to from User A AD object, then it reads the UM Dial plan definition from AD Configuration Partition, and then will list all UM servers attached to that Dial Plan, and it will pick one and route the call to it.
    Also, this makes things interesting for load balancing, say you have 12 UM servers and two UM dial plans, you can attach 6 UM servers to each dial plan, thus load balancing the traffic between the UM servers.

    For the issues you faced, I suggest you could try to check whether you have done some changes before this issue occurred. In addition, you could try to check the UM dial plan settings in your environment. You could also refer to this blog to find more details: Skype for Business and Exchange UM Integration

    Note: This response contains a reference to a third party World Wide Web site. Microsoft can make no representation concerning the content of these sites. Microsoft is providing this information only as a convenience to you: this is to inform you that Microsoft has not tested any software or information found on these sites and therefore cannot make any representations regarding the quality, safety, or suitability of any software or information found there. There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software on the Internet.

    Best Regards,
    Evan Jiang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.
    • Edited by woshixiaobai Wednesday, November 14, 2018 2:25 AM
    Wednesday, November 14, 2018 2:23 AM
  • Hi Evan,

    In theory this is exactly how I thought it will work.

    You attach a UM Dial plan to a single UM Exchange server and when the call is routed the SfB server will check what UM server is associated with the dial plan and then route the call to that server.

    However this is exactly the problem I am facing as this is not the case. I initially had my UM Dial plan attached to a single UM Exchange server. The calls worked for a while and then failed and it took me a long time to find out that the call was routed to an exchange server which did NOT have the UM Dial plan associated with. Further testing, reboots and troubleshooting showed that calls are forwarded to any of my UM Exchange servers in no particular order. And the UM Exchange server response is the error in my initial post.

    I read through your 2 links and it all seems very simple to setup UM it is just that the SfB server routes the calls in a random manner which doesn't sound right. I am still facing the issue and have not found a proper solution other than associating all Exchange servers with all UM Dial plans.

    Wednesday, November 14, 2018 5:41 AM
  • Hi Seppwa,

    Based on my research, you could try to check whether the Microsoft Exchange Unified Messaging service is started in the Exchange Servers which are not associated the UM dial plan. If you do not need to use the UM service in those Exchange Servers, you could try to stop it and then check whether this issue is fixed.

    Best Regards,
    Evan Jiang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    • Proposed as answer by woshixiaobai Monday, November 19, 2018 9:40 AM
    • Unproposed as answer by Seppwa Tuesday, November 20, 2018 12:50 AM
    Friday, November 16, 2018 5:38 AM
  • Hi Evan,

    We have 5 locations and all locations run SfB and UM.

    I don't want to send calls across lets say from a New York SfB server to a LA UM server and from a LA SfB server to a New York UM server.

    LA should service LA and New York should service New York. So disabling UM can't be done as all Exchange servers need to have UM. It is crazy that SfB just randomly sends calls to any UM server. I surely can't be the only one having this issue?

    Tuesday, November 20, 2018 12:53 AM
  • Hi Seppwa,

    Based on my research, UM traffic isn’t load balanced in the general sense like we do for MAPI/ActiveSync/OWA traffic. You could try to check the load balancer in your environment, check the settings for port 5060/5061 in it. You could refer to the case to do some references. 

    In addition, you could also refer to this blog to find more details: Multiple Exchange UM servers and microsoft Lync.

    Note: This response contains a reference to a third party World Wide Web site. Microsoft can make no representation concerning the content of these sites. Microsoft is providing this information only as a convenience to you: this is to inform you that Microsoft has not tested any software or information found on these sites and therefore cannot make any representations regarding the quality, safety, or suitability of any software or information found there. There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software on the Internet.


    Best Regards,
    Evan Jiang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Thursday, November 22, 2018 7:40 AM
  • Hi Evan,

    Sorry I don't think you quite understand my issue.

    I don't want to load balance. And I have no load balancer in place.

    I want SfB to send the AA call to a specific UM server. The UM server which in the same location as the SfB server.

    But SfB sends AA calls to any random UM server it can reach in the network, regardless of location and latency. So the SfB server in New York sends the AA call to Sydney even though there is a UM server in the same subnet in the same datacentre in New York. I don't want the call to be send to Sydney!

    So I need to have all UM servers setup to take any SfB AA calls from any location to any location which makes absolutely no sense.

    And If not all UM servers are configured to accept any AA calls from anywhere in the world the AA call fails with the error messages I have listed in my first post.

    - I don't want to load balance
    - I don't want redundancy
    - All I am trying to achieve is set one single UM server to accept calls from one single SfB server. Which seems to be impossible!

    Friday, November 23, 2018 6:39 AM
  • Hi Seppwa,

    According to your description, this issue didn’t occur at first, did you do some changes before this issue occurred?

    In addition, you could try to check the UM dial plan, as I said in my first reply, Dial Plan also is attached to one or many Exchange UM Servers, please check whether someone changed it. 

    Best Regards,
    Evan Jiang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Tuesday, November 27, 2018 8:52 AM
  • Hi Evan,

    no changes were made, it started randomly. I checked this with my counterpart (there is only 2 people who have access to make changes).

    If the dial plan is only attached to one UM server (the one I want to answer) then the issue occurs. Only if I assign the dial plan to all UM servers does the error go away as Lync sends the call to any random UM server.

    Wednesday, November 28, 2018 6:16 AM
  • Hi Seppwa,

    About this issue, I suggest you could try to use tools to check the traffic in the UM Server, such as using netmon or wireshark to see the SIP conversations.

    Best Regards,
    Evan Jiang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Friday, November 30, 2018 8:58 AM
  • Hi Seppwa,

    Is there any update for this issue, if the reply is helpful to you, please try to mark it as an answer, it will help others who have the similar issue.

    Best Regards,
    Evan Jiang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Tuesday, December 4, 2018 6:16 AM
  • Hi Evan,

    so far no update or solution to the issue. All I can see in wireshark is that the call is send to any UM server in the environment. Regardless of if the server is selected in the dial plan or not.

    Wednesday, December 5, 2018 1:22 AM
  • Hi Seppwa,

    As the UM worked as expected before, I suggest you could try to use the Exchange Audit to get the log on the time node when the problem suddenly occurred. Then check whether some changes have been occurred in the Exchange server.

    Best Regards,
    Evan Jiang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    • Proposed as answer by woshixiaobai Friday, December 14, 2018 6:34 AM
    • Unproposed as answer by Seppwa Monday, December 17, 2018 12:40 AM
    Friday, December 7, 2018 7:31 AM
  • Hi Evan,

    As mentioned no changes were made. Exchange logs were audited.

    The issue can be re-produced. The Skype for Business Server sends the call to any Exchange, the Exchange which receives the call changes and there is no pattern to which Exchange the call is routed.

    It continuously is send to any Exchange, if the server is selected in the dial plan or not is not relevant. Therefore if the particular Exchange is not selected in the dial plan the call fails. If the Exchange is selected in the dial plan the call is successful. There is no pattern which Exchange is selected. No research or Documentation I found has a clear explanation how SfB sends UM calls to Exchange servers.

    Monday, December 17, 2018 12:43 AM