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

What I do see is the mobile number.

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.

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.Clicking 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.

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.

Like this:

First, exclude the users from the Exchange GAL by setting the msExchHideFromAddressLists user attribute to true. This will hide them at the Exchange level within the company. No one will stumble upon them in their address book.

Second, isolate the users from Lync address book so that they can only discover themselves. This is accomplished with another user attribute: msRTCSIP-GroupingID.

This attribute is a 16-character GUID which, if present, only returns contacts that also have the same GUID value present on their account.

In other words, if John has this attribute set to 1111111111111111, then he can only search for and discover other users (by name) that also have the same value for this attribute. It should be noted that, just like federation, if John were to enter the full SIP URI of a user, he would find them. So while it can’t be considered complete isolation, it provides enough isolation to satisfy our needs. That is, not exposing internal users to this external group.