Sie sind auf Seite 1von 6

Integrating Exchange 2013 + Lync 2013 for UCS & OWA integration

First, the foundation of communication between Exchange and Lync 2013 is based on the new Office Web App OAuth calls for server-to-server
communication. As part of the installation of Lync 2013 you had to install SSL certificates to start the services, however for Exchange youll want to
make sure youre not using the self-signed certificates. An internal CA is fine (were using this in our test environment), third party is even better, but
the self-signed will not be able to communicate because its missing the necessary subject names.
First lets get the autodiscover service URI:
get-clientaccessserver | fl fqdn, autodiscoverserviceinternaluri
AutoDiscoverServiceInternalUri :
Also lets take on the Lync side and get the pool FQDN:
PS C:\Users\administrator.COMPANY> Get-Cspool | where-object {$ like *UserServer*} | fl site, fqdn
Site : Site:ConnectUC
Fqdn :
Since were using internally signed certificates, well want to try accessing these URLs from both the Lync and Exchange servers, and ensure we can
open them via IE without any certificate warnings.

On the Exchange 2013 environment, we link up to Lync:

cd $exscripts
.\Configure-EnterprisePartnerApplication.ps1 AuthMetadataUrl -ApplicationType Lync
Now lets update Exchange to enable IM!
The process isnt that different from Exchange 2010, except Ive noticed that Exchange 2013 holds on to an internal self-signed certificate so we
cant blindly use a wildcard to pipe the certificate like we did before. We need to determine which thumbprint to use by looking at the Subject name
and Issuer.
Update 7/13/15 Update If you dont have a SAN certificate with your server names, I highly recommend requesting a dedicated certificate from an
internal PKI with the subnet name in it. As long as its trusted internally by all (Exchange & Lync) servers, it will serve the purpose!
Get-ExchangeCertificate | where-object {$ -like *iis* } | fl subject, issuer, services, thumbprint
Subject :, OU=Connect UC, O=IT, L=Minneapolis, S=MN, C=US
Issuer : CN=cloud-CIRRUS-CA, DC=cloud, DC=local
Services : IMAP, POP, IIS, SMTP
Thumbprint : 5FB91CB7AB7677EF45B5C809CF8CB9CFDB31D0A1
Subject : CN=VL-EXG-01
Issuer : CN=VL-EXG-01
Services : IIS, SMTP
Thumbprint : 86F218D2E3AF6D98422F18E1217C101BBC0F000B
Now that we have the thumbprint, and we know our Lync pool FQDN, lets plug it in.

7/13/2015 Update Ive implemented the FREE Kemp virtual LoadMaster for my Lync 2013 May 2015 update and Exchange 2013
CU9 servers, but it doesnt change the process that much. Make sure you have a valid local certificate thats trusted & everything should work OK.
When we enable Lync IM for Exchange, we only want to target the FRONT END servers.
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InstantMessagingEnabled $true -InstantMessagingType OCS
-InstantMessagingCertificateThumbprint 5FB91CB7AB7677EF45B5C809CF8CB9CFDB31D0A1 InstantMessagingServerName
Get-OwaMailboxPolicy | Set-OwaMailboxPolicy -InstantMessagingEnabled $true InstantMessagingType OCS
Next, lets change the OWA web.config information. Use Notepad to open the following files
7/13/2015 Update -Youll need to reconfigure the web.config with each Cumulative Updates you run!
Notepad C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\web.config
Under <appSettings> add 2 lines, substituting your Exchange certificate thumbprint (which we already obtained) and the Lync pool name:
<add key=IMCertificateThumbprint value=5FB91CB7AB7677EF45B5C809CF8CB9CFDB31D0A1 />
<add key=IMServerName />

Then recycle the related IIS pool

C:\Windows\System32\Inetsrv\Appcmd.exe recycle apppool /
Then over on the Lync side, we have a few commands to run in order to integrate with Exchange.
First, we create a Partner Application:
New-CsPartnerApplication -identity Exchange -ApplicationTrustLevel Full -MetadataUrl
7/13/2015 Update With Lync 2013 May 2015 update and Exchange 2013 CU9 update I didnt actually find my environment start working until
I ran the commands below to clear out the existing pools. I was actually able to LEAVE THEM REMOVED and then IM worked.
Get-CsTrustedApplicationPool | Remove-CsTrustedApplicationPool
Get-CsTrustedApplication | Remove-CsTrustedApplication
Using the Lync 2013 Centralized Logging Tool I discovered some SIPPROXY_E_CONNECTION_UNKNOWN_SERVER entries from my
Exchange server, despite my Trusted Applications being for the NLB VIP DNS record. This tells us the calls are made directly from the Exchange

server hosting the OWA session. And even when I logged into OWA using the server FQDN (that wasnt a Subject Name in my Certificate and threw
a certificate error) IM still worked.
Im going to keep an eye on this to see if maybe the New-CsPartnerApplication alone facilitates connectivity to Exchange.
7/13/2015 Update If IM still doesnt work, use the commands above to remove them!!
Next we create our trusted application pool/application. Well want to use the individual server names themselves (and make sure we have the
corresponding SSL certificate in the web.config with a subject name matching the server FQDN).
New-CsTrustedApplicationPool -Identity -Registrar -Site ConnectUC -RequiresReplication
New-CsTrustedApplication -ApplicationId OutlookWebAccess -TrustedApplicationPoolFqdn -Port 5199
Next, we can enable our User accounts in Lync

If all went successfully, lets log into OWA and click to Sign in to IM

And success!

Posted on November 1, 2012 at 1:57 pm

This post is filed under Exchange, Lync.