This blog article has been a long time in the making and has been virtually written (and subsequently unwritten) multiple times in my head.  Over time it appears the concepts are starting to become more widely understood, but then the same misunderstandings pop up again.  Thus this article has been reborn yet again and will take a step-back from the previous articles to address the entire concept of integrating video conferencing infrastructure solutions directly with Lync Server 2010.  This article is not intended to replace other documentation or serve as a detailed walkthrough of how to configure the integration.  It is meant as a companion reference designed to explain the concepts in greater detail as well as provide best practices born directly from field engagements and real-world usage.

On the surface dealing with the configuration of Lync and Trusted Applications seems complex and confusing, but once the moving pieces are understood and it is clear which parameters relate to each other, and which have absolutely no bearing on each other, only then does this seemingly mysterious topic seem fall into place.

The primary focus of this article is the Polycom RealPresence Platform which is a re-branding of the Polycom UC Intelligent Core suite of solutions including the RMX and DMA products.  The concepts in this article only address video conferencing MCU integration with Lync and will not discuss video endpoint (e.g. room system) integration.  Some of the same concepts also apply to other third-party vendor product integration with Lync, although those solutions require additional hardware not shown in the call-flow diagrams below and also do not support some of the advanced features that are highlighted.

Additionally there is some misleading (and at this point simply inaccurate) documentation floating around out on the Internet that also adds to confusion on exactly how all this should work.  The best source of integration documentation for the Polycom solutions is included in the Polycom Unified Communications Deployment Guide for Microsoft Environments document which is constantly updated as new features and functionality becomes available.  This article then goes one step further to more deeply explain the components used by this integration.

The Completed Puzzle

The following diagram outlines a number of concepts which are later described in detail so that the proverbial light bulb should go on. There are two different pool configurations shown side-by-side (Single versus Multiple Computer) as well as two different potential call flow paths depicted top-to-bottom (Registered VMR versus SIP URI Dialing).  Only one of these two types of pool configurations is required (although a multiple computer pool is recommended for Polycom integration) but this example shows both in the same environment to point out that multiple pools can coexist with different hosts and also to clearly demonstrate the configuration differences between each.

Before diving into all of the individual components and concepts depicted in the diagram each item has been briefly defined as a reference:

• Lync Endpoint – A native Lync client used to place a video calls to the various potential users and SIP addresses listed in the diagram.

• Front End Service – The Lync Server Front End service which handles the SIP signaling traffic and decides where to direct it to.

• Trusted Application Computer – The basic Lync Server topology object that defines an external application residing on a specific host which is to be trusted by Lync for secure communications.

• Trusted Application Pool – A Lync Server topology object that is configured as either a single or multiple computer pool.  A single computer pool functions as both a Computer and Pool object as the defined FQDN is the application’s hostname.  A multiple computer pool is simply a grouping of one or more Trusted Application Computer objects.

• Trusted Application – A Lync Server topology object that points to a Trusted Application Pool and defines the trust required to support secure communications between Lync and the external application.  All objects defined in that destination pool are inherently trusted.

• ApplicationID – A descriptive name used to identify the Trusted Application within the Lync Server topology.

• Static Route – A SIP routing configuration in the Lync Server topology used to locate an existing external trusted application host to accept request for users in a specific SIP namespace.

• Destination – The hostname of the external application defined in a static route where requests to a matching SIP URI are routed to by the Lync Server.

• MatchURI – An arbitrary namespace defined in the Static Route which users enter as part of a complete SIP URI to connect to resources on the external application hosts.

Understanding the Pieces

Prior to configuring the Lync Topology there are two prerequisite steps which must be addressed so that Lync will be able to resolve the selected hostname of the external application as well as establish a secure TLS connection utilizing standard X.509 certificates.

Application Hosts

Before Lync can be configured to trust an external application it must first be able to communicate with it at a network level.  The hosts running these applications are traditionally other Windows domain Member Servers and thus would already be defined in Active Directory and DNS.  Since video conferencing equipment is often not integrated with Active Directory and is often managed by a separate team then the first step is to configure basic name resolution.

• Identify the SIP signaling interface on the RMX or DMA as that is the only IP address that Lync will connect to for signaling traffic for each host.  Any other addresses for management or media interfaces do not need to be defined anywhere in Active Directory or Lync.

• Once the proper IP address is known then a DNS Host (A) record must be created for each host using a unique Fully Qualified Domain Name (FQDN).  The multiple hosts (e.g. rmx.schertz.local, dma.schertz.local, etc) in this example are all defined in the same domain namespace as the Lync Server: lync.schertz.local.

Note: The FQDN selected to identify the application host is completely irrelevant in terms of how Lync users place calls.  The only requirement of this FQDN is that it is also used as the Common Name parameter for the requested SSL certificate that is installed on the external host.  This also means that the FQDN does not need to, and typically does not match the MatchURI parameter.  It is a best practice to use the AD namespace as the Lync server to define the application host records.

There is no technical reason that the host FQDNs could not instead be defined as rmx.mslync.net or dma.mslync.net, but it is best practice to define the hosts using the same AD namespace as the Windows servers are using, this simplifies the configuration and keeps the concepts separate.  In smaller environments where both the AD namespace and the primary SIP domain are identical then all defined parameters will use the same namespaces.

Certificates

In order to support TLS communications between Lync and each of the hosts defined as Trusted Application Computers a standard SSL certificate needs to be requested against a trusted Certificate Authority (internal Enterprise or public third-party) and imported into each host. The Common Name portion of the certificate’s Subject Name field must match exactly the previous defined DNS Host record for the individual host.  This name has nothing to do with the SIP address namespace that Lync users will place video calls too.

• The CN parameter of the certificate Subject Name field is shown below for two of the four hosts in this scenario.

Trusted Application Pool

The way to define a trusted host in Office Communications Server was pretty straightforward; there was one place to define either an IP or FQDN depending on if TCP or TLS was required.  But with the introduction of the Trusted Application concept in Lync 2010 there are now a number of objects which need to be defined in Lync to build the entire trust relationship.

The primary building block in this concept is a Trusted Application Pool, which must be defined first.  The diagram depicts both a Single Computer Pool (the orange pool object on the left side) and a Multiple Computer Pool (the blue pool object on the right side).  Either the Lync Server Topology Builder or the Lync Server Management Shell can be used to define either type of pool and then publish the changes to the Lync topology.

• When creating a Single Computer Pool both the pool name and the server name share the same parameter and the value should be the FQDN of the server hosting the third-party application to be trusted.  The examples below demonstrate how a single computer pool in the example can be defined in Lync Server using either tool.

New-CsTrustedApplicationPool -Identity rmx.schertz.local -Registrar Registrar:lync.schertz.local -Site Chicago -RequiresReplication $false

• But single computer pools are not typically used for video integration as a Multiple Computer Pool is the recommended configuration.  This allows additional application hosts to be added to the same pool, simplifying the overall setup and design.  The PowerShell example below demonstrates how the multiple computer pool in the example was defined in Lync Server.

New-CsTrustedApplicationPool -Identity video.schertz.local -Registrar Registrar:lync.schertz.local -Site Chicago –ComputerFqdn dma.schertz.local

Note: The example pool name above is completely irrelevant in terms of what namespace will be used to route calls to the video hosts.  The descriptive name of video.schertz.local was used but it could just as easily be defined as polycom.schertz.local or foo.anything.org.  It is only an identifier for the topology object and offers no functional purpose.  Even the SIP domain itself can be used as the Pool FQDN as Lync does not prevent this configuration and it works fine.

Although this scenario uses different values for the Pool FQDN and the MatchURI there is no requirement that those values match or not. For demonstration purposes unique values have been used to clarify this concept, but in practice it is common to set the Pool FQDN to the same value as the MatchURI for simplicity’s sake and also to make it easy for any administrator to identify at a glance which pool a specific route might be associated with.

Trusted Application Computer

• To then create the additional hosts as a Trusted Application Computer in an existing multiple computer pool the following cmdlet can be used for each host, or Topology Builder can instead be used to configure the pool. These entries must match exactly the selected FQDNs for each host which were defined in DNS.

New-CsTrustedApplicationComputer -Identity rmx1.schertz.local -Pool video.schertz.local

By default when a new Trusted Application Pool is created Lync will enable the pool for replication of configuration database information.  As only other Lync Server roles typically participate in this data replication process then it is recommended to disable this replication when defining pools for video conferencing hosts.

• Either use the Lync Topology Builder to uncheck the Disable replication of configuration data in this pool setting or use the Management Shell set the -RequiresReplication parameter to $false.

Set-CsTrustedApplicationPool -RequiresReplication $false -Identity TrustedApplicationPool:video.schertz.local

Trusted Application

Now that the pools are defined Lync must be configured to actually trust these application hosts by creating a new Trusted Application.  It is a common mistake to omit this step and just publish the Lync topology, but Lync does not automatically trust a defined pool.  The new Trusted Application cannot be created using the Lync Topology Builder tool, only PowerShell can be used.

• The following cmdlets show how each trusted application pool would be linked to each pool, with a unique application ID for each object.

New-CsTrustedApplication –ApplicationId BetaVideo -TrustedApplicationPoolFqdn rmx.schertz.local -Port 5061

New-CsTrustedApplication –ApplicationId ProductionVideo -TrustedApplicationPoolFqdn video.schertz.local -Port 5061

The specified Port is what Lync attempts to connect to the remote application host over, this parameter is not defining any type of listening port for the application on the Lync Servers themselves.  It is a destination port on the external application host’s signaling interface, not a source port on any Lync Server.  Lync Server already listens for incoming SIP traffic over 5061 by default from clients, other Lync servers, and trusted applications.

Note: The Application ID value does not need to match anything else in the configuration.  It is often thought that either the Pool name or the Application ID need to match the MatchURI or the SSL certificate Common Name, but these are all untrue.  Neither the Application ID nor the Trusted Application Pool FQDN bare any relevance to the actual SIP addresses used to route calls to the external hosts.  This value is just an identifier for the topology object.

Whether Topology Builder and/or the Management Shell are used to configure the various Trusted Application settings they must first be published to the topology before Lync can use them.

• Either select Action > Topology > Publish… from Topology Builder or run Enable-CsTopology from the Management Shell.

Static Routes

Just as with creating the Trusted Application, configuring static routes also can only be performed using PowerShell.  Mike Stacy has documented the processes for creating or deleting static routes in Lync and these articles should be referenced for additional details and examples.

To create new static routes in Lync Server the management shell must be used.  Only a single route is required, but multiple routes, using unique MatchURI values can be pointed to either the same Trusted Application or unique Trusted Applications.  This flexibility supports deployments from a single host and single domain to multiple hosts with a large number of unique SIP domains.

• The routes for this article’s scenario are created using two sets of cmdlets.  The first cmdlet in the each set defines the new static route and saves the results to a variable ($route).  The second cmdlet recalls that variable and adds it to the multi-valued route parameter.  Each set defines a unique route, one for each of the Trusted Applications in the example scenario.

$route = New-CsStaticRoute -TLSRoute -destination “rmx.schertz.local” -port 5061 -matchuri “beta.mslync.net” -usedefaultcertificate $true

Set-CsStaticRoutingConfiguration -identity global -route @{Add=$route}

$route = New-CsStaticRoute -TLSRoute -destination “dma.schertz.local” -port 5061 -matchuri “mslync.net” -usedefaultcertificate $true

Set-CsStaticRoutingConfiguration -identity global -route @{Add=$route}

• As static routes are not part of the actual topology (and not manageable in Topology Builder) then there is no need to run the Enable-CsTopology cmdlet after running the cmdlets above.  The changes will be committed immediately and depending on the size of the deployment and replication intervals then it may take several minutes before Lync clients are able to use them.

By defining a new, unique MatchURI value and pointing each route to the associated Trusted Application Computer FQDN then Lync clients will be able to route calls to either application using the appropriate MatchURI value in the dialed SIP URI.

• Looking at the static route cmdlets above it is clear that the Destination parameter matches the FQDN of the defined Trusted Application Computer for the external host, not the Trusted Application Pool in multiple computer pool configuration.  (In a single computer pool the values are one in the same.).  This highlights the fact that the route simply points to the host, not to a Trusted Application.  There is no 1:1 relationship between a route and a pool as once the Trusted Application is defined in Lync then it can be used for any supported purpose as Lync ‘trusts’ this host and will securely communicate over the network to it.

• If during a call attempt the Lync Server fails to resolve the Destination FQDN against a defined DNS record then it will forward the request to an Edge Server to see if the FQDN is actually an external SIP domain via Federation.  But if no Edge Server is deployed in the environment then Lync will fail to locate the dialed SIP URI and will immediately fail the call with the result code of 0xc3e93d6a-SIPPROXY_E_CONNECTION_UNKNOWN_SERVER.

• Most examples of creating new routes utilize the default Route Collection but it is possible in Lync to define a new route collection using the New-CsStaticRoutingConfiguration cmdlet.  By setting the target identity to a Lync registrar like a Front End Pool or Director (e.g. service:registrar:lyncpool1.contoso.com) then separate route collections can be used to define different destinations.  This flexibility would beneficial when geographically dispersed Lync pools need to route traffic to separate trusted hosts which are local to each pool.

MatchURI

The MatchURI parameter as defined in the static route is often the most misunderstood component of the entire scenario.  This parameter’s sole purpose is to define which SIP requests will be routed to the external application. It is defined as the Matching URI Domain setting in Office Communications Server (OCS) or simply the MatchURI parameter in the Lync Server.

• The MatchURI value is completely independent of all other configured parameters and does not need to match anything else in the configuration.  Not the Application Pool name, not the Certificate Common Name, not anything.  It is another very common mistake to assume that this parameter must be set to the same value as anything defined in the Trusted Application settings.

• The value must be unique per route collection, but the same value can be used in multiple routes if they are defined in different collections (e.g. Global and Pool Registrars)

• The value can be set to the same string as an existing SIP domain in Lync.  In fact it is best practice to define the MatchURI as the same exact value as the primary or most commonly used SIP domain.  Since the large majority of users in the this scenario are configured with SIP URIs in the primary SIP domain namespace of mslync.net then the MatchURI is also defined the same.

Question: So how does Lync forward SIP traffic to the external host when the called SIP URI is using the same SIP domain as other regular Lync users?

Using the scenario in this article as an example a user would attempt a video call to 771005@mslync.net and because mslync.net is a defined SIP domain in Lync then the Front End server will parse the database to locate a Lync user account configured with this SIP URI.  But a Lync user with this address does not exist as this SIP URI is simply a dynamic URI typed in to the Lync client by a user (or an Active Directory contact, or personal contact).  Since Lync cannot locate a SIP-enabled user in the database with that address then it will fall back to the static routing configuration to see if there is anything else it can do to complete the call.  Since a static route is defined with a MatchURI in the same namespace of mslync.net then Lync will forward the SIP invitation to the destination host in that route, which would be the signaling IP:Port of the DMA.

Note: When integrating with OCS 2007 there exists a limitation that the Matching URI Domain value cannot be the same as any currently defined SIP domain, so common practice was to use a unique value that appeared to look like a sub-domain of the SIP domain which was most commonly assigned to users.  For example a value of video.contoso.com would allow users accustomed to seeing contosto.com as their SIP domain to simply dial 1001@video.contoso.com to call the RMX.  This limitation does not exist in Lync Server, thus the shift in recommendation to use the same namespace.

• The primary benefits to using the same domain as the SIP domain are a simplified configuration allowing users to just append the desired virtual meeting room ID (e.g. 1001) to the SIP domain they are already accustomed to using, as well as the ability to leverage any existing Edge federation configuration.  This allows external users and federated contacts to call the same virtual meeting room using the same SIP URI as internal users. This functionality can be prevented via Lync External Access Policies if external access is undesirable.

Contacts

Since the static routing scenarios utilize a SIP URI then traditionally users would just type in the desired SIP address on-the-fly in their Lync client.  As the address does not resolve to any object within Active Directory and also does not match any external federated domain then Lync will display Presence Unknown.

• For example, to call a virtual meeting room defined on the DMA a Lync user would type “771005@mslync.net” in the client’s Search field.  Although presence is not shown audio and video calls can still be placed to this address.

But this requires a user to both know of and correctly type in the entire SIP URI to reach the target virtual meeting room.  To facilitate searching for these meeting rooms which are predefined on the DMA or RMX then Active Directory contacts objects can be utilized.  This is not a requirement as the SIP URI can always be dialed, but it may be beneficial to define in AD some of the more common virtual meeting rooms to make them easy to find for the end-users.

• Create a new Active Directory Contact and define a descriptive name (e.g. RMX Meeting Room 771005) for the object.

• Using the Attribute Editor manually set the msRTCSIP-PrimaryUserAddress attribute to the SIP URI that would be entered to dial the associated video meeting room (e.g. sip:771005@mslync.net).  The sip: prefix is mandatory on this attribute.

Now that Active Directory contains a contact with a populated SIP Address then the Lync Address Book service will include this object in the Lync Address Book, allowing Lync clients to simply search for the descriptive name instead of typing in the entire SIP URI.

• Force a manual update of the Lync Address Book as shown in this previous article.

• Once the updated address book files are downloaded by the Lync client then the user can type “rmx” in the client’s Search field and the new contact should be returned in the results. Note that there is still no presence information shown as this is not a SIP-enabled Lync user, just a contact stamped with a SIP address.

Virtual Meeting Room Registration

Although the Contact scenario simplifies searching and calling there still is no presence information available for the meeting room.  But this gap has been addressed by Polycom and the is covered in detail in the previous article RMX Virtual Meeting Registration in Lync.

By configuring this additional functionality Lync clients will have the ability to place calls to an RMX without using a defined route as calls will be directed to a registered endpoint (the RMX) which advertises presence for one or more Virtual Meeting Room (VMR) configured as actual Lync user accounts.  This calling scenario is no different than a native Lync to Lync peer video call, except that on the far-end is an RMX instead of another Lync client.

• • In the scenario diagram the different registered users (vmr1, vmr2, and vmr3) are all configured on a different RMX; each RMX can share the same SIP domain namespace, or each could be configured with accounts in different SIP domains.  There is no reason that rmx.schertz.local in the single computer pool could not be configured to register VMRs using the mslync.net SIP domain instead as there is no requirement that a static route MatchURI pointing to the same RMX must use the same SIP domain as the registered VMRs.
• VMR registration is a perfect example of how the Trusted Application functionality allows the RMX to register as an endpoint for individual Lync user accounts without requiring user account credentials or a static route.  As shown in this scenario both configurations are supported at the same time (with either unique or identical domain names) for a flexible overall solution.

Summary

Hopefully after reading through this article some (or all) of these concepts are now better understood.  The intent of this article was to serve as both a primer for anyone just setting foot on this journey through experienced administrators who may not have understood the ‘how and why’ behind the configuration.

If only one concept is to be taken from skimming through then let it be a clear understanding of that fact that the MatchURI does not have to be the same thing as the FQDN defined as the signaling destination for SIP traffic.  Sending video calls to 1001@rmx2000a.chicago.contosocorp.local is just silly when something much simpler and more familiar to users like 1001@contoso.com could instead be used .