Polycom RPP Configuration for Lync

March 25, 2015 by · 15 Comments 

The core Polycom video bridging infrastructure components of the RealPresence Platform (RPP) have recently attained Lync Qualification.  As of the posting of this article the following RPP products qualified for Lync Server 2013 are:

This means that when the DMA and RMX are deployed together and integrated into a Lync 2013 environment then a host of different features and conferencing topologies are supported by both Polycom and Microsoft.  In this recent article the concepts of utilizing a third party MCU to either host all conference attendees or better yet leverage both MCUs by hosting attendees on both the standards-based MCU and the Lync A/V MCU together in a single, cascaded meeting.  This improved workflow, referred to as RealConnect, is discussed in this article by Adam Jacobs.

Regardless of the chosen conferencing scenarios the base integration between Lync Server and the RPP core components is the same.  The latest deployment guide can always be found at the bottom of the Polycom Microsoft partner support page which can be found using this simple URL: http://support.polycom.com/microsoft


The overall configuration guidance has remained largely unchanged since Lync 2010 was first released.  These third party solutions are integrated using the Trusted Application Pool methodology and the guidance in this previous article is still applicable, with the except of a few changes and improvements over time.

Trusted Application Pools

  • For most installations only one Trusted Application Pool for the entire topology is required.  This pool should be created as a multiple-computer pool so that both the DMA and RMX, as well as any additional DMAs or RMX is resilient deployments are all defined in this same pool.

  • Having a single pool means that only a single Trusted Application needs to be defined.

Note that it is important to understand the difference between single-computer and multiple-computer Trusted Application Pools.  Use of single-computer pool is not recommended as it requires some steps to be duplicated and adds unneeded complexity to an environment which never aids anyone when troubleshooting potential issues.  Utilizing a multiple-computer pool means that all of the Polycom RPP resources are contained in a single grouping and granted the same level of trust throughout the Lync topology


Also important to understand is the difference between the concepts above and having one or more unique Trusted Application Pools.  As mentioned above the default practice is to create one (1) multiple-computer Trusted Application Pool, meaning one pool is defined which contains multiple computer objects.

There is at least one scenario though where more than one Trusted Application Pool should be defined in the topology.  This would be in multiple Lync Pool deployments where (often geographically) separate Lync pools are paired with their own Edge pools.  In the event that there is more than a single Edge pool and also more than a single Polycom RPP deployment in the environment then it is recommended to use separate Trusted Application Pools for each set of RPP components.

In the following example this Lync topology includes two separate sites (East and West) which each contains their own Front End and Edge pools.


The reason for this configuration is that the RMX will utilize the Edge server or pool that is allocated to the Front End Pool that its Trusted Application Pool points.  So in the example above the RMX in the East site would leverage the Edge Server in that site, and the RMX in the West would us its local Edge Server.  If the topology only contains a single Polycom RPP deployment or a single Edge pool then this is not necessary.  Defining just one Trusted Application Pool will be sufficient for all Front End servers in all pools in any site in the entire topology to function correctly as Trusted Application Pools are topology-wide.

Static Routes

One of the steps that is still included in the official guidance covers how to define a static route to send SIP messages from Lync to the trusteed application.

In the new RealConnect workflow this is no longer necessary as all Lync participants will only ever connect to the Lync AVMCU in conference calls and then RMX will automatically connect into the same meeting running on that Lync AVMCU.  Hence there is no need to define a static route, nor a Matching URI in Lync.  If the traditional approach of landing Lync endpoints directly into the RMX is still required (both can be enabled in the same environment) then the static route would still be needed for those calls.

But for RealConnect-only workflows the static route is a thing of the past.

Legacy ICE Configuration Method

In past RMX releases the method of enabling Lync Edge Server connectivity to leverage ICE/STUN/TURN media traversal support has been an optional step which requires only the creation of a basic Lync user account.  That configuration has been superseded by a newer approach which is now a requirement (even if there is no Edge Server in the environment) and uses a n improved design.

The original approach was to simply create a standard Lync-enabled user account and then supply that account’s SIP URI to the RMX (and not to SIP register the RMX directly to an Edge Server which has often been performed mistakenly).  For older versions and comparison’s sake the legacy method is revisited in the following steps.  If using RMX 8.4 or a newer release then do not uses these steps; skip directly to the next section.

  • Create a new AD user account and then enable it in Lync.  the AD account’s username and password fields are irrelevant so they can be anything within company policies.

  • Create a simple, meaningful SIP URI in the same SIP domain name space as what was already defined in the RMX configuration. (e.g rmxice@mslync.net).


  • Go to the SIP Advanced section on the RMX under the Default IP Network Service properties and select MS from the ICE Environment drop-down menu.  Then enter the name portion of the SIP URI (e.g. rmxice) into the Server User Name field.


  • Go to the SIP Servers section on the RMX under the Default IP Network Services properties and verify that the Server Domain Name field is using the same SIP domain as the Lync account above.


If the SIP domains do not match then it is required to change the Lync account’s SIP URI suffix to the same SIP domain that is already defined on the RMX.  This issue would only be applicable for Lync deployments with more than a single SIP domain defined.

New ICE Configuration Method

The ICE support configuration has now changed to utilize a Trusted Application Endpoint instead of a standard Lync user as shown above.  Also the Service Globally Routable User Agent (GRUU) for the Trusted Application Pool containing the RMX is leveraged, meaning that the new ICE configuration is a two-part setup.

  • In RMX 8.3 or earlier releases only the legacy methodology must be utilized.
  • In the RMX 8.4 release either method can be used s both are supported.
  • In RMX 8.5 and newer only the new method is supported and the legacy method can no longer be used.

Understand that the supportability statements above mean that the existing ICE configuration in a current deployment would need to be modified if the RMX is upgraded to 8.5 or newer.  Also be aware that the ICE configuration is no longer optional.  For the rare Lync deployments which do not contain a functional Edge Server in the deployment this ICE configuration is still required.  The Lync Front End pool will actually support some of the required capabilities when an Edge Server does not exist.

Lync Configuration

Whether the Trusted Application Pool and Trusted Application objects already exist from a previous integration or need to be created for a new integration a third object needs to be created: the Trusted Application Endpoint.  For new configurations simply follow the official deployment guide referenced at the beginning of this article.  If updating an existing configuration use the following cmdlets to determine the desired target application pool to attach the new ednpoint object to.

  • Using the Lync Server Management Shell issue the following Get-CsTrustedApplicationPool cmdlet to identify the required attributes.

Get-CsTrustedApplication | Select-Object identity,ApplicationId | ft


Identify the correct Trusted Application Pool and record the FQDN (video.schertz.name) and the Application ID (video).

  • Issue the New-CsTrustedApplicationEndpoint cmdlet to create a new endpoint object in the desired existing pool.  The TrustedApplicationPoolFqdn and ApplicationId parameters must match the values resolved in the previous step.  The SipAddress parameter defines a SIP URI for this new endpoint object and must be a unique value that is not already in use by another Lync user, contact, or service.  Anything unique can be used and in this example a SIP URI of ‘rpp@mslync.net’ is chosen.

New-CsTrustedApplicationEndpoint -TrustedApplicationPoolFqdn video.schertz.name
-ApplicationId video -SipAddress sip:rpp@mslync.net

The TrustedApplicationPoolFqdn and ApplicationId parameters must match the values resolved in the previous step.  The SipAddress parameter defines the SIP address for this endpoint object and must be a unique value that is not already in use by another Lync user, contact, or service.

  • Make sure to issue the Enable-CsTopology cmdlet to comment this change to the Lync Topology.


Before leaving the management shell there is one more step to complete.  The target Trusted Application Pool will contain a parameter called the Service GRUU (Global Routable User-Agent URI) which needs to be set in the RMX and DMA. This Service GRUU is not something which can be manually defined in the topology; it is a value that Lync automatically defines when a Trusted Application is added to the topology.

  • Run the following Get-CsTrustedApplication cmdlet to retrieve the Service GRUUs defined in Lync.  Highlight the entire parameter and copy it to the clipboard or save to a text file for later use.

Get-CsTrustedApplication | fl ServiceGruu


Polycom Configuration

Any RPCS/RMX instances deployed in the environment can be updated using the following configuration for ICE support within Lync.

  • Go to the SIP Advanced section on the RMX under the Default IP Network Service properties and select MS from the ICE Environment drop-down menu.  Enter or change the value to use the name portion of the new Trusted Application Endpoint’s SIP URI (e.g. rpp) into the Server User Name field.


  • Go to the SIP Servers section on the RMX under the Default IP Network Services properties and verify that the Server Domain Name field is using the same SIP domain as the Lync account above. This should not need to be changed as it should be in the same SIP domain as the previous ICE Lync account.


Save these changes but defer any reboot request in order to make one final change.

  • Navigate to the Setup > System Configuration > System Configuration menu and in the default MCMS_PARAMETERS_USER view select New Flag.

  • For the New Flag name enter SIP_CONTACT_OVERRIDE_STR and then paste in the Service GRUU value which was saved to the clipboard or a text file in the previous section.


It is important to note that in the RPCS/RMX the “sip:” prefix must be omitted from the Service GRUU value when entered into this system flag.

  • Save these changes and then reboot the system to enable the new configuration.

While the DMA does not actually interact with the Lync Edge Server directly for ICE support the Service GRUU is still utilized for other capabilities and should also be configured using the Service GRUU..

  • Using the DMA web management interface navigate to the Network > External SIP Peers menu.

  • Edit the desired Lync Front-End Pool peer object and then in the editor window switch to the Lync Integration tab.
  • Enable the checkbox for the CsTrustedApplication ServiceGruu setting and then paste the entire Service GRUU into this field. 


It is important to note that in the DMA the “sip:” prefix must be included from the Service GRUU value when entered into this system flag.

About Jeff Schertz
Site Administrator


15 Responses to “Polycom RPP Configuration for Lync”
  1. Marvin Franklin says:

    Mr. Schertz,
    I have a dumb question. If you already a front-end pool installed in Lync 2013. To install another FE pool for HA, do you update the existing certificate or create a new one with the new SAN names?

  2. James Frost says:

    Hi Jeff,

    Nice article. I’ve recently implemented RC at a customer site and think its a great solution for blended meetings in a Lync centric environment, particularly with the Polycom content sharing suite. With the ability to retain Lync scheduling and joining workflow a major advantage over the competitive software inter-ops out in the market.

    Any idea when the Group series endpoints will be upgraded so the calendaring feature recognises a RC enabled Lync meeting and cascades back to the DMA, instead of forcing everything onto the AVMCU as is the current predicament?

    Regards, James

  3. Freddi Guerrero says:

    HI Jeff, in the past it was stated in your 2011 article (in regards to setup with DMA): “there is no need to define the RMX within the Lync Server topology.”

    In this article are you stating we now need to define the RMX along with the DMA as a trusted application? I am asking because we have the DMA setup with Lync and signaling as taking place but I see the media being routed from the client directly to the RMX. This is causing issues as due to NAT (client on private and RMX on public IP) and I was hoping media would proxy through the Edge server but it is not. Will I need to setup the new “ICE configuration” shown above for this to work?

    • Jeff Schertz says:

      Disregard any conflicting guidance from older articles as the integration, and thus best practices have changed over time. For the past few years the guidance is that both DMA and RMX must be defined in Lync. The RMX needs this in order to support features like ICE, regardless of signaling and media paths.

  4. Le Roux says:

    Hi Jeff,

    Is there a document or blog release that can help with testing the Realconnect environment, I have followed everything properly with no errors indicated and Realconnect is not working. It seems that the Bridge can receive calls from Lync through the DMA Routing but when an AV/MCU Cascade is dialled from the RMX to the Lync server then nothing happens.

    Please advise?


  5. Matt says:

    We have deployed solution with 2 RMX’s, however, second RMX cannot register to Lync. Lync is stating about certificate, it is expecting a sertificate with different name than what the RMX real FQDN is. Other RMX registers just fine. Application endpoint URI’s are unique within the environment.
    Also calls to that RMX with failed registration works when calling within enterprise networks, but not from the outside.

    • Jeff Schertz says:

      Each RMX should be configured using the same procedure, with a unique FQDN for each’s Signaling IP address. You cannot use the same certificate on both RMXs, each one requires its own unique server certificate. The RMX that is not configured correctly will not be able to leverage the Edge Server, hence external call failure. I always recreate certificates from scratch in these scenarios and most of the time that resolves the issue. The most common mistakes are made during the certificate creation and installation process so that is worth revisiting.

  6. Tai Nguyen says:

    Hi Jeff,
    Can Skype for Business connect to Polycom RMX 2000? I know SFB publish new role is VIS, is this related for connection between SFB and Polycom like as Cisco?


    • Jeff Schertz says:

      VIS is not applicable for Polycom solutions as they have much more native capabilities than even VIS can provide. To support Skype for Business clients and servers you need to make sure your RMX is running at least 8.5.4 or 8.6 firmware.

  7. Cristian Hernandez says:

    Hi Jeff
    I tried to get the Get-CsTrustedApplication | fl ServiceGruu on S4B but it does not appear nothing when run the command. Is still configurable the command Gruu on polycom platform for the ICE configuration method with S4B?


  8. Aalwyn says:

    Hi Jeff,

    Have you ever came across an issue where a SFB clint dials into a VMR on the RMX but the call fails due to an error “video not accepted”?

    We recently upgraded from Lync 2013 to SFB and since then we are having this issue. When the RMX is on version we are able to get internal SFB clients working but the RMX does not pick up the Edge server. When we upgraded to , 8.5.10 and 8.5.11 the RMX picks up the Edge server but then both internal and external SFB calls to the RMX fails due to “video not accepted”. This issue has been sitting with polycom support now for almost 2 months but they still cant find a solution.


    • Jeff Schertz says:

      Normally that message indicates a media encryption mismatch. Make sure that that conferencing profile on the RMX (or DMA if deployed) is still set to use encryption when available. That being said your issue does sound more like a media relay/reflexive setup problem. I would check that the RMX configuration for ICE (via the ServiceGRUU) is still correct as well. It’s possible the upgrade could have lost or reverted some part of the configuration.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!