Adding more nodes or locations to an existing on-premises Skype for Business deployment

This section explains the steps involved if you need to add additional Conferencing Nodes, or new Skype for Business / Lync* servers and Conferencing Nodes in a new geographic location, to an existing on-premises SfB/Lync environment. It also describes a manual pool failover process.

* Note that where this documentation refers to "SfB/Lync", it represents both Microsoft Skype for Business and Lync unless stated otherwise.

Adding a new Conferencing Node to an existing location

Within Pexip Infinity

Using the names of the example environment described in this guide, you need to:

  • Assign a hostname to the Conferencing Node, e.g. in the format and configure its SIP TLS FQDN setting to reflect its DNS FQDN.
  • Assign DNS A records for this Conferencing Node:

    • A standard DNS A record, registered as its hostname e.g.
    • Add a DNS A record to the pool domain so that SfB/Lync will also load balance over this new node.

    For example (change the hostnames and IP addresses as appropriate for your actual deployment):         86400 IN A    86400 IN A
  • Generate a new single certificate for all of the Conferencing Nodes in the application pool. This new certificate should contain the same name information as the existing certificate, with the addition of the FQDN of the new node as another SAN (Subject Alternative Name).

    The new certificate must be uploaded to all of the Conferencing Nodes in the application pool.

    For example, before adding the new node, the certificate name information in our example would be:

    commonName =
    altNames =,,,

    The name information in the new certificate would be (assuming the new hostname is

    commonName =
    altNames =,,,,

Within SfB/Lync

You need to add the identity of the new Conferencing Node to the existing Trusted Application Pool (, in our example):

New-CsTrustedApplicationComputer -Identity -Pool

and then enable topology:


Adding new Front End Pools (FEPs), locations and Conferencing Nodes

If you have SfB/Lync servers and Conferencing Nodes in other geographic locations, then you should apply the same configuration model for these other locations as described for the Europe location configuration.

For example, if you had the following devices located in the USA (in addition to the existing Europe-located devices, as shown in the diagram, right):

  • 2 SfB/Lync Front End Servers fe03 and fe04 in a pool
  • 2 Conferencing Nodes conf06 and conf07 in System location US and to be placed in an application pool

Within Pexip Infinity

  1. Generate and assign a server certificate to the US Conferencing Nodes:

    commonName =
    altNames =,,

  2. Configure the US system location to use:

    • the Front End Pool
    • DNS servers on the inside of the network
    • a STUN/TURN server, if required.
  3. Configure DNS records for the US Conferencing Nodes:

    • A-records for each Conferencing Node conf06 and conf07
    • another A-record per Conferencing Node with the host name (the application pool name of the Conferencing Nodes).

    For example:         86400 IN A         86400 IN A    86400 IN A    86400 IN A
  4. Configure the SIP TLS FQDN setting for each US Conferencing Node to reflect its DNS FQDN e.g. and

Within SfB/Lync

  1. Create a trusted application pool for the US Conferencing Nodes.

    This command adds a trusted application pool for the Front End Pool and adds the first node ( as a computer in the application pool:

    New-CsTrustedApplicationPool -Identity -ComputerFqdn -Registrar -Site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true

  2. Add the other Conferencing Nodes in that location to the trusted application pool.

    This command adds conf07 to the new trusted application pool:

    New-CsTrustedApplicationComputer -Identity -Pool

  3. Create a trusted application for the pool of Conferencing Nodes.

    This command creates a trusted application for the pool:

    New-CsTrustedApplication -Applicationid confpool-us -TrustedApplicationPoolFqdn -Port 5061

  4. Create a static SIP domain route and associate it with the trusted application.

    This example creates a static route from the US Front End Pool ( to the nodes for the domain

    $newroute = New-CsStaticRoute -TLSRoute -Destination "" -Port 5061 -MatchUri "" -UseDefaultCertificate $true

    Set-CsStaticRoutingConfiguration -Identity "" -Route @{Add=$newroute}

    Note that if there is no existing routing configuration for this registrar, this can be created via:

    New-CsStaticRoutingConfiguration -Identity ""

  5. Enable the new topology using the following command:


Pool failover (manual)

If a SfB/Lync Front End Pool becomes unavailable, you may need to reconfigure your Pexip Infinity system to use a different SfB/Lync pool/server.

To fail over to a secondary SfB/Lync pool/server within Pexip Infinity:

  1. Ensure that the address of the alternative SfB/Lync Front End Pool is configured (Call Control > Lync / Skype for Business servers).
  2. Assign the alternative SfB/Lync pool to the affected Pexip Infinity system locations: go to Platform > Locations and change the Lync / Skype for Business server in use for the relevant locations.
  3. Assign the alternative SfB/Lync pool to any Call Routing Rules and Virtual Receptions that place calls to SfB/Lync from the affected locations: go to Service configuration > Call routing or Virtual Receptions and change the nominated Lync / Skype for Business server for the relevant rules / Virtual Receptions.

Putting a Conferencing Node into maintenance mode

If a Conferencing Node in a trusted application pool is placed into maintenance mode, and a SfB/Lync server sends a call to that node, the node will respond with 503 Service Unavailable and the call will then fail (SfB/Lync will not try another node in the pool).

Therefore, if you need to place a Conferencing Node into maintenance mode, we recommend that you wait until all SfB/Lync calls on that node have completed, and then you should temporarily remove the node from the trusted application pool and then place it into maintenance mode. The node should then be returned to the trusted application pool after it has been taken back out of maintenance mode.