Adventures with the Lync Address Book (ABS). Or “When E.164 just isn’t E.164 enough for Lync!”

Down here in the Banana Republic we sometimes fall into traps when localising foreign products (in this context those of Microsoft) to our regional preferences.

OCS and Lync are no exception. (I have some vague recollection of being unable to install the first release of OCS on an original Server 2008 machine if you’d dared to change the locale from “US”, and similar issues with R2 Group Chat if you’d changed the SQL Language from “[US]English”).

This time it’s Australianising the Lync Address Book that’s tripped me up.

As you do, I loaded my “Company_Phone_Number_Normalization_Rules.txt” file into its usual location under “\\LyncShare\n-WebServices-n\ABFiles”, then set the cSAddressBookConfiguration to ignore the inbuilt (US-centric) normalisation rules and use my standard Aussie rules:

PS C:\> Get-CsAddressBookConfiguration
Identity                   : Global
RunTimeOfDay               : 1:30 AM
KeepDuration               : 7
SynchronizePollingInterval : 00:05:00
MaxDeltaFileSizePercentage : 20
UseNormalizationRules      : True 
IgnoreGenericRules         : True
EnableFileGeneration       : True

Running “Update-cSAddressBook” generated me a new set of Address Book files, but the clients would stubbornly fail to show any of the phone numbers for my users – even though they were stored in AD (and Lync!!) as E.164 anyway.

I got serious, exporting the Full Address Book file to text:

C:\Program Files\Microsoft Lync Server 2010\Server\Core>abserver -dumpfile "C:\LyncShare\n-WebServices-n\ABFiles\00000000-0000-0000-0000-000000000000\00000000-0
000-0000-0000-000000000000\F-0ef3.lsabs" c:\ABS-dump26Jun.txt

Sure enough, when I viewed the file I could see EVERYONE there, replete with beautifully-formatted E.164 numbers:


[“+6127000…” is semi-legitimate. It’s a valid prefix, but currently spare and isn’t likely to be issued for some years to come, so I’ve appropriated it as a pseudo-indial range for my Lab deployment].

Try as I might, they wouldn’t show to a user in the Lync client when you searched for the recipient. My Lync-enabled users would show in the search list, others showed as Suggested Contacts, but no bl**dy phone numbers.

Jeff Schertz inadvertently helped here with his recent post explaining how we can revive the missing Invalid Numbers file. And strangely enough, once I’d done that it became apparent that Lync was FINDING these phone numbers – just not liking them. Any of them:

Unmatched number: User: ''  AD Attribute: 'telephoneNumber'  Number: '+61270001236'

So I returned to ABServer, and it confirmed that my E.164 numbers (that didn’t need normalising) failed to normalise:

C:\Program Files\Microsoft Lync Server 2010\Server\Core>abserver –testphonenorm "+61270001236"
args[1]: +61270001236
+61270001236 -> failed to normalize number.

… and in the end, the solution was a simple one: Turns out you need to add a normalisation rule entry to “Company_Phone_Number_Normalization_Rules.txt” to turn your E.164 numbers into E.164:

## Aussie Number in VALID international format: +61 2 1234 5678

With the file edited and a new Address Book generated, ABServer’s testphonenorm is happy, and the resulting dumpfile now shows additional line(s) for all the users. And of course all the numbers are revealed to the Lync client. And for bonus points, multiple instances of the same user are consolidated into the one entry too!

C:\Program Files\Microsoft Lync Server 2010\Server\Core>abserver –testphonenorm "+61270001236"
args[1]: +61270001236
+61270001236 -> tel:+61270001236
    Matching Rule in Company_Phone_Number_Normalization_Rules.txt on line 35


So, if I’d only left the blasted “IgnoreGenericRules” enabled in the first place I wouldn’t have spent so long chasing my tail on this one. Thanks Happy for the help nailing this one!

– G.


  1. this is a really cool explanation, probably one step ahead of where i aam currently at.

    through the company i work for, i have just gone through all our users in Active Directory (Windows Server 2008 R2) and added in all the phone numbers with the +61 preface and they all showed up in Lynch no problems and they dial out through our Polycom phone system that is connected.

    but just recently ive been converting a speed dialing list hard copy, into AD by adding new contacts in an OU and filling in the phone numbers using the +61 for mobiles and lan lines, BUT, we have a few contacts on our list that are 1300 numbers and 13 numbers – e.g. taxi companies 13 10 08 – these numbers dont have a +61 that i can put in front, i mucked around with pizza huts number and tried +6113116 for the sake of it and when you click call – it just wont do it. have you heard of, or do you know how we can rectify this issue. we havnt employed the normalization fix either.

    thanks for your time, i appreciate any help you can offer.

  2. Hi Karl,

    When you say “Lync just won’t do it”, I’m guessing you mean the call attempts but fails? (Have you seen my post of Lync error messages and possible causes??). First off, +6113116 is 1 digit too short if you’re just gluing the country code on the top of a 13-number (and it’s not just a typo here).

    If we assume that you’re booking a cab by calling +61131008 and you have route/usage/policy that permit you to call “+61”, I’d be heading straight for your gateway and seeing if it’s correctly resconstituting E.164 for the local PSTN (or are you doing this in the csTrunkConfig?).

    Any chance you have a global that’s dropping “+61” and inserting a 0? There’s you’re problem.

    In order of sequence, here in AU, you need 3 rules to turn anything back to local format:
    \+61([0|1]) Drop +61 and dial what’s left. That gets you Triple0, 13, 1800, etc.
    \+61 Drop +61, add a 0 and dial what’s left. That’s the rest of Australia catered for.
    \+ Drop +, add 0011 and dial what’s left. Overseas.

    Otherwise, start tracing… (And good luck).

  3. It seems that the phrase “…then set the cSAddressBookConfiguration to ignore the inbuilt (US-centric) normalisation rules..” is based on the assumption that “IgnoreGenericRules” attribute is referring to US-centric rules, yet instead in output of “abserver -dumpRules” command shows different interpretation:

    Built-in Generic Rules
    # E164 Phone Number normalization (E164 keyword for regular
    # expression matches up to 14 digits into $1, stripping out
    # any separator characters (space, period, dash, left paren
    # and right paren)
    # The result for this rule is ignored and must be null.
    # The actual result if this rule matches
    # is tel:+digits-that-matched


    # +dd dddd… Xddddd


    # +dd dddd…


Leave a Reply

Your email address will not be published. Required fields are marked *

... and please just confirm for me that you're not a bot first: Time limit is exhausted. Please reload the CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.