I am a bit ashamed to say that I wasted most of a day on this, but I’m posting this in the hopes that I can help someone else avoid the same mistake I made.
I just spent about five hours troubleshooting why I couldn’t get Exchange 2013 Outlook Web App to display IM and presence data from a Lync 2013 standard edition server. I had carefully followed the integration steps in the documentation, including the part that says this:
If you have installed the Microsoft Exchange Unified Messaging Call Router service and the Microsoft Exchange Unified Messaging service on the same computer then there is no need to create a trusted application pool for Outlook Web App. (This assumes that the server in question is hosting a SipName UM dial plan.
So, having read that, I didn’t set up a trusted application pool or trusted application… and IM didn’t work.
I fussed with certificates. I read a ton of documentation. I swore. I drank too much diet Coke. I ran OCSLogger and found errors about an unknown peer. “AHA!” I thought. “There must be an error in the docs and you really do need to create a trusted application pool.”
So I created the pool and the trusted app. Two quick lines of PowerShell, a quick login to OWA, and voila:
As much as I would like to claim that it was a documentation error, this was pure fail on my part: the problem was that my Exchange 2013 server doesn’t host a SIP dial plan, so Lync doesn’t automatically add it to the Lync known servers table. It will have a SIP dial plan when I get to the next section of this chapter, but that’s a post for another day.
So, in summary: yes, you do need to create a trusted application pool and application for your Exchange servers even if they are multi-role unless they are hosting a SIP dial plan.
Now, time for another diet Coke…