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