Lync 2010 Address Book Normalization

September 30, 2010 by · 57 Comments 

As discussed in a past article the Address Book Normalization process of OCS is a barely-documented and often misunderstood process.  The objective of this blog article is to explain how this process works now in Lync Server 2010.

Overall the process is generally the same, but with a few minor changes that impact both how it is configured and how normalization functions.

Default Behavior

Firstly, just as in previous versions of the client any telephone numbers stored in Active Directory phone attributes directly in RFC3966 complaint formats (+E.164) will be displayed by the Lync Client.  The number will appear both on the contact call menu and the contact card details.  For example the pattern +13125557501 is populated on the following AD user account and appears in Lync.

image     image

Secondly, following the same basic principals of previous versions the Lync client will also not display any phone numbers on contacts which fail to normalize into a +E.164 pattern.  For example the pattern (312) 555-7505 is populated on the following AD user account and does not appear in Lync.

image     image

In order to display number formats in the second example Lync Server will need to be manually configured to properly normalize these numbers.  As a general best practice the format should be pretty uniform among all AD users and contacts but if they are not then multiple rules can be added to match and normalize various numbering formats.

Configuring Address Book Normalization

By default normalization is already enabled in Lync Server which can be verified by the viewing the Lync Server’s current Address Book configuration.

  • From the Lync Server Management Shell execute the cmdlet Get-CsAddressBookConfiguration and note that the UseNormalizationRules value should already be set to True.

PS C:\> Get-CsAddressBookConfiguration

Identity                   : Global
RunTimeOfDay               : 1:30 AM
KeepDuration               : 30
SynchronizePollingInterval : 00:00:30
MaxDeltaFileSizePercentage : 20
UseNormalizationRules      : True
IgnoreGenericRules         : False
EnableFileGeneration       : True

But this setting in and of itself does nothing yet as the normalization file needs to be configured first.  Just as with OCS the Address Book does not leverage any Enterprise Voice normalization patterns which may have been created to support EV calling.  Note that if the value is set to ‘False’ (Set-CsAddressBook –UseNormalizationRules $false) then even numbers already entered in +E.164 format will not appear in the Lync client.

  • Locate the Lync Server’s shared directory which was configured during the initial server deployment.  The file server FQDN and share name can be identified in the Topology Builder under File Stores.


  • Browse to the share directory on the server and locate the ABFiles subdirectory.


  • Create a new text file named Company_Phone_Number_Normalization_Rules.txt in the ABFiles directory.  This normalization rules file must be stored in this location and not down a few directories where the actual address book files are stored as it was in OCS.


  • Edit the file with Notepad and enter the following example normalization and translation patterns.  This rule will apply to  the users configured with phone numbers in this standard 10-digit format: (312) 555-7500.  (The first three lines are commented out and are not required in the text file.)

## Normalize 10-digit phone number patterns from Active Directory into +E.164

Up until this point anyone familiar with Office Communications Server should recognize that everything is about the same, other than the required location of the normalization text file.  An improvement in Lync Server’s address book normalization process is instantly noticeable when looking at the simplicity of the example pattern above.  In the past long, complicated regular expressions (regex) were required to filter-out any non-digit information which could be potentially stored in the telephone field.

But now Lync Server automatically ignores non-telephony related digits in the strings and only looks at the continuous 0-9 numerical digits (and also recognizes the + symbol).  So there is no longer a need to include regex code like [\s()\-\./]* in patterns to ignore spaces, parenthesis, dashes, etc.

  • Execute Update-CsAddressBook to import the new settings configured in the text file and apply them to numbers stored in the address book files.

PS C:\> Update-CsAddressBook

At this point the contacts previously not displaying phone number information should now be working.

image     image

About Jeff Schertz
Site Administrator


57 Responses to “Lync 2010 Address Book Normalization”
  1. Mark Hickson says:

    As always, a perfectly written and extremely valuable post, Jeff. What's the same, what's different. With real-world examples. Awesome. Thanks!

  2. phydroxide says:

    From which A.D. fields does Lync Populate contact Phone numbers? We have heard some assert that it should be reading the IPPhone field, and in our configuration it is not, even after we normalize the 4-digit extension. What are the searched fields and do they include IPPhone?

    Also, i cannot determine a service in "services" which represents address book. Should there be?

    • jeffschertz says:

      Phone number information is pulled from the Work Telephone (telephoneNumber), Mobile (mobile), Home (homePhone), and Other Phone (otherPhone). The ipPhone attributes are not used in OCS/Lync.

      Also the Address Book service is actually not a standard Windows service, but is just and executable that the Lync Server runs automatically every time the polling interval (24 hours) is reached.

  3. Jeff says:

    My Lync client is only displaying users that are enabled for Lync. In OCS, I was able to see all AD users. Is this normal?

    • jeffschertz says:

      You normally should be able to see users which are either SIP-enabled and/or have a telephone number attribute populated for the purposes of click-to-call.

  4. Hey Jeff,

    Am I right in thinking my old friend "Invalid_AD_Phone_Numbers.txt" is no longer?? I've scoured several Lyncs (RC & RTM) looking for it without success. :-(

    In its absence, are you aware of any tool that will help diagnose numbers from AD that your normalisation rules aren't catching?


    • jeffschertz says:

      Unfortunately it is no longer in the product. I'm not sure the reasoning for removing it but I agree it was a helpful feature that I often used with clients to easily identify poorly formatted telephone strings within AD. An alternative would be to perform CSVDE exports of the related AD attributes and drop them into Excel to search for strings which would not be translated correctly be your defined normalization rules.

    • jeffschertz says:

      Turns out the feature is still in Lync, just needs to be re-enabled with a workaround:

  5. chrispt says:

    Thanks for all the good information you post. Is it possible to just have it pull a 3 or 4 digit extension if that is what you have in the Work field in AD?

    • jeffschertz says:

      Chris, You can enter extensions in the telephone fields provided that you create Address Book Normalization rules to properly translate those strings into +E.164 format.

  6. RLH says:

    First, great blog post and I've very appreciative of this information!

    I am having a problem with the normalization rule working for the Work phone numbers we have in AD in the format (XXX) XXX-XXXX. The contact card information for these users is just blank. I can however get the work phone to display for users if I enter E.164 format in AD. Those users show up as +1 (XXX) XXX-XXXX. For my normalization rule, I'm using just what was spec'd above
    I'd rather not have to go back through AD and change to the E.164 format so any suggestions on what I need for my rule to normalize the (XXX) XXX-XXXX format?

    • jeffschertz says:

      That basic rule should do it. Make sure that you are not cutting/pasting the rule directly out of my blog as the page formatting has added spaces to the ends of block-quote text, so if that space t the end is entered into the configuration file then when Lync adds the ^ and $ characters automatically in the background there will be a space between the ) and $ in the pattern, causing it to fail.

      • albogado says:

        Jeff, thanks for the information you have provided here but I am still unable to see my phone numbers in any of my AD contacts. I can see everything but the phone numbers and have tried your method outlined above to no avail. I even created a new file and typed the normalization from scratch. What troubleshooting steps would your recommend? The only difference from my normalization is that my phone numbers are listed as such in AD;


        Whereas in your example you have (312) 555-1212

        Do the parentheses and dashes need any special considerations? This is driving me crazy :) Any help is appreciated. Great blog

        • jeffschertz says:

          To verify at the least the ABS service is working correctly enter a few numbers in E.164 format with the + (e.g. +13125551234) directly into the AD user's Work Telephone field. If these appear in the Lync address book then it's a problem with the normalization file. Check the other comments about people cutting/pasting the example pattern from this web page and having an unwanted space in the pattern.

        • randy says:

          I know this really old but for anyone who is looking make sure that you have the added in correctly unlike the poster above (d{10}) as opposed to (d{10})

  7. Eric says:

    Hey Jeff, great post…I did the company norm text file but was curious if i'm manipulating the ABS config tool on the reskit wrong. I've set it to display work and moble only and those display fine on the contact card but on the call drop down next to their name I'm getting their work and mobile numbers twice and each displaying differently. (one with the dashes and one without)
    I've set the absconfig to "use normalization rules and include the normalized number for the phone attributes"
    Any idea how to get it to just display those numbers once in the drop down?
    Thanks in advance

    • jeffschertz says:

      Eric, I haven't seen that issue in Lync yet but I have many times with OCS and was never able to find a root cause outside of it apparently being a display bug in the client. If you look at the raw GalContacts cache file on the workstation you can at least see if the duplicate normalization entry appear there. If so then something is normalizing multiple numbers, but it only a single entry is in the cache file yet the client shows duplicate entries for those contacts then typically this is related to not using a proper RFC 3966 (+E.164) numbering pattern throughout OCS/Lync.

  8. Patrick says:

    Hi Jeff- Great post! This solved a HUGE problem for me. One question. How would I handle phone extensions? I'm updating all my AD phone numbers to format: +12065550100;ext=8632. Lync is not normalizing the number and I am seeing it exactly as it is in AD. Any suggestions?

  9. Idris says:

    great post. The best I've come across. We have a merged topology (everything imported from OCS 2007 R2). AD telephone field is populated with a 4-digit Call Manager extensions (3xxx). However, I'm unable to see these numbers in lync. They get normalized to +23414483xxx when i type and call in Lync.

    How do I get lync to display the 4-digit numbers?

    • jeffschertz says:

      Lync will only display numbers post-normalization so you cannot have just the 4 digit extension appear in the 'Call' menu for contacts.

  10. Brent says:

    Any good troubleshooting tips other than the lync logging tool ABServer process???

    Some users in AD are getting their four digit extensions normalized (+ sign added) but not their 10 digit home/mobile numbers. If i add a plus the number will show up in lync.

    Having difficulty finding good troubleshooting options with the AB normalization. Any help would be appreciated.

    *Also as always great stuff Mr. Shertz.

  11. romy says:

    I have a client that uses / in the number, is anyone willing to provide a normalization rule to normalize this xxx/ xxx-xxxx. Please and Thank-you

  12. GregWhitworth says:

    Great article, helped alot in my setup. However; I do have an interesting situation. We have a mix of users with DIDs and extensions only. So in AD we enter in the telephone field (555) 555-1234 for DID users and 9876 for extension only users. I have normalization rules in the dial plan and in the "Company_Phone_Number_Normalization_Rules.txt" file to normalize the 10 digits or 4 digits in AD to +15555551234;ext=1234 for DID users and +15555551000;ext=9876 for extension users. (555) 555-1000 would be the main number.

    This all works perfectly in the Lync Client. Clicking the drop down arrow on call shows the Work number as either +1 (555) 555-1234 X1234 for DID users and +1 (555) 555-1000 X9876 for extension users. When selecting the Work number Lync shows that it is dialing the persons name along with the normalized number described.

    • GregWhitworth says:

      Now in outlook when I hover over the name of the person who sent me an email and the cool contact card displays I can then select the dropdown next to the phone icon and I can choose to "Call Work.+1 (555) 555-1234 X1234" for DID users and "Call Work +1 (555) 555-1000 X9876" for extension users. All looks good so far. However; when the Lync call comes up it doesn't show that it is dialing the persons name along with the normailized number listed. It ends up attempting to dial +1555555123491234 for a DID user and +1555555100099876 for an extension user.

      Not sure why the number gets formatted with the 4 digit extension portion repeated with a 9 between the two. Any thoughts?

  13. says:

    Dear Jeff, would you please join discussion regarding duplicated numbers after custom normalization

  14. Jeff says:

    This was very helpful. However, it does not seem to correctly resolve names for reverse lookup (incoming calls) unless I was doing something wrong. Our voice is configured using RCC. I ended up using a powershell script to change all our numbers to E.164 format and all is well now.

  15. Matthew says:

    Hi Jeff,

    We have deployed Lync using RCC and have problems with reverse number lookup. Our extensions in AD are in a 3 digit format ie +500, but incoming calls are received as 500 without name resolution. Would you be able to advise me as to how to modify our normalisation rules?

    Many thanks in advance.

    • jeffschertz says:

      Matthew, you should not be normalizing the numbers with a '+' when using non E.164 string s for extension dialing with RCC.

  16. John Owens says:

    We have 2 types of users in our environment. Users with a D.I.D. and users with just extensions. Is there a format I can enter so they both show up properly?

  17. Sujitraj sancheti says:

    I have a my phone number in AD displayed in below format

    X – 1111

    Please let me know how can i have this displayed in Lync client for all the users.

  18. says:

    Dear Jeff, plese visit last post in this TechNet topic:

    It's about how Lync displays normalyzed dial strings in address books.

  19. Andre says:

    Great Post ! This was what I was looking for and its a shame that even in the original MOC course its not mentioned ! Keep up the good work ! :-)


  20. rocco says:

    I got lync server 2010 ad client and ip phone polycom Cx600
    all updated but i cant find people with accent character on the phone but it works on lync …an on ad everything is displayed correctlty with accent on the character …help please

    • jeffschertz says:

      This sounds like a character limitation in the Microsoft Lync Phone Edition firmware; I suggest opening a support ticket with Microsoft to report the issue.

  21. oscaR says:


  22. Alexandre says:

    We are migrating from OCS R2 to Lync and I got an annoying problem…
    In my AD, all the users have their 4-digit extensions in the telephonenumber attribute and their public number on other telephonenumber. (We do not want to change this)

    I imported the "company_phone_number_normalization_rules.txt" from OCS to Lync along with all the rules. Including the one for the 4-digit extensions to appear on the address book. (d{4}) —-> $1

    These rules worked flawless on OCS and still do…

    The problem is all 4-digits extensions appear duplicated when im selecting which contact i want to on Lync client.
    But when i dump the address book from the server to a *.txt none of them are duplicate and neither are on Galcontacts.db in the client.

    AB dump:


    tel:4340 4340

    Any ideas how to correct this "bug"?

  23. ChunKy says:

    Hi, could anyone advise me with normalization phone numbers with spaces? We have numbers in format "123 456 789" and I need the Lync client showing only the last 3 numbers. How can I do it? Thanks.

  24. Tom says:

    Jeff…good morning. I am trying to get my numbers to display as "(xxx) xxx-xxxx", without the +1 at the beginning. I have put this into my .txt file –
    and cannot figure out for the life of me why this command causes all the numbers to display like this – "xxxxxxxxxx". Any ideas?

    • jeffschertz says:

      I'm not sure what you are trying to do or which clients you are talking about (Windows, LPE?) but you cannot control the display format of the numbers using the normalization patterns. The different clients will automatically display the strings and cannot be customized in that way; for example: +12223334444 versus +1 (222) 333-4444.

  25. Pete says:

    Do you know of a way to get around the fact that any number that starts with a + sign is assumed to be already formatted for E.164, and no normalization rules will apply? It will be dialed as is. Normalizing numbers is easier then doing a large AD reconf/cleanup. We use + in all numbers but that is the only standard:)



    • jeffschertz says:

      No, there is no way I know to get around this as it's a hard-coded behavior within Lync to treat numbers starting with a plus as already global unique (and thus do not need to be normalized).

  26. Gaz Jones says:

    Great Post as usual Jeff…. can anyone think of any reason that you wouldn't just use the normalisation rules from your dial plans here? The following exports the dial plan rules into the format expected by the address book normalisation rules, I've noticed a few strange results in our case with numbers not being listed as expected but it generally works well.

    $dialplan = get-csdialplan global
    $file = "c:Company_Phone_Number_Normalization_Rules.txt"

    foreach($d in $dialplan.NormalizationRules){
    ("## " + $ + " – " + $d.Description) | Out-File $file -Append
    ($d.pattern) | Out-File $file -Append
    ($d.translation) | Out-File $file -Append

    • jeffschertz says:

      As a rule of thumb I usually duplicate the Dial plans rules in the ABS so AD numbers are normalized the same, but I have seen discrepancies between the two services before.

  27. Jose Maria Gonzalez says:


    Lync can use the symbol “number” # in the dial plan? Example must call extension ##4698, I set the path to the dial plan to rule ^(\##(\d{4}))$ also ^(##(\d{4}))$ and change the # to %23 generating an error in the call. The Lync test to verify the normalization runs successfully, but when marking the gateway generates error that marks %23%234698 instead of dialing ##4698.


  28. Nickey says:

    After modifying the "Company_phone" file, I still do not see my AD telephone numbers in the call menu when I right click on a user. We are using Lync 2013 with the latest updates.
    Another problem we have is that if I am viewing a user's contact card and I click on the work number it does not dial and call that user.

  29. Rob says:

    doesn't work. Lync 2013. created the fil in ABSfiles folder. restarted the services and did Update-CsAddressBook. abserver.exe -dumprules still gives the original rules….


Check out what others are saying about this post...
  1. [...] configuration of the Address Book service to be displayed in the Lync client.  See this previous blog article for more details on this [...]

  2. [...] around the new file structure to see if it was simply relocated.  As documented in this previous article the location of the server address book files moved in Lync Server, as did the proper location of [...]

  3. [...] additional configuration of the Address Book service to be displayed in the Lync client. See this previous blog article for more details on this [...]

  4. [...] more information about normalization of the address book for Lync, see this excellent article by Jeff [...]

  5. [...] 2010 Address Book Normalization: Lync 2010 People & Skill Search with SharePoint 2010 and TMG: [...]

  6. [...] To add new rules to support our AD phone number taxonomy, we create a file called Company_Phone_Number_Normalization_Rules.txt. Details on how to do this can be found on Jeff Shertz’s blog. [...]

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!