Category Archives: ADContacts

Number missing from Call Button but present in Contact Card

09 Tuesday Dec 2014

Posted by in AddressBook, contacts, Address Book, ADContacts, ABS, Call Button, Call Work

≈ 1 Comment

Tags

, ,

Perhaps one of the most mysterious of components in Lync is the Address Book Service and how it populates the Outlook contacts with numbers from AD and so on.

Had one such interesting issue today and hadn’t realised the (now obvious) symptoms.

The issue is that Lync contacts are not showing office numbers from the Call Button call button

What I do see is the mobile number.mobile only

AD Properties

Checking the users AD Properties to see what’s been defined for the user in question I confirm that a valid number is indeed specified.

Next I need to be sure that the number is being normalized by the AddressBook Service when updating the Lync Address Book.

This is done with the assistance of ABServer.exe found on the Lync Front Ends at C:\Program Files\Microsoft Lync Server 2013\Server\Core

Run the command in the following syntax:-

ABServer.exe -testphonenorm “+64 (1) 234 5678 x 4675”

where +64 (1) 234 5678 x 4675 is the format we saw earlier in AD Properties.

ABServer

So as you can see, our number is successfully normalising to tel:+64….6868;ext=3868

So far so good. The number is in AD, it is in a valid format so it should be in the contact card. Checking the contact card we find that it is indeed there under Call Work.contact cardClicking on the hyperlink for Call Work reveals that the number cannot be called, this eludes to the true reason why the number does not show up under the Call button.

To call the number as it shows up in the contact card a Lync Dial Plan entry has to be added that normalises the number to its Lync format (so it normalises back to the Lync users Line URI). You can use the same  pattern as was seen in the ABServer.exe match.

^\++(\d+)[Xx]+(\d{1,15})*$

Once the normalisation rule has been added you should be able to call the number in the contact card by clicking on the hyperlink for Call Work. Once the number has a matching Dial Plan rule it appears as an entry in the selection list of the Call Button.

call button works

In Summary

If you wish to see a number in the Call Button selection list then a matching Dial Plan rule to call the number must exist. Obvious now that we know.

Managing non DDI numbers in AD during migration

13 Wednesday Feb 2013

Posted by in ABS, ADContacts, AddressBook Service, DDI, Normalization

≈ Leave a comment

If ever you get cross pollinated contact cards then you have just been a victim of Lync Contact Merge. A good explanation of this is found here. Its a handy feature but not always desirable…

I landed up with this by normalizing the numbers in AD to a common DDI for all non DDI Telephone numbers in AD – not a good idea 😦

My scenario was that a number of users in AD had 4 digit extension numbers set for their Telephone Attribute. Now we all know that this is not going to make the ABS happy as the import requires a + to deem the format acceptable.

*Simply adding a + in front of the ext number wont work as the Lync Normalization rules DON’T apply to numbers that have been imported from AD.

What we want to achieve is a unique number in AD and thus in the ABS to avoid Contact Merge. We also want all the non DDI users in AD (who live on a legacy PBX) to dial a common DDI which presents a prompt to select the extension (a function on the Legacy PBX).

The Solution…
Normalise the AD Telephone Number field to the Common DDI BUT add the actual Extension number on the end of the normalized number. This will ensure that the Attribute stays unique and it will also be a valid number to dial. When the normalized number is passed to Lync for calling it ignored the normalization rules as stated above at *. The number is sent “as is” to the mediation server and thus passed on to the Provider, who simply ignore the extra digits on the end of the valid E.164 number.

Ta Da


AD Contact Numbers not showing in Lync

05 Tuesday Feb 2013

Posted by in ABS, ABServer, AD Normalization, ADContacts, AddressBook Service, contacts, E.164, Invalid AD Phone Numbers, Normalisation, Normalization, Test

≈ Leave a comment

Its always frustrating how Administrators don’t have any standard format in which they add telephone numbers to user in AD.
Its even more frustrating when Lync WONT collect these numbers and send to the RTCAB database cause they aren’t in E.164 format.

It is possible to add normalization rules for modifying numbers from AD to E.164 so that they are recognised by Lync and sent off to the Database.

If this happens the AddressBook Service will gladly distribute these to Lync user via GAL or WEB.

It will even distribute numbers that aren’t in E.164 as long as they have a normalization rule in the “Company Phone Number Normalization Rules” text file that matches the format in AD (as per the Extension Example below)

So how does this work?
Simply create a txt file and copy to the Lync Share

….LyncShare1-WebServices-1ABFiles

Company_Phone_Number_Normalization_Rules.txt

Now populate the txt file with your rules as per the example below:

#Start
#
# Normalize 4-digit extension numbers from Active Directory into E.164
#
# Legacy extensions
#
(d{4})
+643321$1
#Normalize NZ National Numbers from Active Directory into E.164
#+64$1
0([3-9]d{7})
+64$1
#Normalize NZ Cell numbers from Active Directory into E.164
#+642$1
0(2d+)
+642$1
#Extension Dialing for 8xxx range
(8d{3})
$1
#End


To find further Active Directory Normalization failures navigate to the directory:
C:LyncShare1-WebServices-4ABFiles0000000-0000-0000-0000-0000000000000000000-0000-0000-0000-000000000000Invalid_AD_Phone_Numbers.txt

NB
Just be warned, this isnt validated so if you make any typos you wont find this reported

BUT you can test this by running the ABServer.exe -testphonenorm switch.
Simply run the ABServer .exe from the directory:-
C:Program FilesMicrosoft Lync Server 2010ServerCore

Example


..Program FilesMicrosoft Lync Server 2010ServerCoreABServer.exe” -testphonenorm “021 123 4568”