Skype for Business server configuration for an on-premises deployment

This topic describes the commands that need to be issued on the SfB/Lync server to set up a redundant integration where the on-premises SfB/Lync environment talks to all Pexip Infinity Conferencing Nodes as a pool of resources.

The SfB/Lync server configuration consists of the following steps (each is described in full in the sections that follow):

  1. Creating a trusted application pool for the Conferencing Nodes.
  2. Adding the other Conferencing Nodes to the trusted application pool.
  3. Creating a trusted application for the pool of Conferencing Nodes.
  4. Creating a static SIP domain route and associating this route with a trusted application.
  5. Enabling the new topology.

Using the SfB/Lync management shell

The above operations are performed using the SfB/Lync Management shell, which is normally available on the SfB/Lync Front End Servers in the SfB/Lync server environment.

The command syntax described in the following section is based on the devices described in the example deployment for the on-prem SfB/Lync integration. Where applicable, you must replace these example parameters with parameters appropriate for your actual deployed environment.

Commands that are entered in the management shell are shown as follows:

this is the command to enter; parameters to be replaced for your actual deployment are emphasized

For a comprehensive overview of the SfB/Lync management shell commands used in this deployment guide, see Additional general application activation information can be found at

Creating a trusted application pool for the Conferencing Nodes

This command adds a trusted application pool for the Front End Pool to trust traffic coming from Pexip Infinity (and to be able to send traffic back), as well as adding the first node ( as a computer in the application pool.

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

Syntax explained

-Identity defines the DNS FQDN of the group of Conferencing Nodes that belong to this trusted application pool. In this example, it is, which must also be configured in DNS.

-ComputerFqdn defines the DNS FQDN of the first node in the trusted application pool.

-Registrar defines the FQDN of the Front End Pool to which this trusted application pool belongs.

-Site defines the Site ID to which this trusted application pool belongs. The SfB/Lync management shell command Get-CsSite can be used to retrieve the SiteID of a given Front End Pool.

-RequiresReplication defines whether replication is required for this application pool. In our case this is not required.

-ThrottleAsServer defines how connections to this trusted application are throttled. In our case we use the default value of True.

-TreatAsAuthenticated defines whether this trusted application pool is considered authenticated, or if authentication is required. Here, we use the default value of True, meaning that the server with this hostname/certificate is considered to be authenticated.

When creating a trusted application pool (and a trusted application computer in the next step) in this way, SfB/Lync will issue a warning stating:
"WARNING: Machine from the topology you are publishing was not found in Active Directory and will result in errors during Enable-CsTopology as it tries to prepare Active Directory entries for the topology machines."
This warning can be safely ignored as the Pexip nodes are not domain joined, and you should answer Yes to this warning.

Adding the other Conferencing Nodes to the trusted application pool

You must now add the remaining two nodes, conf02 and conf03 in our example, as computers to the newly added trusted application pool as this is a load-balanced setup with 3 Conferencing Nodes.

Note that when creating a trusted application pool that will contain multiple computers, you must add the first trusted application computer when you initially create the trusted application pool.

To add more trusted application computers to the trusted application pool:

New-CsTrustedApplicationComputer -Identity -Pool

New-CsTrustedApplicationComputer -Identity -Pool

Creating a trusted application for the pool of Conferencing Nodes

This command creates a trusted application for the pool of Conferencing Nodes:

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

Syntax explained

-ApplicationId is a friendly identifier for the trusted application.

-TrustedApplicationPoolFqdn defines which trusted application pool that this trusted application belongs to.

-Port defines which port the trusted application (the Conferencing Nodes) will be sending SIP traffic from. In our case this is 5061 (SIP TLS).

Creating a static SIP domain route and associating this route with a trusted application

In SfB/Lync, static SIP routes can either be associated with the global routing table, or with a specific SfB/Lync registrar or registrar pool. In our case, we want to have one static SIP route per location (i.e. per registrar), so that we can route SIP and media traffic from a Front End Pool to a pool of Conferencing Nodes.

If you currently use global static routes for other integrations, these will become inoperable if you were to add routes per registrar.

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

First, you need to check if there is any existing routing configuration for the registrar. To do this, run the command:


On a new system this may report only:

Identity : Global
Route : {}

or if there is existing routing configuration the output will contain additional routes, for example:

Identity : Global
Route : {}

Identity :
Route : {;MatchOnlyPhoneUri=False;Enabled=True;ReplaceHostInRequestUri=False...}

You need to check if the Identity in any of the routes matches your registrar. The example output above does have a match for our registrar (

If there is not an existing Identity that matches your registrar, then you need to use the following command to create a new static routing configuration for your registrar:

New-CsStaticRoutingConfiguration -Identity ""

Now you can apply your required static route to your registrars' static routing configuration by using the following commands:

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

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

If static routes for additional domains are required, this can be achieved by re-running the 2 commands above, substituting the ‑MatchUri parameter with the desired domain name. If the specified domain is the primary SIP domain used for this SfB/Lync environment, SfB/Lync will only send SIP requests which are not destined to actual SfB/Lync users for that domain towards the Conferencing Nodes.

Pexip Infinity supports both same domain, and subdomain or different domain integrations. If your SfB/Lync environment consists of thousands of SfB/Lync users, consult your Pexip support representative to discuss the recommended design and dial plan.

Syntax explained

Get-CsStaticRoutingConfiguration returns information about the current static routing configuration.

New-CsStaticRoutingConfiguration creates a new static routing configuration for a given registrar (unless it already exists).

-Identity defines the registrar for which we want to create this new static routing configuration.

$route defines a variable to hold the static route object that we are creating.

-TLSRoute defines that the route we are creating will use SIP TLS for signaling transport.

-Destination defines the DNS FQDN where SfB/Lync should send SIP requests matching the domain specified in -MatchURI.

-Port defines the TCP port to which the SIP requests should be sent, in our case 5061 for SIP TLS.

-MatchUri defines the SIP domain to statically route towards the Conferencing Nodes.

-UseDefaultCertificate $true defines that the route uses the default certificate for authentication purposes.

Set-CsStaticRoutingConfiguration applies a given static route object to a static routing configuration.

-Identity defines the registrar on which we want to apply the static route object. In our case this is the Europe Front End Pool.

-Route @{Add=$route} defines the static route object that we want to apply. Note that the variable name, in our case $route, is case sensitive.

Enabling the new topology

The new topology can now be enabled using the following command:


After this command has been run, it should be possible to place calls from SfB/Lync clients to and similar aliases within a few minutes. SfB/Lync clients which are already logged in may have to log out and back in again before being able to place calls towards the Pexip Infinity Conferencing Nodes.

If the calls fail, check the Pexip Administrator log, or the Support log to see if your call is reaching Pexip Infinity.

Reverting configuration

If you need to undo the changes to your SfB/Lync deployment that have been made by following this guide, you must:

  • Remove static SIP domain routes.
  • Remove trusted application pools. Removing the trusted application pool will automatically remove all trusted applications within that pool.
  • Re-enable the topology.

The commands below show how to achieve this using our example deployment.

Removing the static routing configuration

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

Set-CsStaticRoutingConfiguration –Identity "" –Route @{Remove=$route}

Removing the trusted application pools

Remove-CsTrustedApplicationPool –Identity ""

Re-enabling the topology