Sunday, March 17, 2013

Creating separate static routes for Lync Server 2013 and Avaya RCC integration spread across data centers for disaster recovery

As indicated in one of my earlier posts:

Lync Server 2010 or 2013 IM (Instant Messaging) conference no longer works with RCC (Remote Call Control) configured with a PBX

…. the instructions provided by the guide:

Implementation notes on Integration of Avaya Aura Application Enablement ® Services with
Microsoft® Lync® 2010 Server.


… from Avaya could have the instructions improved or possibly get a refresh to prevent administrators from running into various issues.  One of the questions I’ve been asked when this was initially available for Lync Server 2010 which I also anticipate to be the same for Lync Server 2013 is how to create specific static routes so we could have multiple Avaya AES servers in the environment, one for the production and another for DR pool.  As shown in the Avaya RCC deployment guide, the example static route command does not specify an identity switch:


… and therefore would create a static route under the global identity:


This is not ideal if we are configuring 2 sites in the Lync Server 2013 topology with 1 Lync pool in the production site and another Lync pool that serves as a backup in the second site.

The solution to this problem is quite simple and that is to specify an identity switch specifying the registrar (Lync pool) during the creation of the static route.  The following cmdlet demonstrates this:

$TLSRoute = New-CsStaticRoute -TLSRoute -Destination aes.domain.internal -Port 4723 -UseDefaultCertificate $true -MatchUri aes.domain.internal

Set-CsStaticRoutingConfiguration -Identity service:Registrar:svrlyncstd02.domain.internal -Route @{Add=$TLSRoute}

Executing the cmdlet above would create a specific static route that does not belong to the global identity:


With the modified cmdlet for setting the TLSRoute variable and then creating the static route, the cmdlets we’ll need to execute to create the route and trusted application and trusted application pool are as follows:

New-CsStaticRoutingConfiguration -Identity "service:Registrar:svrlyncstd02.domain.internal"
$TLSRoute = New-CsStaticRoute -TLSRoute -Destination aes.domain.internal -Port 4723 -UseDefaultCertificate $true -MatchUri aes.domain.internal
Set-CsStaticRoutingConfiguration -Identity service:Registrar:svrlyncstd02.domain.internal -Route @{Add=$TLSRoute}
New-CsTrustedApplicationPool -Identity aes.domain.internal -Registrar svrlyncstd02.domain.internal -Site 1 -TreatAsAuthenticated $true -ThrottleAsServer $true -RequiresReplication $false
New-CsTrustedApplication -ApplicationID avaessrv -TrustedApplicationPoolFqdn aes.domain.internal -Port 4723

Once the cmdlets shown above are executed, the Avaya AES server for the production Lync 2013 pool will be created and you should immediately have RCC operational.  To get the DR site configured, execute the following and change the appropriate fields as required:

New-CsStaticRoutingConfiguration -Identity "service:Registrar:svrlyncstd03.domain.internal"
$TLSRoute = New-CsStaticRoute -TLSRoute -Destination aesdr.domain.internal -Port 4723 -UseDefaultCertificate $true -MatchUri aes.domain.internal
Set-CsStaticRoutingConfiguration -Identity service:Registrar:svrlyncstd03.domain.internal -Route @{Add=$TLSRoute}
New-CsTrustedApplicationPool -Identity aesdr.domain.internal -Registrar svrlyncstd03.domain.internal -Site 2 -TreatAsAuthenticated $true -ThrottleAsServer $true -RequiresReplication $false
New-CsTrustedApplication -ApplicationID avaessrvdr -TrustedApplicationPoolFqdn aesdr.domain.internal -Port 4723

Note the changes for AES server’s FQDN, the site number and the registrar pool.

With both the production and DR sites configured, a Get-CsStaticRoutingConfiguration cmdlet should show the following:


Reviewing the Trusted application servers in the topology builder should show the following highlighted in red:


Hope this helps anyone looking for information for configuring multiple Lync sites for disaster recovery with Avaya RCC integration.

In addition to the cmdlets I provided above, I’m also going to paste the ones I used to remove the production and DR static routes and trusted application pools because I found them extremely handy if you realize you’ve made a typo or need to quickly remove the configuration.

--------------Remove RCC AES Configuration-------------------------

Remove-CsStaticRoutingConfiguration -identity service:Registrar:svrlyncstd02.domain.internal

Remove-CsTrustedApplicationPool -identity aes.domain.internal



--------------Remove RCC AESDR Configuration-------------------------

Remove-CsStaticRoutingConfiguration -identity service:Registrar:svrlyncstd03.domain.internal

Remove-CsTrustedApplicationPool -identity aesdr.domain.internal


1 comment:

UCSIP said...

as always your posts are time sensitive and well thought out. Thank you sir!
I'm not a Robot