Been through many troubleshooting articles and still cannot resolve the "There's a problem with IM" message in OWA. Have confirmed the following:

• web.config on all servers
• Trusted partnership on Exchange and Lync
• OwaVirtualDirectory (all servers) and OWAMailboxPolicy for users
• SIP type address for users
• Configured Lync with and without CSTrustedApplicationPool and CSTrustedApplication applications with no affect.

What remains are certificate issues. The major problem seems to be that all guides and troubleshooting tips are for test environments or micro environments with one Exchange box and one Lync FE. We have a Lync enterprise config that is load balanced and 2 Exchange servers with all roles one each and it is load balanced. The breakdown seems to be in what certificate is used on the Exchange systems but not sure if that is truly the case. Present configuration is such:

Exchange

2 Servers with MBX, CAS, U, and UC roles

CAS is load balanced using SAN cert (mail.contoso.com, autodiscover.contoso.com) whereas the servers have domain FQDN's of EX1.domain.local and EX2.domain.local. Therefore there are two certs that are IIS enabled. The mail.contoso.com cert and a self-signed cert. Cannot change that without breaking things unless the new cert has a subject name of mail.contoso.com

Lync

2 FE servers that are load balanced using a SAN cert with names such as lyncpool.contoso.com, lyncadmin.contoso.com, dialin.contoso.com, lyncdiscover.contoso.com, lyncdiscoverinternal.contoso.com, meet.contoso.com, LyncFE1.domain.local, lyncFE2.domain.local

Attempted from Lync side to perform

set-CsTrustedApplicationPool -Identity mail.contoso.com -registrar lyncpool.contoso.com -Site lyncsite and then add CsTrustedApplications for each Exchange server

set-CsTrustedApplicationPool -identity mailcontoso.com -registrar lyncpool.contoso.com -Site lyncsite -ComputerFqdn ex1.domain.local and then adding another computer by new-CsTrustedApplicationComputer -identity ex2.domain.local -Pool mail.contoso.com. Still no dice

Does the cert being used on the Exchange servers, since they hold CAS and MBX roles have to be a SAN cert like such as:

Subject: mail.contoso.com; SANs: autodiscover.contoso.com, ex1.domain.local, ex2.domain.local

for this to work properly?

Hi Peter,

Some questions for you.

What do you mean by "Therefore there are two certs that are IIS enabled."

As same IIS service can't be linked to 2 certs at a time.

CAS is load-balanced using what NLB,HLB,DNS RR?

Is your Exchange a multirole, do you have DAG?
NLB and DAG can't coexist.

Are your certs trusted by each other Lync, Exchange

Which article are you refering for this configuration.

Integrating Microsoft Lync Server 2013 and Microsoft Exchange Server 2013:

https://technet.microsoft.com/en-us/library/jj688098(v=ocs.15).aspx

Manage server-to-server authentication (OAuth):

https://technet.microsoft.com/en-us/library/jj204817.aspx

https://technet.microsoft.com/en-us/library/jj204817(v=ocs.15).aspx

#Run this on Exchange to check if the valid certificate is listed here or not
 Get-AuthConfig		

I assume W stands for IIS under services property when running get-exchangecertificate. See screenshot.

Cert 5 is self-signed. Load balancing SMTP and IIS using Kemp LoadMaster. Yes there is a DAG, wouldn't go without it. Saw an article about setting AuthConfig cert but was not real keen on mucking with that on the production environment without understanding what the implications might be. Lync and Exchange both trust the certs assigned to Lync services and Exchange IMAP, POP, IIS, SMTP, UM, and UMC. oAuth on Lync set to same cert used for all Lync front-end services. Exchange Auth Configuration cert would not be trusted by any of the systems since it is Issued by "Microsoft Exchange Server Auth Certificate" but I didn't think it had to be. Poorly documented function as near as I can tell and only enabled for SMTP within Exchange (again, as near as I can tell). It is never mentioned in any troubleshooting or TechNet integration articles unless I missed something.

Cert 5 is the self-signed.

Hi Peter,

Thanks for the info. The image attached appears to be a thumbnail to me for some reason.

In order to configure server-to-server authentication for an on-premises implementation of Lync Server 2013 you must do two things:

• Assign a certificate to Lync Server's built-in token issuer. (This you confirmed is already done - Get-CsCertificate -Type OAuthTokenIssuer)

• Configure the server that Lync Server 2013 will communicate with to be a "partner application." For example, if Lync Server 2013 needs to communicate with Exchange 2013 then you will need to configure Exchange to be a partner application. (What about this part, have you run ServerToServerAuth.ps1 and  Configure-EnterprisePartnerApplication.ps1)

This was all done long ago. There are partner applications configured on both sides of the communication (Lync and Exchange). Global Get-CsOAuthConfiguration lists the partner applications in Lync and Exchange is there with the appropriate application identifier, autodiscover URL etc..

Finally figured out the problem. Apparently when we first setup OWA - Lync 2013 integration we had not configured enterprise voice and, therefore, did not have a SIP URI dial plan in Exchange. So, to get it to work at the time we had to configure a trusted application pool and trusted applications within Lync to communicate with Exchange. However, we then setup a SIP URI dial plan which then caused an issue within Lync because it was auto discovering the Exchange servers that conflicted with the trusted application pool and trusted application settings and shutting the whole thing down. I had suspected that and played around with removing the pool and applications from Lync, reading them, etc. Numerous times. However, the FE service was never restarted on the Lync servers so it would never work regardless of whether the trusted application pool and trusted application settings were enabled in the topology. The solution was to remove the trusted application pool, restart front end services, and then log in to OWA.

• Marked as answer by Peter Souza 10 hours 53 minutes ago

Finally figured out the problem. Apparently when we first setup OWA - Lync 2013 integration we had not configured enterprise voice and, therefore, did not have a SIP URI dial plan in Exchange. So, to get it to work at the time we had to configure a trusted application pool and trusted applications within Lync to communicate with Exchange. However, we then setup a SIP URI dial plan which then caused an issue within Lync because it was auto discovering the Exchange servers that conflicted with the trusted application pool and trusted application settings and shutting the whole thing down. I had suspected that and played around with removing the pool and applications from Lync, reading them, etc. Numerous times. However, the FE service was never restarted on the Lync servers so it would never work regardless of whether the trusted application pool and trusted application settings were enabled in the topology. The solution was to remove the trusted application pool, restart front end services, and then log in to OWA.

• Marked as answer by Peter Souza Thursday, July 30, 2015 8:35 PM

Hi Peter,

Thanks for coming back and updating us with the resolution