Configuring Lync Server 2010 to use more than two Exchange Unified Messaging servers

This gotcha was brought to my attention by Ari Protheroe during a recent deployment where a Lync Server 2010 Front End pool needed to communicate with an Exchange Unified Messaging dial plan that consisted of more than two servers. This is an important one to know during the planning/deployment phase of a scaled/resilient environment to ensure all the UM servers you’ve deployed are actually being utilised by every Front End server.

Thanks to insight directly from Microsoft, the changes in this post aren’t required in most scenarios as they’ve now been explained as unnecessary. I won’t delete the entire post though as it still contains some valuable information about Lync Server 2010. Read on for more information.

Setting the Scene

This setting is controlled by a process called ExumRouting which runs on each Lync Front End server in a pool. This process is responsible for routing calls from Lync to Exchange Unified Messaging servers to receive voice mail for Enterprise Voice users and to answer calls to the Subscriber Access number (plus any Auto Attendants you may have setup). If this process isn’t running or isn’t working properly, users won’t receive voice mail.

By default in Lync Server 2010, ExumRouting will only try to use 2 servers in the dial plan it’s associated with. If your dial plan consists of more servers than this, you’ll want to change this setting to use all the servers you have deployed.

Making the Fix

To fix this, we need to modify the ExumRouting.exe.config file. On the Lync Front End server, browse to C:\Program Files\Microsoft Lync Server 2010\Server\Core\ and open ExumRouting.exe.config in Notepad as shown below:

Find the key named ExumNumberOfServersToTry and modify the value from the default of 2 to however many UM servers are in the dial plan for your Lync pool (in my case it was 4). Save and close this file and repeat this process on each Front End server in your pool.

For these changse to take affect, you will need to restart the Lync Server Front-End service on each Front End server. No service restarts are required on the UM servers.

Update 22/08/2012
Jon McKinney brought to my attention in the comments that you also need to change the ExumFinalAttemptTimeLimit key from the default value of 20000 to a multiple of however many servers in your dial plan you want the Lync FE servers to contact. So as an example, if you change ExumNumberOfServersToTry to 4, then you need to change ExumFinalAttemptTimeLimit to 40000 also.

Update 30/09/2012
Doug Lawty from Microsoft recommended in the comments that this change to the ExumRouting config not be made. Here’s why:

you seem to imply that when you have four UM servers and use the default settings that two of the servers will go completely unused. This is untrue. The setting ExumNumberofServersToTry is the number of servers to try per individual call. For each call, a different two servers will be randomly selected from the four. So, all four servers will get calls spread evenly across them even with the default setting of two for ExumNumberofServersToTry.

Since we don’t document these settings, I understand how they can be confusing. I hope this helps clarify things.

 

7 thoughts on “Configuring Lync Server 2010 to use more than two Exchange Unified Messaging servers

  1. Pingback: Configuring Lync Server 2010 to use more than two Exchange Unified Messaging servers | Justin Morris on UC « JC’s Blog-O-Gibberish

  2. Jonathan McKinney

    you might also include increasing ExumFinalAttemptTimeLimit depending on the number of servers you add. Your example would still only ring 2 servers and then timeout (2 rings per server, up to 4 rings)

    Reply
  3. Richard

    Please note that the above procedure is unsupported by MS. To be exact, its nowhere written down literally that you must not mess with the exumrouting config file, but in the end that will be the jolly joker answer of PSS if you run into any trouble. Personally myself would also make these extra steps to make sure the system is completely resilient. It would make worth contacting your MS sales rep to force some statement from them regarding this issue. At the moment MS holds back any details of this functionality in order specialists not to mess with the config file, but security by obscurity is not the solution.

    Reply
  4. Doug Lawty

    For what it’s worth, I do not recommend changing the default values in the config file – no matter how many UM servers you have.

    I’m not sure if this is what you meant, but you seem to imply that when you have four UM servers and use the default settings that two of the servers will go completely unused. This is untrue. The setting ExumNumberofServersToTry is the number of servers to try per individual call. For each call, a different two servers will be randomly selected from the four. So, all four servers will get calls spread evenly across them even with the default setting of two for ExumNumberofServersToTry.

    Increasing the number of servers to try per call has little benefit for two reasons: 1) You’d have to have two UM servers down at the same time (and they would also have to be the two selected) and 2) A caller is not likely to hang on while you try a bunch of servers. Once a server is known to be down, it is less likely to be chosen for the next call. Instead, a different two from the pool of four will be tried.

    Also, and this is a minor point, there’s really no reason to change the ExumFinalAttemptLimit. It is the timer used when trying the last server on the list — not the overall timer for trying all servers. So, there’s no relationship between that value and the number of servers.

    Since we don’t document these settings, I understand how they can be confusing. I hope this helps clarify things.

    –Doug

    Reply
    1. Justin Morris

      Many thanks for the great explanation and clarification Doug. I definitely understand this functionality a lot better now.

      Reply

Leave a Reply to Justin Morris Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.