Lync 2013 Address Book Blues - Perficient Blogs
Blog
  • Topics
  • Industries
  • Partners

Explore

Topics

Industries

Partners

Lync 2013 Address Book Blues

Since the days of OCS, there has been a need for an address normalization process so that phone numbers within Active Directory or Outlook contact lists could be normalized into the recommended E.164 format for usage within Office Communicator and Lync.  For most organizations the default rules in Lync are able to handle numbers in Active Directory that are in E.164 format, but while working with a customer on a Lync 2013 deployment I came across an interesting address book normalization issue that you should definitely watch out for.
This particular customer was interested in dial-out conferencing via the Lync Server AVMCU, so when we began testing calls we discovered that something did not add up with the address book normalization process.  Outbound calls were failing and after examination of the logs it became apparent that the normalized number included an “;ext=XXXXX” in the INVITE:
INVITE sip:+1312701XXX;ext=1XXXX@xxxxxxxxx.com;user=phone SIP/2.0
FROM: <sip:klove@ xxxxxxxxx.com;gruu;opaque=app:conf:audio-video:id:8S6V9NKQ>;epid=3ACD236015;tag=c0ff61fcc2
TO: <sip:+1312701XXXX;ext=1XXXX@ xxxxxxxxx.com;user=phone>
This format was despite the fact that the user’s contact card within Lync showed only the E.164 number without any extension information.  In fact, there was no extension information anywhere within Active Directory as only E.164 numbers were assigned to the telephoneNumber attribute within users’ Active Directory accounts.  Additionally, no company specific address book rules were in place and no pool, site or user dial plans were in place either, so it was very frustrating that the numbers were getting normalized to include an “;ext=XXXXX”.  Armed with this info, I attempted find to reproduce the issue in my lab.
I created a user account and assigned the account a telephoneNumber attribute in the same quasi-E.164 format as my customer:
+1 555 701 5555
The format normalized successfully and could be found within the user’s contact card in Lync:
ContactCard
A closer examination of the address book indicated that the telephoneNumber attribute had definitely been normalized to include the “;ext=XXXXX” despite the contact card showing only the E.164 number:
AddressBookDebugwEXT
$a = debug-csaddressbookreplication –user sip:ethel.a.merman@widgets.com –poolfqdn na-lyncpool01.widgets.com
$a.attributevalues
Further testing showed that despite what the debug-csaddressbookreplication results indicated, the number normalizes correctly (without the EXT) if you test the number directly against the Address Book server:
ABServerTest
Abserver.exe –testphonenorm “+1 555 701 5555”
Huh???  Why the difference?  And what matching rule on line 6?
As I indicated before, there was no Company_Phone_Number_Normalization_Rules.txt file in the pool file share that would have caused this and I was certain that a rule had to be in place somewhere for this to be occurring, so I turned to Process Monitor to help sort things out.  With Process Monitor running I restarted the Front-End service and discovered that the Front End service, along with ABServer.exe, accessed a file called Company_Phone_Number_Normalization_Rules.txt in the installation directory of Lync before attempting to check the file share for a file of the same name:
ProcessMonitorCapture
E:\Program Files\Microsoft Lync Server 2013\Server\Core\Company_Phone_Number_Normalization_Rules.txt
This undocumented behavior was definitely a surprise and as I looked through the contents of the file it became obvious as to why the numbers were getting normalized to include an “;ext=XXXXX”:
#
# +1 (ddd) 70dddddd
#
\+1(\d{3})70(\d{5})
+1$170$2;ext=$2
The vast majority of the rules contained within the file are examples of how Microsoft normalizes their address book, but the rule above was being caught by my test phone number of +1 555 701 5555 which resulted in unexpected and incorrect normalization results.  This same rule was also catching my customer’s phone numbers of +1 312 70X XXXX.  To workaround this issue, I could do two things:

  1. Create a Company_Phone_Number_Normalization_Rules.txt file on the pool file share with normalization rules to override this behavior
  2. Comment out or delete the rules contained within the Company_Phone_Number_Normalization_Rules.txt file in the Lync Server installation directory

I would suggest using #1 above as it requires the least amount of administrative work, but within my lab I chose #2 and commented out the offending rules by adding a # sign before the rules:
#
# +1 (ddd) 70dddddd
#
#\+1(\d{3})70(\d{5})
#+1$170$2;ext=$2
After saving the TXT file, restarting the Front-End service and running an update-csaddressbook command, the numbers normalized correctly and everything worked as I expected it to:
AddressBookDebugwoutEXT
$a = debug-csaddressbookreplication –user sip:ethel.a.merman@widgets.com –poolfqdn na-lyncpool01.widgets.com
$a.attributevalues
After all the digging it appears that there is a undocumented behavior within Lync 2013 where the Front-End service and Address Book service will read this local file before attempting to read the file share.  In most cases this wouldn’t be an issue, but because my customer had 70X NXX numbers, it resulted in some head scratching and heartache until we figured out that this was the root cause.
So go out there and check your address book normalizations….you might find something unexpected!

6 thoughts on “Lync 2013 Address Book Blues

  1. After a day of head scratching, I stumbled across this post. Thanks Trevor
    We recently migrated all our users to 7-digit extensions and had all our address book entries rewrite to +1 425 xxx-xxxx
    Thanks Microsft

  2. Should be able to use the set-csaddressbookconfiguration -identity -IgnoreGenericRules $true
    From TN IgnoreGenericRules:
    Indicates whether or not the Address Book server ignores the generic normalization rules used when parsing phone numbers. Generic rules are the rules that are built into Skype for Business Server 2015. These rules cannot be changed; however, by setting the value of this property to True you can instruct your Address Book servers to ignore these rules and instead use custom rules that you create yourself. The default value is False.

  3. So I am a sys admin who was thrown Lync (previously deployed) with no prior experience or training on it. I was wondering there the 425 number was coming from when I right clicked a user and went to call. It fails to work and just confuses people. There is a also the 7 digit standard version of the # too. The Lync deployment I have is fairly simple as far as normalization rules and dialing goes – all local 7 digit. I found your blog and thought I had solved it. We don’t have our own normalization rules file in the default share but obviously have the default one in program files directory. I commented all the rules out that have 425 in them, saved, and restarted all front end servers. I signed out of Lync, cleared my Lync temp files. and restarted the client. Still showing the 425 # for all contacts. Waited a few days – still there. Any idea where this may be coming from? Any help would be appreciated.
    Thanks for the post btw!

  4. In Lync Server 2013 (or 2010) the only two places the Company_Phone_Number_Normalization_Rules.txt file can exist is on the pool file share (unique for EACH POOL, potentially) and in the default, hidden location within the Program Files directory on your install drive. If you’ve made changes to either file, you really need to run the following two cmdlets to make things update:
    Update-CsUserDatabase
    Update-CsAddressBook
    Don’t run both simultaneously; you need to wait about 15 minutes for each cmdlet to complete before moving on to the next. If you are still having problems with numbers showing up in the address book incorrectly, then your TXT files aren’t right.
    In Skype for Business Server 2015, the address book generation process is completely different and doesn’t rely on the TXT file at all. In this case you need to examine the Get-CsAddressBookNormalizationConfiguration and use the Remove-CsAddressBookNormalizationRule to remove the offending entries.

Leave a Reply

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

Subscribe to the Weekly Blog Digest:

Sign Up