« UC: A Perspective on Best Practices | Main | Logon Failure to xds database when installing the Local Configuration Store »



Feed You can follow this conversation by subscribing to the comment feed for this post.


Any way to do this in the GUI on Lync RC like there was in OCS?

Mike Stacy

Partially. You can create the trusted application pool a trusted application computer with topology builder but the static route must be created with the management console.

Mike Carman

Hi Mike and thanks so much for this information. Unfortunately this is making my head hurt  I have a merged R2 and Lync environment. In my R2 world we have a configuration supporting RCC with an Avaya AES. Both my R2 and Lync environments are comprised of dual FEs behind an F5 HLB. My Host Authorization and Static routed are configured as follows in R2:

Matching URI = Avayaaes.net.domain.com
Next Hop = Avayaaes.net.domain.com
Transport = TLS
Port = 4723

To add the static route to Lync I ran the following:

$route = New-CsStaticRoute -TLSRoute -destination "avayaaes.net.domain.com" -port 4723 -matchuri "avayaaes.net.domain.com" -usedefaultcertificate $true

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

Host Authorization
FQDN = AvayaAes.domain.com
Throttle as Server = True
Treat As Authenticated = True

This is where I get hung up. I create the Trusted Application Pool with the FQDN of the Host authorization as it is in R2, however the topology builder can’t find it in AD. Well it doesn’t exist in AD…… not sure what to do here. When running the NetStat I see the connection established to the correct port, yet my Lync Client is not recognizing the RCC enabled phone system.

Any and all help is very much appreciated.

Mike Carman

Hello again Mike. I created the trusted app server using power shell. The following are the errored results:

PS C:\Users\micarmx> New-CsTrustedApplicationPool -Identity avayaaesrsrv.domain.com -Registrar Registrar:lyncpool.domain.com -site 1 -ComputerFqdn avayaaesrsrv.domain.com -ThrottleAsServer $true -TreatAsAuthenticated $true
WARNING: Machine avayaaesrsrv.domain.com 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. If you
choose to publish this topology Enable-CsTopology will have to be re-run once the missing machines are domain-joined.

Missing Machine
The following machines from the topology you are publishing were 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. If you choose to publish this
topology Enable-CsTopology will have to be re-run once the missing machines are domain-joined:

[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
WARNING: The following changes must be made in order for the operation to be complete.
Enable-CsTopology must still be run for all changes to take effect.

Identity : 1-ExternalServer-6
Registrar : Registrar:lyncpool.domain.com
FileStore :
ThrottleAsServer : True
TreatAsAuthenticated : True
OutboundOnly : False
RequiresReplication : True
AudioPortStart :
AudioPortCount : 0
AppSharingPortStart :
AppSharingPortCount : 0
VideoPortStart :
VideoPortCount : 0
Applications : {}
DependentServiceList : {}
ServiceId : 1-ExternalServer-6
SiteId : Site:Americas
PoolFqdn : avayaaesrsrv.domain.com
Version : 5
Role : TrustedApplicationPool

Justin Morris

Thanks for the write up Mike. Was able to get RCC going with CUPS as a result, much appreciated.


Mike: in your example \ TLS static route you write:

-destination "rmx.domain.com"
and little bit later: -matchuri "video.domain.com"

Let me translate that into human text:

if Lync sees a SIP URI ending with "video.domain.com" (for example my RCC user LineserverURI is congifured as: "sip:randomstring@video.domain.com"), exactly this route will match and as a result it will route it to rmx.domain.com

Can both "rmx.domain.com" and "video.domain.com" be the same string, like both being "rmx.domain.com" ? If yes, can this cause infinite routing loops?

I am fighting with the same issue in Avaya AES RCC as Mike Carman, and I suspect Lync-side inconsistent configuration of static routes and application pool names, but cannot find out where and how.

Mike Stacy

That is correct. You can make them both the same - it will not cause any issues.


Good to hear that :)

I am thinking on the rmx side \ listening port: this TLS port 5061 is on the RCC gateway (RMX side), so it has nothing to do with the fact, that Lync is also using the same port number 5061?


One more thing is still bugging me:

you have chosen a "pool" as the type for trustedapplicationpool instead of the type "single computer" for trustedapplicationpool. As the result you could provide different pool and member server FQDN, and also you can expand the pool object to show the separate child object (screenshot)

Was that a requirement/recommendation of Polycom, or just here for demonstration purposes, how these application pools in Lync are represented?

Mike Stacy

Correct - it's the destination port. You will not have a conflict.

You can use either a single computer pool or a multiple computer pool. I always do a multiple computer pool because if I need to add other FQDNs (maybe to add redundancy) or swap from one to another (new hardware, etc.) it minimizes the amount of changes I have to make.



Would this be a way to integrate Lync with Tandberg?
our MCU domain name is same as SIP URI, so for ex, mcu-sip@domain.com and sign in name of Lync user is abc@domain.com. If I create static route of same domain, does it affect Lync users OR it will only send all the request to mcu if user dosen't exist in Lync?

Mike Stacy

I'm sure the Tandberg configuration uses the same basic aspects as the ones outlined here, which are based on Polycom integration. You can definitely create a route using the same name as your primary SIP domain.

Timo Schönfeld

Hi guys,

i did all what was postet in blogs, whitepapers, technet and so on. But my Lync allways routes the traffic for VCS-Domain to the edge server instead directly to the trusted server.

A Get-CsStaticRoutingConfiguration brings that:

Identity : Global
Route : {MatchUri=vcs.domain.com;MatchOnlyPhoneUri=False;Enabled=True;ReplaceHostInRequestUri=True}

The VSC is hosted in a foreign domain. I want to route all traffic to VCS via 5060. SIPServerTCPPort is set to 5060 by the way.

Any hints ?!
Identity : Service:Registrar:pool.mydoamin,com
Route : {}

Regards Timo

Mike Stacy


You need to create the trusted application pool and trusted application computer in Topology Builder. The trusted application computer FQDN must match the FQDN you entered in the "destination" attribute of the new-csstaticroute cmdlet that you ran.

Timo Schönfeld


CSStaticRoute is unable to process FQDN when using TCP instead of TLS, what makes no sense for me....

If the FQDN is needed for a "URI-Routing" the IP-Address in TCP-Destination is total useless, or ?

Reagrds Timo

Mike Stacy

Ok, I didn't realize that you were using TCP. I don't recommend TCP routes to my customers so I haven't used them very much but you still need the trusted computer and application pool but in your case the trusted computer will be an IP address rather than an fqdn.

Chan Andrew

Hello Mike,

I've bumped into this error
TL_WARN(TF_DIAG) [0]1024.1BC4::09/10/2010-03:10:17.510.0003ebae (SIPStack,SIPAdminLog::TraceDiagRecord:SIPAdminLog.cpp(145))$$begin_record
LogType: diagnostic
Severity: warning
Text: Non-trusted source sent an FQDN/IP that doesn't match a routing table rule
Result-Code: 0xc3e93c5e SIPPROXY_E_ROUTING
SIP-Start-Line: INVITE sip:1003@video.domain.com SIP/2.0
SIP-Call-ID: 2ee2c5825a1248e6b37f03d70f25732a
Data: user="1003@video.domain.com"

This is what you stated above and exactly there was a route created before I add a new front end pool

What should I do to fix this?

Please also refer to the post I asked here, thx


Jürgen Pfeiffer

Hi Mike,
this is an interesting post, especially considering the time when you wrote it.
I'm currently implementing a custom application on a UCMA server. Every time the application sends a SIP REGISTER on behalf of a user to the front end server, I can see exactly the error message you descibed in your article.
I configured a trusted application pool and a trusted application computer. The application is not routing for a different namespace or anything like that. It's just registering as some users and modifying settings for these users.
Do you have any idea why it's not accepting the traffic from the application server even though it should be a trusted computer?
Thanks a lot.

Jürgen Pfeiffer

Hi all,
we found the answer to the question I posted before:
Even though you only leverage the signalling portion of UCMA, there still needs to be a trusted application associated to the trusted application pool. Without the trusted application, Lync server basically does not trust a trusted application computer assigned to a trusted application pool.


Hi Mike,

i want to clarify something related to my video domain and lync domains.

i have a situation where video domain and lync domain is same..now i don't know how the lync will differentiate where to route this calls.

i have created the trsusted application on the lync side. from video gatekeeper i am able to route the calls to lync clients.

but i am not getting what should i do on lync..the domain for video and lync is same for e.g. abc.com

can i write a static route on lync for shared domain as well?? can it effect something on lync??how the lync will understand that it should check the static routes, i mean on what condition it will check the static routes? is there anything like priority exist in the lync, so that if it doesn't find the user it check the static routes!!


Mike Stacy

Alok - Lync always checks a SIP address to determine if the user has a Lync account prior to sending the call out the static route. Therefore you can have a static route which matches any of the SIP domains which Lync is hosting.


I have a further question about static routes, especially with regard to forwarding Lync to Lync calls via federation with a fall back to forwarding ALL other video call through a standards based SIP gateway.

We have a Cisco VCS environment which can be interrogated with Lync in this very fashion. The fact that register Lync users a queried first BEFORE the static route is great, but ideally we would want to ensure that all federated sites are also check before the static route is checked. It would be nice to ensure that ONLY video calls are forwarded via the VCS, as using the VCS for audio based calls could waste call licences.

1) Can a static route be set up to forward ALL unknown address via a trusted application (in a similar vein to a default gateway)
2) Will all other Lync possibilities be check before failing back to a static rule?
3) Is it possible to set up a stic rule to ONLY forward video based calls?

Mike Stacy

Swinster - As far as I know it is not possible to do what you are asking. This is why I try to use one of the same SIP domains as Lync for the route (company.com rather than video.company.com). The downside to this is that requests to unknown users in your company (people that have left, etc.) will be sent across the static route as there is no simple way to send only video calls across the route. You could deploy an MSPL script to filter requests that you don't want and INVITEs that don't contain video SDP but you'd have to be very careful with both the MSPL code and the use of such a script since it can negatively impact performance. If you were going to do this I'd recommend using a separate pool for the routing connection that does not contain users. Alternatively you could build a go-between UCMA app. This would be a much better architecture but would require more code expertise and might cause support issues with your video vendor.


Thanks Mike.

Indeed we are looking at the same SIP domain form all user within an organisation, however, I am more concerned with outbound calls to OTHER organisations outside of our control. This is quickly becoming a very common scenario.

Now, it maybe plausible that this "third party" organisation (lets call them otherlyncorg.com) utilises a Lync deployment, therefore the sensible way to go would be to set up a federation between my organisations Lync deployment and that of otherlyncorg.com, and so we have a native Lync-to-Lync call.

However, users in my organisation my want to call ANY other standard based SIP system/user direct from their Lync client. We can't possibly put static rules in place to cover all internet domains and so ideally would have to route ALL unknown domains (i.e those of users that that at not registered to Lync or that are not part of a Federated organisation), via the SIP gateway.

However, this could potentially overload the SIP Gateway itself which is designed for video calls not specifically voice calls. However, there should be a way out to the Internet in order that a standard DNS lookups can be made to place such a call to an unknown SIP destination (as is the case with our current videoconferencing infrastructure)

If this really isn't possible without custom code (which I fear is way beyond what I would be able to offer - I am entrenched in the video world with infrastructure from Tandberg/Cisco and this is my first foray into the Lync world), then the only possibility IS to add domain specific static rules as users request them - NOT pretty!. The Cisco VCS does offer a B2BUA, but there is not much scope in its configuration as well. My feeling should be that it would be down to Lync however, to simply not route a call that is not require by a particular app (i.e. stop voice calls place to an unknown SIP domain through the video trusted application.)

I take it that this would not be resolved in 2013?

As mentioned, I have not gone far with Lync as yet. How does Lync deal with calls to unknown SIP domains in general? I assume that it to would use DNS to look up to possibility of Lync based SIP systems via edge pools?

Mike Stacy

The only way to really deal with the situation you describe is to instruct users to dial a specific SIP URI format when calling non-Lync federated systems ( and use whatever VCS/B2BUA features you need to modify the dial string and be able to route that call. Of course the two main problems with this are 1) the user needs to know in advance if they are calling a Lync system or not and 2) Lync isn't very accommodating to various URI strings so if you needed to dial IP/FQDN@extension or IP/FQDN##extension you will hit problems.

Lync 2013 drops H.263 so whatever you call would need to be able to communicate over RTV or H264UC (Lync's SVC).

For ubiquitous connectivity a virtual meeting room strategy works best. I don't know if Cisco has a similar approach to Polycom in this regard but by meeting on the RMX it means the dial experience for your internal users is always the same and you can connect H.323, OCS/Lync 2010/Lync 2013, and non-Lync SIP platforms all together. You can also gateway calls and the like when necessary.

Outside of that you will probably need some fancy code to make this work seamlessly.

The comments to this entry are closed.

Important Information:
The views and opinions outlined within this blog are solely my own, and do not represent those of any organization. All technical procedures contained herein are provided without warranty of any kind. These procedures may or may not fall within the support guidelines of any company mentioned. If you have questions about the supportability of any information in this blog please contact the appropriate vendor.

Twitter Updates

    follow me on Twitter
    Blog powered by Typepad