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 thinks I didn’t know. I will share those with you today.
In this particular usage, we were setting up UM Play on phone and Find Me features.
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 = yourserver.name.com, 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 (Set–UmIpGateway)
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.