Lync 2013 and OWA Integration Troubles

Gratuitous Intro to the Situation

Ok, so we'll keep this short(ish) and sweet. Integrating your Lync Server 2013 on-premise environment with your Exchange Server 2013 on-premise environment is a fairly common goal within companies that wish to leverage even a few of the awesome "unified communication" features that come with the grouping of these awesome applications. Moreover, there are exactly 12,073,258 (Disclaimer: the preceding statistic is a completely bogus number) different blog posts and forum entries on the web detailing how to go about integrating Lync with Exchange. So, this issue assumes that you already have integration setup and verified to be working. At least partly working...

The Actual Problem

Some sporadic, not all, Exchange mailboxes were unable to login to Outook Web App (OWA) and successfully sign-in to Lync from within OWA. If the user is enabled for both Lync and Exchange using the same SIP domain (Example: @msucguy.com), they should be able to log into OWA, and sign in to Lync from within OWA, at which point they can initiate chats from their web browser. Below is what one would expect to see in such a scenario:

However, for the sporadic few users that were not seeing this, they would instead see the below message once logged into OWA:

The notorious, "There's a problem with IM. Please try again later. If the problem continues, contact your helpdesk" error. 

How to Troubleshoot

There are a few things to consider when trying to get to the bottom of this pesky error. Let's dig into a few of the key things to check for.

1. While this post assumed that the Lync integration with Exchange had already been setup successfully (partially, anyway), let's take a step back and forget about the fact that we already know some users are successfully logging into Lync via OWA. If we know of no instances of users accessing IM within OWA, we want to ensure that Lync does in fact trust Exchange (and OWA). To do this, let's open up the ever-so-handy-dandy Lync Server Management Shell. Once in the Lync Server Management Shell, we will run the cmdlet "Get-CsTrustedApplicationPool". We should see the below results, listing out your OWA URL up top, specifying your Lync Pool as the Registrar, and listing "urn:application:outlookwebaccess" in the Application field:
   
2. Next, with the Lync Server Management Shell still opened, we will run the "Get-CsTrustedApplication" cmdlet. The results should look like below. Note the port number 5199. If you have a pretty tightly locked down network internally, you will want to make sure that your Lync Front End servers can reach your OWA servers on port 5199.
   Ok, I realize that most of this image is "whited out", but you get the picture. Make sure your FQDNs are where the white out sections are, and make sure "outlookwebaccess" shows up where it should.
3. Now that we have verified that our Lync environment is properly set up to trust the Exchange servers, let's go back to assuming that we now know for a fact that IM works for some users within OWA. If we know that it does work, at least for some, then we need to verify that there is not, in fact, problem with "IM" (a.k.a., Lync Server 2013). Of course we can verify this by checking to make sure that we are able to log into our desktop or mobile clients with Lync, but this does not rule out that there is an isolated problem in the environment. To make sure all is well, quickly log into the Lync Server Control Panel (LSCP), and browse to the "Topology" tab. On this tab, ensure that all your relevant servers show up with a green check mark for their Replication Status, and then ensure that all servers report a healthy status for their services. We will assume that all is well on these checks, and that the environment is perfectly healthy.

The Resolution (at least in my case)

Alright, well now that we verified that Lync is in fact set up to trust Exchange and OWA properly, that the Lync environment is not having any sort of issues, and that IM within OWA does actually work for most users, we need to do some checking on the individual user level. A topical inspection of the user's settings within Exchange and Lync didn't reveal anything that stood out right away, so we decided to do a side-by-side comparison of a user that was experiencing the issue versus a user that was not experiencing the issue by looking at their properties within ADSIEdit. ADSIEdit allows us to get a really granular view of all possible attributes that can be set for a user within the realms of Active Directory-integrated applications, like Lync and Exchange.

Sure enough, there was a single attribute that did not get set for the accounts experiencing the problem: msExchOWAPolicy. And wouldn't you know, that attribute sounds like it just may have something to do with the problem we are experiencing. The value for the problematic user was set to "<not set>", when it should have been set to the Default policy, like so:

Technet does a dandy little job explaining how a default policy is created when Exchange is installed, and that this policy has ALL options enabled by default, BUT this default is not set on any mailboxes by default: https://technet.microsoft.com/en-us/library/dd335142%28v=exchg.150%29.aspx. So, if your Exchange admins/engineers don't have a provisioning process that sets this value for each user, or if the process allows for a user or two to slip through the cracks, you might just find yourself with a handful of users that magically can not sign into IM within OWA.

Well, I supposed I completely blew the attempt to keep this short and sweet, but I hope this is helpful for someone out there, and that they don't have to spend too long trying to track the problem down.

Stay techy, my friends!