Wednesday, May 8, 2013

Viewing Extensions in the Lync Client

In companies that use extensions off the main number, I’ve always recommended they format their numbers using the main office number for the “base” and followed by the extension (ie. tel:+14165551111;ext=222 for North America, or tel:+4420555111;ext=222 for elsewhere).  In Active Directory, I’ve recommended they use the same type of format (ie. +1.416.555.1111 X222), and use the Company_Phone_Number_Normalization_Rules.txt to enforce the same formatting.


For those unfamiliar with how Lync displays phone numbers, the Lync client will only display numbers it can parse from Active Directory.  It doesn't show the actual TelURI defined in the Lync Control panel, which is a good thing, because there are often additional settings applied there that administrators don't want to have appear in the address list.  The Company_Phone_Number_Normalization_Rules.txt file is helpful in re-formatting phone numbers in AD to the E.164 format we like to see in Lync.  For a good overview of the Company_Phone_Number_Normalization_Rules.txt, see Jeff Schertz's blog entry on the topic.

The Problem

I've found that when using the Lync 2010 client, North American phone numbers would always display with the typical North American formatting properly along with the extension when dialed, (ie. +1 (416) 555-1111 X222).  However, when applying similar rules to international numbers, the extension would never display.  It would show +4420555111 instead of +4420555111 X222.  The number would be dialed properly, but it would be confusing to the user, because the extension wouldn't appear.

Fast forward to Lync 2013 client, and the situation appeared even worse.  Even North American phone numbers with extensions wouldn't appear properly when dialled.  I assumed this was a client bug that was getting worse with each client revision.

The Solution...Sort of

Fellow Lync MVP Tom Pacyk of brought to my attention a little known (well, little known by me) feature added with the October 2012 update for the Lync 2010 client.  In short, the client update finally fixed the bug for international extensions, but with a had to first add a new client policy entry to your Lync client policy.  If only the global client policy is being used, the commands are:
$x = New-CsClientPolicyEntry -Name "ShowExtensionInFormattedDisplayString" -Value "True"
$y = Get-CsClientPolicy -Identity Global
Set-CsClientPolicy -Instance $y

Since this policy setting was a part of the Lync 2010 client updates, it would be very easily missed by someone whose focus has changed to Lync 2013.  I can only assume the same settings are required in a pure Lync 2013 environment, although there is very little information on the topic.

If you're running Lync Server 2010, it appears as though you need at least the October 2012 Lync 2010 server updates for this to work.  I tried to apply this client policy entry to a client's deployment whose got Lync 2010 and 2013 in parallel, but the Lync 2010 environment is a bit out of date.  The policy entry showed up properly when I ran the following:
$y = Get-CsClientPolicy -Identity Global
...but neither my Lync 2010 or 2013 clients would show extensions properly.  Applying the policy entry to a 2010/2013 server mix where the 2010 environment was up-to-date worked least for 2010 clients...mostly.

So, make sure your Lync 2010 infrastructure is up-to-date before attempting to apply this setting.

What's Still Not Working

I setup a few test users with extensions off a fictitious Toronto, Canada and London, UK main office number.  The Toronto user's office number in AD was set to +1.416.555.1111 X111, and the London user's number in AD was set to +44.20.444.2222 X999.  Both users were setup in Lync with their TelURI properly defined as tel:+14165551111;ext=111 and tel:+44204442222;ext=999 respectively.

A Company_Phone_Number_Normalization_Rules.txt file was placed in the ABFiles folder on the shared folder for the Lync server pool with the following rule to ensure Lync would be able to parse phone numbers  with extensions in Active Directory properly:

When testing with the Lync 2010 client, North American numbers showed up properly in both the list view and the dialing view, as shown below:

However, international numbers did show numbers a bit differently between the views, using the ;ext= from the TelURI instead of the X:

Interestingly enough, the Lync 2013 client doesn't seem to fully honour the extension setting for either North American or international numbers.  The number shows up properly when hovering over the phone icon, but only shows the main number when dialing:

North America

United Kingdom

Needless to say, this can be very confusing to the average user.

This appears to be a bug introduced with the Lync 2013 client.  I've brought this up with the Lync product managers, and we should see a future patch that will address the issue for Lync 2013 clients.

UPDATE (10-July-2013): The July 2013 Update for Lync 2013 addresses the extension presentation for North American numbers, as shown below.

However, non-North American numbers with extensions still don't show up properly.  I've been told this should be in a separate fix coming later.

UPDATE (16-June-2014):  I didn't notice but at some point in the past year, a patch seemed to mostly fix non-North America number presentation during dialing.  The number shows the extension as part of the TelURI, but it really should show the display number. At least its consistent with how the Lync 2010 client formats things.


  1. Great post!

    Ok the handsets are now showing the format +441234567890;ext=291 when enter 291 into the handsets! A big step forward!

    Now if I edit the normalization text file, do you think I could get it to show a 'nicer' format without breaking it?

    Also, sometimes if left for 10-20 seconds it will automatically resolve the +441234567890;ext=291 to the persons name and shows presence status. If this could be made quicker it would be perfect!

    I've had the Addressbookavailability option set to WebSearchOnly which I thought maybe was causing the delay, I have since set it back to WebSearchandFileDownload but this doesn't appear to have made any difference. I'm not sure if it only works if you've dialled that extension recently and it's cached the persons details or if it is looking up against the address book. Seems very intermittent.

  2. Because of this bug in the client we have delayed the production Go-Live of Lync 2013 and will be working with our beta test team in re-training on how to dial using the "Lync Call" feature. It would be wonderful if this patch came out prior to go-live though as I can foresee our help-desk team will be pounded with "Problems" and I think it looks bad on our part to release a broken product to the user base.

  3. Thanks for the great post.

    I wanted to find out if you’ve seen this issue with the Lync 2013 client and normalization.

    From a Lync 2013 client when doing a search for a user the user is displayed but from the Call menu the Work number is not. However from a Lync 2010 client (same Lync user and same search) the number is displayed.

    To see the number for the user from a Lync 2013 client, the Lync user has to add the user to their contacts list, restart the Lync 2013 client and then the Work number is visible.

    The normalization rules must be good because they are being displayed correctly in the Lync 2010 client on initial search and in the Lync 2013 client when added to the contacts.

    The environment is in a coexistence phase with Lync 2010, all users are now homed on the Lync 2013 pool.

    1. Yes, I've seen the same behaviour with the 2013 client. I've posted screenshots of both 2010 and 2013 clients above. Again, there is a fix coming in a future patch.


  4. The example number +4420555111 is two digits short and +44.20.444.2222 is one digit short compared with real London telephone numbers (and real London numbers currently have only 0, 1, 3, 7 or 8 directly after the 20 area code).

    Did you know that in the UK there's a whole bunch of numbers reserved for use in drama? These example numbers also work equally well in documentation.

    They are the equivalent of the 555 numbers seen in the US and Canada.

  5. Thanks Ken,

    Just hit this on a UK 2013 install. Hopefully it's high on the todo list

    Tom Arbuthnot

  6. Ken,

    Thanks for the great information regarding this bug. I do have a quick question though; is the rule required in the company normalization file if the phone numbers in AD are already configured with +13125551000 X1212? I thought if the address book process already see's the phone number with a + , it doesn't try to manipulate it using the rules, correct?

    We're seeing some very strange behavior and the data is inconsistent between Lync Clients and LPE devices. For example on the LPE devices, in a user's contact card, it shows +13125551000 X0

    We do have a ticket in with Microsoft but I'd love to hear your thoughts on this.


    1. Even with the AD numbers configured as +13125551000 X1212, its a good idea to include those in the normalization text file. That will ensure that Lync will parse the number as a valid Tel URI, ie +13125551000;ext=1212. Even if the number in AD has a +, Lync will attempt to normalize if you've accounted for the + in your rule inside the Company_Phone_Number_Normalization_Rules.txt file.

      The only time Lync will ignore normalization rules is on actual inbound calls with a + already on it. Doesn't apply to address book normalization.


  7. Hi Ken,

    We have about 15 users that don't have DID numbers (and are not enabled for Enterprise Voice) but I would like a number to appear on their Lync contact card. I've entered the common company phone number and extensions into their AD accounts however Lync is still logging a warning 21034 saying the numbers cannot normalise.

    The numbers are:
    +64 (New Zealand)
    9 (Area Code)
    123 4567 (Company Main Number)

    I've entered +6491234567;ext=1234 on each AD user however these users are all appearing in the Invalid_AD_Phone_Numbers.txt file each time the address book updates.

    I'm trying to to have to use Company_Phone_Number_Normalization_Rules.txt and just entering all numbers in AD as proper E.164.

    Is this related to the bug you mention above?

    1. Hi Christoph,
      For numbers in AD, you don't need to format the phone numbers with ;ext=. Format the numbers the way you would like them to appear in Lync. So, something like +64 9 1234567 x1234.

      In your Company_Phone_Number_Normalization_Rules.txt, you should have a normalization rule like:

      That should do the trick.

  8. First of all thank you for publishing your insights! It is very un-Microsoft of you.

    What I would like to add to is from my background as a PBX technician is the number routing in traditional telephone systems.
    The fact that there is no issue with North American numbers does not surprise me since those are a fixed length. 1-NNN=NXX-xxxx = 11 digits, always. When we program a PBX we define this as 11 digits and 0 to follow. Meaning that as soon as you dialed the 11th digit the system can process it.
    International numbers we program with 011 UNKNOWN to follow. See even the number of digits in a country code aren't the same length. North America is '1' Hungary is '36' and other countries are 3 digit.
    Not sure if the separator X before the extension is sufficient. In telecom usually we have an end-of-dial character, In a Mitel PBX cluster you can dial the PBX specific number you want to process a call and then the number and then '#' to indicate the end of dialing and force the system to process.
    I also have a degree in programming and know that without seeing the actual code that parses the text (ie: +64 9 1234567 x1234 is not a number) we have no idea what it will do.

  9. Hi Ken,
    Thank you for your great article,
    we faced that problem when user call from integrated PBX to external or lync user the calling ID is normilzaed to did;ext=xxxx.
    - it appear in lync client (soft, mobile, handset) and also in CDR report as DID number only without ;ext section.
    - we solve it for CX handsets and lync client according to this blog (thanks to your effort).
    - but for CDR or lync mobile client didn't work do you know how to enable it also on them.

    1. Hey Hamed,
      You know, I never noticed, but you're right about the lack of extension data in the monitoring reports. There is nothing you can do to configure the reports to show extensions. It would have to be included in a patch from MS.


  10. We have this same issue. I've got 2 settings to try to account for + or none (This is just testing, or normal GAL entries are +1 (123) 555-9190 X114. I'll meddle, run update-csaddressbook, close everything, open it all back up - I'm able to make one call - It displays great - shows the extension, call completes. I try again immediately after and it then trys to dial +11235559190114. Riddle me that! I'm at the point where I'll need to put 11 digit main number in one field and the extension in another so people can atleast reference it.

    I heard from Brian R that there was a weird issue if you don't update both company_phone_number_norm_rules.txt files both in the share and in core. I've done that as well.

    Have you seen anything similar. I know we're all patched and current. We're only a few weeks into go-live and this seems to be the only glaring complaint I hear daily.

    #External numbers with extensions

    #External numbers with extensions2

  11. How would we remove the + from displaying on a users account on CX phones?

    The user's Lync entry and AD account do not have a + in them and can't seem to find where to do that.