Lync 2013 Address Book Blues

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

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:

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:

$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:

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:

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:

$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!