'Why doesn't my Communicator client have any numbers for anybody?'

I.e you right click on somebody there is no number available for you to call.
Well, there is a big reason for this, and it's an important one - one that seems to be causing an awful lot of confusion out there for one reason or another, whether it's phone numbers not appearing or not being able to actually make calls.
This big reason is that OCS only works with E.164 numbering. There's an article here on Wikipedia about it - but I'm sure if you're reading this you'll actually know what E.164 is.
This is an example of an E.164 number compared to a 'normal' number: +44 870 60 10 100 - normalised is 08706010100.
The other thing to consider is that OCS only considers a number to be an E.164 if it starts with a '+'.....
Now, I want to stress this, you may think you've come up with various funky ways to ignore the E.164 requirements by putting a plus in front of your AD numbers for example, or by doing number manipulations at the gateway etc. etc. however I cannot stress enough - just don't do it. The whole of the OCS product set is designed to work with E.164 - stick with it, and deal with the E.164 at the edge - I.e. interface to phones - in another article... I.e. I'll show you how to do it in a standardised way that makes interoperability relatively easy.
So, what am I covering in this particular piece? I want to show you how OCS interprets your telephone numbers from Active Directory and how you can get them to show within your communicator client. I'm not at this point covering voice integration for Remote Call Control or for Enterprise Voice - we'll get to that.
The first thing to get clear is that OCS does not read telephony information directly from the Active Directory with every query - this would place too large a load on the AD system in larger deployments. Instead, a seperate Address Book system is implemented. This is an intermediary between the Active Directory and the OCS system.
The Address Book Server (let's call it the ABS from now on) will read E.164 numbers from Active Directory and populate them into the OCS Address Book. Now, hands up who has E.164 numbers populated in their AD? Anyone? No? Thought not.
So, how do we get 'normal' numbers to correctly appear in our Communicator client?
We do these using a process called Normalisation - or Normalization if you can't spell.
By default, OCS has a number of in-built rules to normalise numbers between the Active Directory and the OCS ABS however these are predominantly US based formats and as such do not translate particularly well to the UK and Europe.
So let's run through the process of normalising your numbers from AD.
Office Communications Server Resource Kit
The first thing I would recommend is getting hold of the OCS Resource Kit. This can be downloaded here. Install it on the server that has your ABS on it for now. As a bit of advice, do not accept the default directory, instead put it in the root (C:\OCSResKit or similar) - a lot of the commands are command line based and having to type in 'CD \program files\office communications server 2007 resource kit\bin' or whatever it is gets old really quickly.
Enabling Specific Normalisation
The first step in normalising your phone numbers is enabling control for normalisation - I.e. turning off the in-built 'default' rules and specifying your own. To do this, you can use the 'ABSConfig.exe' tool from the resource kit. This tool is used to configure ABS within the OCS deployment an

Executing the utility gives you this screen. Ensure that 'Do not apply any include or exclude filters' is selected as well as 'Use normalisation rules and include the normalised number for the phone attributes'.
Select the options and then click 'Apply Changes'.
Note that you can use this tool to modify the mappings of AD attributes to their OCS equivalents - for example I configured the main work number to come from the AD 'otherTelephone' attribute during testing to ensure I didn't break anything.
Next, click on the 'Configure WMI' tab at the top of the screen. On this screen only change the 'Normalisation Rules' section - ensure that 'Apply only

Once you've done that you can quit out of the tool.
Normalisation File
To normalize the numbers according to your own rules you need to create text file in the OCS' Address Book directory. You will have noted this at installation – if you didn’t, type ‘Net share’ from a DOS prompt on the server that runs the ABS and you’ll see the directory listed.
You need to create a text file in that particular directory explicitly called:
Company_Phone_Number_Normalization_Rules.TXT
Note the Americanism here – it’s important that this text file is named exactly as listed.
So, what’s in the file? Well, it essentially a list of normalization rules using regular-expressions as the search and replacement parameters.
In terms of file format – these is no format other than every expression is started by a search string and finished by a replacement string.
Example format:
# Directly pass numbers that are already detailed as E.164
^(\+\d{10}\d+)$
$1
# now 4 digit extensions
# 8000-8099
^(80\d{2})$
+44163599$1
So, comments on the format. Hash is a comment. The first line is your matching RegEx - I.e. to see if the number that's read in scope of the modification. The next line is the modifier - I.e. the modification to apply to the number.
In the above example the first rule checks for numbers supposedly already in E.164 by checking to si if the number starts with a '+' and is at least 10 characters long - if it is, it is passed untranslated.
The second rule checks for numbers between 8000 and 8099. This number is then modified to:
+44163599x where x is the original extension number. Note I've modified the numbers so they're not real numbers.
Now .NET Regular Expressions (RegEx) are a bit beyond the scope of this article however they're not that difficult to learn. It's useful to have a test though - for this purpose I can thoroughly recommend this site. Make sure you change the operation to 'Replace' and you then can test your RegEx against your numbers.
There are a couple of useful sites out there on .NET RegEx including this one and this one - worth a read-up.
There’s also a routing-helper tool within the OCS Resource Kit however as is often the case with MS software I found it hid too much and also did not tell the whole truth in terms of expression output – it ignored spaces for example in the tests but these were not ignored on the actual live OCS solution.
Your number must match one of the rules in this normalisation file for it to appear in the ABS. Now, fortunately OCS dumps a file of all the numbers it cannot match into a single file - you can use this as reference for the rules that you'll need to enter.
The file is called 'Invalid_AD_Phone_Numbers.TXT' and is located in the in the Address Book shared directory. You'll see a number of entries - probably loads at first inspection - along the lines of this example:
Unmatched number: User: 'DhakinoNzwange' AD Attribute: 'mobile' Number: '6 8597683'
Unmatched number: User: 'Derek.bristow' AD Attribute: 'ipPhone' Number: '0'
The above would tell me that these numbers would not appear for these users as there's no matching rules for those formats. In the above examples though it's worth noting that chances are a 0 and the number listed are actually wrong anyway - you really need to go through this file and make rules for all of the valid numbers that are listed in this non-matching file. The idea is to get the number of non-matched numbers down to a minimum.
Regenerating the Address Book
By default the address book within OCS is calculated and populated overnight. This is great for normal operation however it makes testing your normalization rules quite difficult. Luckily, there is a way to prompt the address book generation to run immediately.
This is a two step process:
1. Force a FULL regeneration of the address book
2. Run a synchronisation
To carry out each of these steps you can do the following:
Full Regeneration
Locate the ‘ABServer.EXE’ on your OCS server. This is typically in the following path:
C:\Program Files\Microsoft Office Communications Server 2007\Server\Core
You’ll need to run this command from a DOS prompt so start your DOS prompt and CD in to the above directory – it’ll take about 5 mis-types but you’ll get there eventually.
To regenerate, type the following command:
ABServer.EXE –regenur
This can take a few minutes to run – it must complete before you kick off the re-sync. To see whether it’s complete or not open the Event Viewer and look out for a 30028 event in the ‘Office Communications Server’ log.
Run a Synchronisation
To run an immediate synchronisation, from the same directory run this command:
ABServer.EXE –syncnow
Again this can take a few minutes to run. From within the Event Viewer look out for a 21058 event to denote its completion.
After running above have another look at the 'Invalid_AD_Phone_Numbers.TXT' file - this will indicate what numbers failed to match your rules. You'll need to revisit your rules file again and re-run the syncs.
Testing Your Rules
A more direct test is to see if you can see people’s phone numbers in your MOC. One thing to be aware of – and it’s caught me out no end of times – is that changes from the Address Book are not replicated to the client immediately. Only delta changes are downloaded and even so they’re a little unpredictable times. You can however force a FULL download of the address book for testing.
To do this, firsthet close down your MOC by right-clicking on it and selecting ‘Exit’. Next, you need to locate the local copy of your address book. This is located in the following directory:
C:\Documents and Settings\Username\Local Settings\Application Data\Microsoft\Communicator\
NOTE: This directory is typically hidden so you will need to enable the viewing of hidden files within your Explorer.
The name of the file is ‘GalContacts’DB’ – delete this file and then start your Communicator again from the Start menu.
You should now be able to see the relevant numbers when you right-click on your contacts – as shown. (Of cou

Now, as a side note, do not be temped to try and do funky things here like adding 9s for an outside line etc. It simply does not work affectively and will cause you grief.
In my following articles I'll explain how to integrate into Cisco CallManager for both Remote Call Control and Enterprise Voice - all using E.164 numbers.
Until next time, thanks for reading, and hey, be careful out there.
No comments:
Post a Comment