I recently worked on an engagement where the integration of Exchange Server 2013 and Lync Server 2013 was performed including all the new bits like Unified Contact Store, Archiving, etc. During the course of the engagement we struggled with OWA IM integration configuration and found discrepancies in the guidance from Microsoft and other bloggers out there.
So I'd like to take the time to share my experiences on two fronts; in resolving the error(s) associated with Lync/UM integration, and the OWA IM integration debacle.
So first, UM integration...
Everything was working fine from a UM perspective until we started messing with OWA IM integration troubleshooting. During this effort we decided to remove the trusted application pool representing the FQDN of the mail environment (i.e. mail.contoso.com) and all the trusted application servers within the pool. Topology was published and no issues were found, however this also didn't solve our OWA IM integration issue by the way.
One issue I did see was that the Lync environment wasn't discovering Exchange correctly and had removed the servers from it's internal "Trusted Servers" list. As a last troubleshooting step I restarted the front-end service on the primary Lync Standard Edition server however this again didn't resolve the OWA IM issue. So I added the trusted pool and servers back, published topology, restarted the front-end service on the primary Lync server, and validated they were back in the "Trusted Servers" list again.
I dropped the troubleshooting effort for the night only to realize the next morning that UM was broken across the board except for users homed on the primary Lync Standard Edition server. The only "change" made earlier that night was the topology change but how could this affect UM?
The following error was observed from my local Lync client when testing UM:
Even though I had reverted my change related to the trusted application pool and servers being removed from topology builder, I had to restart the front-end services on the secondary Lync Standard Edition server AND the SBS for voicemail to start working again.
So the moral of the story, even though you don't think the change you're making is conceivably a client impacting event, it could be. I should have tested EVERYTHING before calling it a night.
Now onto the OWA IM integration issue...
TechNet (http://technet.microsoft.com/en-us/library/jj688055.aspx) claims there is no need to create a trusted application server or pool (if more than one E2013 FE) if the 2013 front-end/back-end roles are collocated and if you have a SIPURI dialplan in UM. In every case where I've configured this type of 2013 to 2013 interoperability, I always need to define the trusted application pool. In other words, the autodiscover from Lync to Exchange never works correctly. Once I populate the trusted application pool, OWA IM lights up!
It seemed obvious to me the linkage between the "Trusted Servers" list identified by the Lync server in Event ID 33022 had something to do with OWA IM not working. Adding it back into topology was reflected by Event ID 33022 and the functioning OWA experience.
Anyway, I invite your comments and feedback on these. Cheers!
So I'd like to take the time to share my experiences on two fronts; in resolving the error(s) associated with Lync/UM integration, and the OWA IM integration debacle.
So first, UM integration...
Everything was working fine from a UM perspective until we started messing with OWA IM integration troubleshooting. During this effort we decided to remove the trusted application pool representing the FQDN of the mail environment (i.e. mail.contoso.com) and all the trusted application servers within the pool. Topology was published and no issues were found, however this also didn't solve our OWA IM integration issue by the way.
One issue I did see was that the Lync environment wasn't discovering Exchange correctly and had removed the servers from it's internal "Trusted Servers" list. As a last troubleshooting step I restarted the front-end service on the primary Lync Standard Edition server however this again didn't resolve the OWA IM issue. So I added the trusted pool and servers back, published topology, restarted the front-end service on the primary Lync server, and validated they were back in the "Trusted Servers" list again.
I dropped the troubleshooting effort for the night only to realize the next morning that UM was broken across the board except for users homed on the primary Lync Standard Edition server. The only "change" made earlier that night was the topology change but how could this affect UM?
The following error was observed from my local Lync client when testing UM:
ms-diagnostics: 15030;reason="Failed to route to Exchange Server";source="lync01.contoso.local";dialplan="dp01.contoso.local";pstnreroutingenabled="false";appName="ExumRouting"The following error showed up on the Lync server:
Server: ExumRouting/5.0.0.0
An attempt to route to an Exchange UM server failed.Additionally, I found the following error through CLS Logging trace:
The attempt failed with response code 504: mb01.contoso.local.
Request Target: [dp01@mb01.contoso.local], Call Id: [0d493c0beac55e4d1938b96d9f0488dc].
Failure occurrences: 27, since 2014-03-07 8:15:44 AM.
Cause: An attempt to route to an Exchange UM server failed because the UM server was unable to process the request or did not respond within the allotted time.
Resolution:
Check this server is correctly configured to point to the appropriate Exchange UM server. Also check whether the Exchange UM server is up and whether it in turn is also properly configured.
TL_ERROR(TF_CONNECTION) [se01\se01]08E8.0CFC::03/07/2014-18:05:22.538.000002E9 (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(389)) [3492250981] $$begin_recordVoicemail was working fine for users on the one Lync server but not for users on the SBS or secondary Lync Standard Edition server. Could the removal of the trusted application servers and pool from topology break UM? Well as a step to fix this I ran the ExchUcUtil.ps1 script to integrate the two environments together again and triple checked all the configuration in UM to see if something was missed or changed by accident. None of this worked.
Severity: error
Text: The peer is not a configured server on this network interface
Peer-IP: 10.222.10.69:55561
Transport: TLS
Result-Code: 0xc3e93d6a SIPPROXY_E_CONNECTION_UNKNOWN_SERVER
Data: fqdn="se01.contoso.local"
Even though I had reverted my change related to the trusted application pool and servers being removed from topology builder, I had to restart the front-end services on the secondary Lync Standard Edition server AND the SBS for voicemail to start working again.
So the moral of the story, even though you don't think the change you're making is conceivably a client impacting event, it could be. I should have tested EVERYTHING before calling it a night.
Now onto the OWA IM integration issue...
TechNet (http://technet.microsoft.com/en-us/library/jj688055.aspx) claims there is no need to create a trusted application server or pool (if more than one E2013 FE) if the 2013 front-end/back-end roles are collocated and if you have a SIPURI dialplan in UM. In every case where I've configured this type of 2013 to 2013 interoperability, I always need to define the trusted application pool. In other words, the autodiscover from Lync to Exchange never works correctly. Once I populate the trusted application pool, OWA IM lights up!
It seemed obvious to me the linkage between the "Trusted Servers" list identified by the Lync server in Event ID 33022 had something to do with OWA IM not working. Adding it back into topology was reflected by Event ID 33022 and the functioning OWA experience.
Anyway, I invite your comments and feedback on these. Cheers!