We had an issue where users were able to sign in with Lync mobility but were unable to send and receive IM’s. There are 2 things to note about this scenario:
1. The users are homed on an SBA
2. There are firewalls between the SBA and the parent pool.
So if you don’t have this scenario then you can quit reading now as you won’t ever have this problem.
In order to troubleshoot why our users were unable to successfully use Lync mobility, we jumped into the logs. We reviewed the log from the mobile phone and it showed nothing useful. We enabled the Lync Logging tool on the SBA and had a user log in and try to send an instant message.
Reviewing this log, we saw a request for port 5088 form the SBA to the parent pool. The request was to a specific server in the parent pool and it was from our Survivable Branch Appliance.
If you look at the image below you’ll see this in the Snooper view of the collected log file. The ms-diagnostics line pretty much spells this out as clearly as you could expect.
Port 5088 does not currently exist on the Lync Ports and Protocols page on TechNet. Searching for this port turns up very little outside of this one TechNet article. That article points to the set-cswebserver PowerShell cmdlet which is used to define the web server settings in Lync. If you expand the Parameters section in the article and scroll down to the UcwaSipExternalListeningPort section you will see that this is set to use 5088/tcp by default. This is incorrect as this is the port used by UcwaSipPrimaryListeningPort. This TechNet article has the two ports switched in their documentation (The same error is seen when running get-help set-cswebserver -detailed).
In other words, even when Microsoft has documented this port in TechNet, they got it wrong. We didn’t see port 5089 in any of our traces so we couldn’t figure out when this port gets used.
After we updated the firewalls in front of our parent pool Lync servers, the problem immediately disappeared and our SBA users were able to successfully IM via their mobile clients.
Our contact at Microsoft has forwarded this omission to the relevant teams so hopefully at some point this will be added to the Lync ports and protocols page.
Credit to figuring this out goes to Antwan who is resurrecting his UC Playa blog. I’m just the one who wrote the article.