Find it...

    Redundant Pexip - Lync integration


    Enterprises seek to build redundant and robust infrastructure for their communication and integration infrastructure. This page will describe the steps taken to set up a redundant integration between Lync and Pexip Infinity.

    Since Pexip Infinity is a truly distributed platform, it does not matter where messages arrive in a Pexip cluster, as the cluster will always ensure that the right Pexip nodes get the message, or the media for the conference.

    In our example (see diagram) we will use a setup with two Lync FEP servers in a pool, as well as three Pexip Conferencing nodes, that we will set up in an application pool and integrate with Lync. This guide covers the specifics of one location - large enterprises with multiple Lync locations would simply apply the same configuration for the other locations towards their local Pexip Conferencing nodes.

    The Lync Pool ( should integrate with the Pexip cluster / application pool (
    Our respective pools will be:

    For Lync users: containing
    (The Lync pool is assumed to be working so this guide does not cover how to install Lync in general.)

    For Pexip Conferencing nodes: containing

    Pexip configuration
    As long as the Conferencing nodes are all deployed in the same location, all clustering is already pre-configured, so no changes is needed to build a cluster in Pexip.

    On the management node, in Platform Configuration > Lync servers, add a new Lync server and give it a descriptive name.

    Add the Lync pool name, as address.



    Take the following steps in DNS:

    - Add one DNS A record for each Conference node, eu-px01, eu-px02, eu-px03 so they point to their individual IP-address.

    - Add three DNS A records for, with the IP-addresses of all three Conferencing nodes above to allow Lync to spread the traffic.

    - Ensure Pexip is configured to use DNS servers on the inside of the network, so Pexip can resolve internal hostnames. This is mandatory for communicating with Lync on-prem. If you forget this step, calls might drop after a few minutes when Pexip verifies that the remote side is still responding properly as an external DNS server cannot resolve the internal hostname of the Lync FEPs.


    The 'SIP TLS FQDN' setting for each conferencing node should be configured to match the DNS FQDN of each node, by clicking on the invidividual conferencing nodes in Platform Configuration > Conferencing Nodes on the management node.

    Ensure that each node is configured with its respective hostname, etc since Pexip will present this as being the server name - and it must match the name on the certificate.

    Lync MSSIP Domain

    The Lync MSSIP domain setting is used for determining which SIP domain Pexip presents to Lync when placing outbound calls. This domain needs to match the domain used as the MatchURI in step 4 of the Lync configuration further down in this guide, in this example Lync MSSIP domain is configured in Platform Configuration > Global Settings.


    All conference nodes need a SAN certificate containing both the DNS FQDN of the actual node ( and the application pool FQDN (

    For this certificate, the common name should be the FQDN of the individual node, while the two SAN entries should be the FQDN of the individual node as well as the application pool FQDN.

    For information on how to create certificates with multiple alternate names, see this article on Certificate creation with  multiple alternate names.

    In this example, using the certificate creation howto above, the commonName and altNames sections would be configured as:

    - commonName =
    - altNames =,

    - commonName = 
    - altNames =,

    - commonName = 
    - altNames =,


    Create a pair of a CSR (Certificate sign request) and a private key, and send the CSR to your Certificate administrator (Windows/AD administrator) for signing of the certificate.

    Since this is communication with Lync FEP servers, this certificate can be signed by the internal CA, and exported as Base64-encoded PEM format.

    You must generate one certificate pr conferencing node, where each certificate has the conferencing node hostname as both common name, and the first alternate name as stated in the example above.

    When the .crt files with the three certificates are received back from the certificate administrator, they must be uploaded to the Pexip Conferencing nodes by logging in to the Management node > Platform Configuration > TLS certificates.

    Take extra care when uploading certificates, to ensure you upload the correct combination of certificate and private key to each conferencing node. This might be complex to faultfinder later, so you will save a lot of time by doing this properly the first time.

    Intermediate Certificate

    From your Certificate administrator you can also get the Intermediate Certificate, and the root certificate for the organization. If you do not get it in a base64 PEM format, but in a .pfx format, you must run the following command to convert it.

    This can be done by copying the certificate to the Management node with SCP, and then SSH in to the Management node and issue the following command:

    openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes

    Where you obviously would change certificate.pfx with the name of your certificate, and certificate.cer with the filename of the certificate you want.

    If you open the certificate in a text editor, it should show:


    in the beginning of the file.

    If your certificates are issued by an intermediate, make sure to copy both the root certificate, and the intermediate certificate in to one file before uploading it to the Management node.

    It would typically look something like this:

    <certificate data with a lot of characters....>
    -----END CERTIFICATE-----
    <certificate data with a lot of characters....> 
    -----END CERTIFICATE-----

    When you have one file with intermediates and root certificate, upload it by clicking "Upload trusted root CA certificates" that you find at the bottom of the TLS certificates page.


    Lync Server configuration

    This guide will go step-by-step trough commands that needs to be issued on the Lync server to set up a redundant integration where Lync talks to Pexip as a pool of resources. We recommend to plan this properly and draw a diagram of the setup before getting started, to avoid confusion.

    1) Add trusted application pool for Lync to trust traffic coming from Pexip (and be able to send 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

    (The SiteId specified in '-Site 1' in the above example can be identified by running Get-CsSite from the Lync management shell)


    When creating a trusted application pool (and trusted application computer in the next step) like this, 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 Yes to all can be answered for this warning.

    2) Adding the remaining two nodes; eu-px02 and eu-px03 as computers to the newly added Trusted Application Pool since this is a load balanced setup with 3 Pexip Conference nodes:
    New-CsTrustedApplicationComputer -Identity -Pool
    New-CsTrustedApplicationComputer -Identity -Pool 
    3) Add a trusted application for the Pexip pool for
    New-CsTrustedApplication -Applicationid eu-px -TrustedApplicationPoolFqdn -Port 5061

    4) Define a static SIP route from Lync towards the Pexip pool with the domain or subdomain suffix that should be sent from Lync to Pexip and define it to register on the Lync Pool.

    Pexip supports both same domain, and subdomain or different domain integrations. In this example we will use a subdomain If the Lync environment consists of thousands of Lync users, consult a Pexip engineer to discuss the recommended design and dial plan.

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

    5) Set Static Route Configuration on the pool to use the route defined above on the Lync pool.

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

    (Note: If no existing routing configuration exists for this registrar, this can be created with New-CsStaticRoutingConfiguration -Identity

    6) Enable the topology and start calling!



    After the enablement is finished, wait a minute and try to call a Pexip VMR with a URI that matches i.e. and see if the Lync client can call in to the VMR.

    If it does not work, check the Pexip Administrator log, or the Support log to see if your call reaches Pexip.

    Additional nodes

    When adding additional nodes in the future, remember the following:

    - create a hostname, i.e.
    - get a certificate that has eu-pxNN.example com as its common name, and and as SAN alternate names and upload to the conference node.
    - get a DNS A record for this conference node registered
    - add a DNS A record to the pool domain, so Lync will also load balance over this new node.

    In Lync
    New-CsTrustedApplicationComputer -Identity -Pool


    Was this article helpful?
    2 out of 2 found this helpful