I recently had a customer who had an interesting requirement for their Lync environment. They did not want to deploy Edge servers or connect their Lync environment to the internet. However, they did want to be able to communicate with a partner who had their own Lync environment deployed in a different AD Forest. This partner and my customer both had separate networks but they shared a network link so they could route to each other at a network level. Also, there were no firewalls between these two networks which essentially made them one big network.
I decided to try configuring a trusted application and some Static SIP routes in Lync to get the two pools talking over the private network link. This was achieved with a few lines of PowerShell however there were a few pre-reqs that needed to be in place in the environment before my solution would work. So here is my scenario and the pre-reqs:
Scenario:
Forest 1: domain1.com
Lync pool 1: lync1.domain1.com
Forest 2: domain2.com
Lync pool 2: lync2.domain2.com
Pre-Reqs:
DNS needs to be resolvable from/to each domain namespace. Pool1 needs to be able to resolve Pool2’s FQDN to an IP/IP’s and vice-versa. I configured a conditional forwarder in each domain for the other domain namespace.
Each Lync Server needs to trust the other domain’s pool certificate. If this is a private CA, then the CA chain needs to be trusted. I installed the chain from domain 1 on each Front end server in pool2 and vice versa.
Obviously, the two environments need to be on routable networks with no firewalls between (or the required firewall ports open between each side of the network.
Here is the PowerShell I used:
On Pool 1:
(NB – the site ID used here can be identified using the get-cssite –identity <”site name”> cmd)
New-CsTrustedApplicationPool -Identity lync2.domain2.com -Registrar Lync1.domain1.com -site 1 -requiresreplication:$false -computerFQDN <FQDN of one EE pool server (not required for SE Pool)>
New-CsTrustedApplicationComputer -Identity <FQDN of additional EE Pool Server> -Pool lync2.domain2.com (NB – I ran this several times to add all EE Pool servers to the pool)
new-cstrustedapplication -identity lync2.domain2.com/lync2 -port 5061
Enable-CSTopology
$Route1=New-CsStaticRoute -TLSRoute -Destination “lync2.domain2.com” -MatchUri “domain2.com” –Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$Route1}
********************
On Pool 2:
(NB – the site ID used here can be identified using the get-cssite –identity <”site name”> cmd)
New-CsTrustedApplicationPool -Identity Lync1.domain1.com -Registrar lync2.domain2.com -site 1 -requiresreplication:$false -computerFQDN <FQDN of one EE pool server (not required for SE Pool)>
(NB – the site ID used here can be identified using the get-cssite –identity <”site name”> cmd)
New-CsTrustedApplicationComputer -Identity <FQDN of additional EE Pool Server> -Pool lync1.domain1.com (NB – I ran this several times to add all EE Pool servers to the pool)
new-cstrustedapplication -identity lync1.domain1.com/lync1 -port 5061
Enable-CSTopology
$Route1=New-CsStaticRoute -TLSRoute -Destination “Lync1.domain1.com” -MatchUri “domain1.com” –Port 5061 -UseDefaultCertificate $true
Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$Route1}
After a few minutes to allow replication and the new settings to take effect, users of each pool were able to see presence, IM, share screens etc.
Whilst this solution is workable for a two-pool scenario, as soon as you add additional pools / SBA’s etc, this quickly becomes an administrative nightmare. I would hesitate to recommend this as a solution for anything larger than a two-pool scenario.
