Lync UM integration breaks Lync/Exchange fax tone detection in Exchange and ability to work with third party applications

Entitled: The case of UM not responding to Unified messaging options messages.

Issue: Lync UM integration breaks Lync/Exchange fax tone detection ability.

Thanks to Tim Boudin for making this issue a priority on the Deployment team. Please be advised of an anomaly in the Unified messaging procedures that need to have some documentation behind it. I had to learn UM by repetition. In some cases I didn’t know why I had to do certain things. I just knew if I didn’t do them, UM would not work. Many years later, I still find I learn new things about Exchange UM.

In this particular usage, we were setting up UM Play on phone and Find Me features. In addition, we were trying to get Exchange Fax Detection to work with Right Fax, third party Software. Now… I hate to spoil the story; but the conclusion is much more, a justification, on why you want to read this article. Exchange 200x integration with Lync or Skype for business, will break the ability of Um to work with a third party fax provider.

This, explained by Tim Boudin, is due to the fact that the Fax options message is non TLS in Exchange 7, 10, and 13. Since Lync expects TLS only, we break the TLS integration, and UM cannot forward its Fax detect. This means that you should really look at the work around and don’t try to integrate Right Fax, Lync and UM together. It is said, you may as well just dedicate a line to right fax, coming in. Yes, bypass the deployment is what you will likely do, to be happy.

Articles to assist in your understanding:

The second article is pivotal. Fax is so under-documented, I recommend you take really good notes, or take an offline copy of the articles. This information will continue to be hard to find as Fax support goes into the sunset with Exchange, in the future. Find underlying issues below, for completeness.

Options Message

When you run the Exchange UM script, it creates the gateway for your dial plan, and sets all the authentication. It is recommended to use this script by Microsoft. There is a caveat of the script that will break UM. MS Documentation says you can create the UM Dial plan and then rename it for convenience. I would not do that! That single change can result in a broken connection between UM and AD. The only clue you will get is that UM did not respond to an options message.

The following UM IP gateways did not respond as expected to a SIP OPTIONS request.
Transport = TLS, Address =, Port = 5068, Response Code = 0, Message = Unknown error (0x80131500)

Notice we had set the UM Gateway to port 5068. More on that later.

If you check Lync logs, you will see the said options message never made it to Lync. So what options message would they be talking about? Exactly! This is an error, due to the gateway name mismatch. There is no log or other error to point you to the issue.

\ExchUCUtil.ps1 is the name of the script. If you have the options error, you simply go back and delete the gateway, and re-run the script. The script will create a gateway, with the same name as the dial plan. This way, your names will match. For example, the normal dial plan ends up being 1:1, 1 for the dial plan and 1 for the gateway. While I will not likely name my dial plan differently, you may come out with something like mydialplan:mydialplan.

Second issue commonly miss-documented (SetUmIpGateway)

An important thing to check in UM with all exchange versions is the UMIPGateway port. The command is

Get-UmIpGateway –identity “gateway name” | fl

Here you will see the setting for the gateway. Look for the PORT value. It is set to 0. There are articles that say this value is a bug. I think I may have a blog to change somewhere on this. This is not the case. Do not set this value to a static 5060 or 5061. As it turns out, this will set by exchange, and the 0 setting will allow Exchange to dynamically try tls, and then tcp if tls fails, that is what you want. Changing the value also may break a dynamic feature in Um, where the back end port changes every 7 days. It alternates between 5063, 5065, 5067 etc… this is undocumented, but confirmed by a Microsoft engineer.

In conclusion, two things you want to watch to hopefully ensure an error free Unified messaging deployment.