Thursday, April 30, 2009

Microsoft Communicator Phone Edition (Tanjay) and wildcard certficiate

I spent quite a bit of time troubleshooting the interaction of Tanjay to Exchange CAS server recently only to find out from Jens that wildcard certificates are not supported.

So, for those of you out there who have a wildcard certificate (* on your CAS server, you must re-issue it before implementing OCS/UM with Tanjay phones.

I typically use the following command when creating the request:

New-ExchangeCertificate -DomainName,, mbxserver1.domain.local -FriendlyName Exchange_CAS_SAN_Cert -GenerateRequest:$True -Keysize 1024 -path c:\exch-san.req -privatekeyExportable:$true

Having the "autodiscover" name in the SAN is also required for the Tanjay phone to connect to the CAS server. Don't forget to create an "A" record as well for these names.


Sunday, April 26, 2009

AudioCodes gateways and TDM to TDM routing...

I came across an interesting issue with a gateway (Mediant 1000) I was setting up for a client today. If you follow the quick installation guide for OCS you probably won't have this issue but if you've bypassed the guide and have forgotten to set up your SIP Proxy IP then read on.

The gateway we were setting up was going inline of the PBX and PRI. The previous configuration was:


The new configuration is:


If you don't set the SIP Proxy IP address then everything will work fine except TDM to TDM routing for outbound calls. It took 6 hours to figure this out and it didn't make sense but the call flow for Nortel to PSTN resulted in the call being sent to OCS always. Calls from OCS to PSTN worked fine. Also, more maddening was that PSTN to Nortel worked fine.

So, remember......the quick installation guides are still a good reference for you and can save you a LOT of time and frustration for those key settings you may forget to change.

I'm tired....

Saturday, April 25, 2009

Normalizing inbound calls and solving the "9" prefix dilemma

I don't believe it is actually written anywhere but I've found out recently that the location profile you specify on your mediation server is actually used for normalizing inbound calls. Seems straightforward but it isn't always clear what these options and settings are used for.

This post is designed to bring awareness to this process first of all but more importantly I talk about the dilemma of including normalization rules for "9" prefix calling.

First off, if you're performing digit manipulation in the gateway for inbound calls you're probably doing the work of OCS anyway. Remove any digit manipulation you have in the voice gateway (or equivalent, i.e. Call Manager).

You want to create a normalization rule and include the name of the mediation server in it so you can easily keep track of which location profile is for what server. For example, if your mediation server is called "abedmocsm01" then create a LP called "".

Include the most common rule for North America calling as follows:

^(\d{10})$ which translates to +1$1

Follow suit by adding rules for your DID's and non-DID ranges. If you have a main number with non-DID's behind it then it would look something like:

^5(\d{3})$ which translates to +17805551212;ext=5$1

Now that you have that sorted, you'll notice that you don't have a rule for something like:

^9780(\d{7})$ which translates to +1780$1

The above rule wouldn't apply since the PSTN (or PBX) would never send a 9, then digits. Using this "split Location Profile" type scenario allows you to get away with not having both of these rules:


I hope his is some value to those out there.



Friday, April 24, 2009

Communicator Phone Edition April 2009 Update

Quick post today......

There is an update to the Tanjay phone firmware (Communicator Phone Edition R2) for April which fixes a few things and adds new functionality:

-Users will now see their own phone number displayed on screen at all times. The number shown is the 'work' number (the number in the General tab of the user account properties in AD).

-If you called a user's alternate number, that number is now stored as the called number in the call log.



Thursday, April 23, 2009

Great tools for building .NET regular expressions

If you're like me and have trouble deciphering .NET regular expressions for tasks like creating normalization rules for OCS and the Address Book Service, look no further. I've included my favorite 'cheat' tools here for you to to evaluate.

RegexBuilder: The first one I'll start with is free and can be downloaded and run without an installation routine. It allows you to type or paste in your expression and test against it on the fly. This tool is great for performing simple validation of an existing string but you really need to know how to write one before you start with this tool. There are no 'helpers' to assist you with wondering the difference between "\d*" and "\d+", which by the way, I still don't know the difference. ;)

Expresso: This has to be my favorite tool thus far. It can be downloaded for free and by simply filling out their online registration form, they will send you a registration code. What I like about this product is that they give you examples and show you what each character means (even though \d* and \d+ are still not clear to me). The GUI interface allows testing of multiple strings and their translations so you could take a copy of your ABS normalization text file and paste it directly into the 'Test Mode' screen to verify your results.

It can be downloaded at:

RegexBuddy: If you have a few bucks lying around and want to give this application a spin, it certainly does the trick and more. This might be a good place to start for the beginner since the interface is much more helpful than the other two. At $39.95 USD it appears to be a pretty good deal however in the context of doing dial plans for OCS, I'm certain you can get what you need out of the other two combined.

That's all for today.



Sunday, April 5, 2009

OCS Address Book Service Normalization

Recently I was working at a customer site where we were trying to come up with a normalization string for numbers in their AD forest that could handle the varying array of number formatting. I find this to be a common issue for many organizations with multiple people typing phone numbers into user accounts.

Some examples of these are:

(780) 555-1212
1 (780) 555-1212

The address book service performs a nightly scan of Active Directory and attempts to build a database of users and phone numbers. If the normalization rules in the "Company_Phone_Number_Normalization_Rules.txt" file can't normalize the numbers you will get a list of them outlined in the "Invalid_AD_Phone_Numbers.txt".

NOTE: The information in the "Company_Phone_Number_Normalization_Rules.txt" file is incorrect (yes, still in R2). The txt file suggests you rename the file to "Company_Phone_Normalization_Rules.txt" (which is missing the word "Number"). If you follow these instructions in the txt file it won't work. Just remove the word "Sample_" from the file name and don't forget to uncheck it as a read-only file.

Now, back to the Address Book Service and AD number normalization...

The 'universal' normalization rule I use is as follows:



This above normalization rule will work for just about any North American phone number someone types in. To make this easy to decipher and modify I will also remove all the text from the default file and begin with this one rule.

To test a number:
  • Open a command prompt and navigate to C:\Program Files\Microsoft Office Communications Server 2007 R2\Server\Core.
  • Type in "abserver.exe -testPhoneNorm " and view the result
If you wish to force the Address Book Service to scour AD again, type in "abserver.exe -regenUR" and "abserver.exe -syncNow". Be sure to open Event Viewer between these two commands and look for an event suggesting the system was successful.

The bottom line is that all numbers in your AD environment should be formatted as e.164 numbers (+17805551212).


Use any IP phone with OCS?

Well if the folks at Evangelyze ( have their way, the SmartSIP product will allow support for generic SIP devices. This means you could potentially connect any IP phone (Cisco to MITEL) to OCS through this gateway style software.

From what I've been told, the IP device linkage isn't quite completed yet but stay tuned for more information as I test this software with OCS when it becomes ready.


Off to Exchange 14 Ignite!

Well I'm packing this evening for a first time trip to Dallas, Texas to attend 4 days of Exchange 14 Ignite training. The event is being held at various locations across the USA this year in preparation for the next release of Microsoft Exchange Server which has yet to be given an official name (or has it?). 

The event will consist of:
  • Setup and deployment
  • Planning and sizing
  • Client Access Server changes
  • Federation
  • Transport and Routing
  • Compliance: Information leakage protection and control
  • Archiving and retention
  • Unified Messaging
  • HA and storage
  • Online services
I'm looking forwarding to the nice weather and opportunity to hear from the experts about this latest version of Microsoft's messaging platform.

Well I'd better get packing...

Wednesday, April 1, 2009

Tanjay won't update (Polycom CX700)


We've done our fair share of troubleshooting with the Tanjay phones lately as we have internally and at client sites various beta phones with the original firmware, R1 firmware and R2 firmware versions. I wanted to write a quick entry about how to update these phones.

First off, read this article to get an understanding of how the process works:

Second, if you have a SIP URI and SMTP domain which is different than the fqdn of the domain (i.e. for SMTP/SIP and contoso.local for AD) and you don't have WINS deployed then you will likely have an issue with the entire process.

You MUST MUST MUST deploy a WINS server and point your Domain Controller at the server so it registers the domain in WINS. You also need to add a static entry called "ucupdates" which points to your R1 update server.

If you're updating an R1 phone in an R2 pool and you have the above mentioned issue with the domain fqdn being different from your SIP URI domain, then add a static WINS entry called "ucupdates-r2" which points to your R2 front-end server.

If you're updating a beta firmware phone this MUST be done in an R1 environment first before logging into R2.

We worked with Microsoft extensively on this issue troubleshooting it by capturing Wireshark traces through the second network port on the phone. You can see the requests for WINS entries going out and if you don't have WINS running properly in your environment, this won't work at all.

NOTE: You may need to perform a hard reset on the phone once you update the beta firmware to R1. If you sign into an R2 pool an expect the phone to update and it doesn't, reset the phone and wait 5 minutes.

Hope this helps!