You are here: Integration > Microsoft Lync / Skype for Business > On-prem Lync/Skype server configuration

Lync / Skype for Business server configuration for an on-prem deployment

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

The Lync/SfB 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 Lync/SfB management shell

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

The command syntax described in the following section is based on the devices described in the example deployment for the on-prem Lync/SfB 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 Lync/SfB 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 Lync/SfB 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, Lync/SfB 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, eu-px02 and eu-px03 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 Lync Server 2013 Standard Edition (as opposed to Enterprise Edition) does not support adding trusted application computers to a trusted application pool. For Standard Edition Lync servers, a separate trusted application pool must be created for each Conferencing Node (in addition to the trusted application pool).

To add 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 eu-px -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 Lync/SfB, static SIP routes can either be associated with the global routing table, or with a specific Lync/SfB 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.

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 Lync/SfB environment, Lync/SfB will only send SIP requests which are not destined to actual Lync/SfB users for that domain towards the Conferencing Nodes.

Pexip Infinity supports both same domain, and subdomain or different domain integrations. If your Lync/SfB environment consists of thousands of Lync/SfB 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 Lync/SfB 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 Lync/SfB clients to and similar aliases within a few minutes. Lync/SfB 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 Lync/SfB 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