Let me firstly say that I have configured Lync and Exchange IM Integration numerous times and every time I perform this configuration in an Exchange Preferred Architecture Deployment I end up confusing myself and then spend a day or so fixing my configuration. (* TIP – Now that I have blogged this naturally I can reference my own blog in future J )
1 Exchange Stretched DAG which resides in 2 different data centers on the same subnet using Cisco OTV Stretched Vlan networking technology.
2 Lync Pools configured in the same network subnet.
The confusing part:
Typically I confuse myself with where I should point my “IMPROVIDER” in my exchange server web.config files since technically I have 1 Exchange, however I have two different lync pools which could potentially serve my IM configuration.
Quick and Easy Guide:
I have resorted to pointing my Exchange nodes to the Lync Pool which resides in the same physical data center.
My logic in this is that in the event of a datacenter going down, my traffic from both internal and external networks will not be routed to that datacenter which also means my exchange naturally would not be able to speak to the lync pool in that datacenter either, makes sense.
Step 1: Ensure all Exchange nodes have a separate internally signed UM certificate with the actual node FQDN in the certificate.
Step 2: Using the script provided on the technet script centre by Michel de Rooij here I configure each Exchange node to point to the local lync pool. – Note you typically have to rerun this after each CU or SP you install on Exchange.
Step 3: Enable the IM on the Exchange nodes by running the following command:
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory –InstantMessagingEnabled $True –InstantMesssagingType OCS
Step 3: Utilising get-cstrustedapplication, get-cstrustedapplicationpool I ensure that I have no reference to my Exchange 2013 nodes of load balanced names.
Step 4: Configure the Exchange Nodes as TrustedApplicationPools using the actual node FQDN’s and the local lync frontend pools:
New-CsTrustedApplicationPool -Identity Exchangenode.FQDN -Registrar LocalLyncPool -Site “SitenameofLyncPool” -RequiresReplication $False
Repeat this for all Exchange Nodes remembering to populate the registrar with the lync pool which resides in the physical datacenter where the Exchange node is located.
Step 5: Configure the OutlookWebapp Trusted Application:
New-CsTrustedApplication -ApplicationId OutlookWebApp1 -TrustedApplicationPoolFqdn Exchangenode.FQDN -Port
New-CsTrustedApplication -ApplicationId OutlookWebApp2 -TrustedApplicationPoolFqdn Exchangenode.FQDN -Port
I resorted to adding a numerical number starting at 1 to the ApplicationId, in my case I have 8 of these configured.
This will add the Exchange Nodes associated with the Lync Pool in the local data centre in the same site as the Lync Pool with which I am communicating.
It is not possible to create a single application pool with all the nodes configured in the pool since you can not configure the shared name in both sites, assuming that your lync pools are configured in separate sites.
Step 6: Configure the Exchange Partner Application
New-CsPartnerApplication –Identity Exchange –ApplicationTrustLevel Full –MetadataUrl https://yourinternalautodiscover.FQDN /autodiscover/metadata/json/1
Step 7: Enable OATH and Commit:
Set-CsOAuthConfiguration –Real yourlocaldomain.local
Assuming all the certificates in your enviroment was deployed correctly and there are no communications issues the integration should work at this point:
Good luck and note this guide also works for single server deployments or scenarios without a stretched dag or multiple lync pools.