Wednesday, December 15, 2010

Troubleshooting duplicate URIs in OCS 2007 R2

I was asked by a friend recently about how I typically troubleshoot duplicate URIs for users who are enabled for Enterprise Voice in OCS 2007 R2 and I was surprised I never thought about writing a post for this since I’ve ran into this issue plenty of times for environments that I don’t manage but would perform configuration changes every few months.


You’re trying to enable someone for enterprise voice so you navigate to the user’s properties in Office Communications Server 2007 R2 administration console:


You file in the URI for the user:


However, once you try to apply the settings, you get the following error:

A duplicate Remote Call Control device URI already exists. Please specify a different URI.




So what would I do at this point? The first thought I had was: “Well, you could open up every user’s account and figure out who’s using the same URI” but that would be prone to errors and extremely painful if you have thousands of users.

What I typically use to troubleshoot problems such as these is Enterprise Voice Route Helper that is bundled with the Office Communications Server 2007 Resource Kit and the following are the steps I take:

Open up Enterprise Voice Route Helper and navigate to Ad-hoc Test –> Manual and then fill in the Dialed Number field with the URI that you’re having conflicts with (in this example, it’s 370):


Various results can be presented when you hit the Test button and for this blog post, I’ll list 2 of them:

Result #1

You get a specific match immediately and know which user is assigned the URI:


Result #2

You end up hitting a translation rule that does something with this match (in this case it’s forwarding the call to a gateway):


In situations such as these, further troubleshooting will be required because this translation rule you’re hitting is providing a match before OCS matches a user with the assigned URI. What I would do next is to locate this rule in the location profile and modify it:


For the purpose of this example, I simply added another “6” to the Phone pattern regular expression so that 306 will no longer match this rule.

Note: This will obviously affect your environment and may end up breaking certain calls to a user so this is recommended to be done after hours.


Now go back to Enterprise Voice Route Helper and reload the location profile:


Rerun the test and since you no longer have a rule that handles URI tel:+306, you will now see which user has the URI assigned:


There are probably other ways of troubleshooting this but I have found this to work for me most of the times I have had to troubleshoot such a problem.

1 comment:

Anonymous said...

Or you could use powershell to query AD for you.

Get-QADUser -SearchAttributes @{'msRTCSIP-Line'="tel:;phone-context=dialstring"}