One of the handy things about Lync is the fact that it’ll parse the Global Address List (GAL), and make them available via the Lync client (using the abserver). This means that Lync will do all the lookup using its own copy of the GAL, rather than hitting the GAL. Additionally, that processed addressbook is cached on the client side, allowing much speedier lookups.
One of the things we’d noticed is that Lync likes the phone numbers formatted in a particular manor, otherwise you end up with some very strange number/calling issues. This leads to a problem because folks update their own address and phone information resulting in a myriad of number formats in Active Directory. A couple of examples:
- 555 555 1234
- (555) 555-1234
- (555) 555.1234
- 555.555.1234 x555
- 555.555.1234 ext. 555
Lync isn’t very happy with this, and will fail to parse these numbers. That is, unless you create normalization rules. This isn’t the same as “Voice Routing” normalization rules, which are rules that are applied when people make calls.
So how do you know Lync doesn’t like the phone numbers you have in the GAL? Lync logs the failures in the file stores path in a file (creatively) called ‘Invalid_AD_Phone_Numbers.txt’ under the file store location. Open the topology builder, and look at the “Files Stores” section, and go to that path in Windows Explorer. Under that path you’ll find a directory structure that looks like this:
The directory 1-WebServices-1 may have a different number depending on the number of Lync installations you have that are sharing the same file store, or if you’ve performed a transition between 2010 and 2013.
Using one of the above numbers as an example, you may find errors that look like this:
To fix this error, we need to create a normalization rule, these rules are stored in a text file called Company_Phone_Number_Normalization_Rules.txt which is stored in the
1-WebServices-1\ABFiles directory. This file uses regular expressions to match and reformat the numbers to an E.164 format. In the above example, I want to convert the number to be +15555551234;ext=555, so I’d using the following regular expression:
Once added to the file, and saved, we can test using the abserver tool with the right arguments. From the
<install path>\Microsoft Lync Server 2013\Server\Core we can run the following:
1 2 3 4 5
It’ll tell you the line number it matched the rule, and what the outcome of the rewrite looks like, a nicely formatted E.164 phone number.
The next step is to make sure you have normalization rules enabled, this is done using
1 2 3 4 5 6 7 8 9 10 11
UseNormalizationRules is set to
True, if it isn’t use
Set-CsAddressBookConfiguration to change it. Once set, you can leave it to the automated process to pick up the changes at the next cycle (in my case 01:30 the following day) or you can use
Update-CsAddressBook to force an update.
This process usually takes a little fiddling to adjust for all the variations in phone numbers, but once setup it makes life a lot better for the users.