Solving Invalid_AD_Phone_Numbers.txt


OK so if you are OCD (and nothing wrong with that) then you may be compelled to make the event warning on your front end reporting on Invalid numbers every morning just after 1:30 am.

The Event ID 21034 explains as follows:


Its arguably one of the most comprehensive and helpful Cause and Resolution events you may ever see!

The Process

When Lync collects the user data from Active Directory a number check is done and only numbers that conform to the E.164 numbering format (I have noticed that an E.164 number with a x1234 on the end is also permitted by default) are imported. Hence the errors..

So looking into the text file (located at Lync File share…1-WebServices-1ABFiles0000000-0000-0000-0000-0000000000000000000-0000-0000-0000-000000000000 called Invalid_AD_Phone_Numbers.txt)
What do we see?

Edited for simplicity I have shown below just a sample of the  culprits.

Unmatched number: User: ‘sip:peter.pan@lyncsorted.co.nz’  AD Attribute: ‘telephoneNumber’  Number: ‘095504321’
Unmatched number: User: ‘fb56a490-0e27-4cac-b6cc-fb17ae0d4dba’  AD Attribute: ‘telephoneNumber’  Number: ‘1234’

NOTE
Its VERY common to see entries with the strange SID looking user name, these are usually disabled accounts and can be hard to find the true user attribute. I usually do an advanced search and use the number attribute provided to find these. By the way, they do no harm just sitting there, its the valid accounts I concern myself with.

The number assigned to Peter Pan above is valid (but not an acceptable default format). To format this number to a recognised number for populate the Lync Address Book service a normalization rule set can be created. 
All numbers that do not comply to the E.164 format by default will parse through the AD normalization rule set to be transformed to E.164 (or any format you allow in the regex)

Do make sure that Lync ABS is configured to use this normalization rule set with the Lync Server Management Shell command:-

Get-CsAddressBookConfiguration

The name and location of the AD Normalization rule set is essential. The rule set must be called Company_Phone_Number_Normalization_Rules.txt and must be located in the central Lync File Share …LyncShare1-WebServices-1ABFiles


The contents of this txt file are documented in the table below:

## Sample AD Normalization rule set for populating AddressBook Service
##Created by PaulB
##
##Normalise to E.164
## 
##Local format from Active Directory into E.164

##Auckland (New Zealand) National Prefix (9) & Country Code added as +649 (and 6 or more digits)

([2-9]d{6}d+)
+649$1

##National format from Active Directory into E.164
##New Zealand Country Code added as +64 and dropped 0 (and 6 or more digits)

0([2-9]d{6}d+)
+64$1

##No DID, extension number only
## Assuming 4 digit extension and passing through to ABS transparently

([0-9]d{3})
$1


Once the rules are added you can test by using ABServer.exe

ABServer.exe can be found at C:Program FilesMicrosoft Lync Server 2013ServerCore (assuming default install directory)

Run ABServer.exe in the Command prompt window in the following format
 in the following format (where 095501234 represents the number to test)

ABServer.exe -testPhoneNorm “095501234
In the below image I have run a valid number test not requiring additional normalisation, followed by a National format number. Notice how the first number (+6495501234 x5234) normalises to the expected line URI format used in Lync. It also mentions that the rule was matched by built in ABServer.exe rules

The Second test was in the national format (095501234), this was normalised by our Company_Phone_Number_Normalization_Rules.txt file to the Line URI +6495501234 as required.



Now to get the AddressBook syncrosised to Lync

From Lync Server Management Shell run:-

Update-CsAddressBook -verbose
  
Before adding these rules the non complying numbers don’t show up in the users contact card, once the rules are in play and the address book has regenerated then the contact card show the numbers loaded from AD in the new accepted format.

Before                          After

Advertisements

About Paul B

My name is Paul Bloem and I am employed at Lexel Systems in New Zealand as a Principal Consultant for Unified Communications. I have been working on enterprise voice solutions for over 20 years. My first 10 years were spent working for a Telco in South Africa (Telcom SA). This is where all the groundwork happened as I was exposed to just about every aspect of telecommunication you could imagine. I develop an interest in PBX technologies and eventually became the go-to guy. Next, I had a 10 year run at Siemens South Africa, most of my time there was as a Technical Trainer. During this time VoIP hit the world stage, I had the privilege of introducing VoIP both as H.323 and later SIP across the Siemens HiPath 4000 solution stack. In 2008 I immigrated to New Zealand with my newly attained MCSE, I was ready to go where no PBX Techie had gone before. I was employed to explore OCS 2007 and that was pretty much the beginning of the end for me. I have been working on OCS and Lync ever since. My current role focuses exclusively on Lync and associated technologies.. That includes pre-sales, consulting, architecture and design, training and support. I even get to play in the development space from time to time - focus on play ;-) I was nominated as a Microsoft VTSP for Lync early in 2013 and also awarded Microsoft's MVP award for Lync in 2014.
This entry was posted in Company_Phone_Number_Normalization_Rules.txt, Event ID 21034, Solving Invalid_AD_Phone_Numbers.txt. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s