# Extension in Contact Card

• ### Question

• Hi Folks

I am trying to get our contact cards to display the extension number of our users who do not have a DID. In AD the numbers are E.164 format but are appended with ;ext=xxx so a 3 digit extension number for example: +441786523923;ext=123

We can successfully dial the users from the lync client by typing in the 3 digit extension as we have a normalisation rule in the users dial plan. However we are struggling to get this in the address book\contact cards. At the moment we see nothing and I assume this is because by adding the ;ext=xxx to the number this invalidates the E.164 format and is by design.

We are trying to forumalate the correct normalisation in the .txt file in the Lync File share directory according to http://blog.schertz.name/2010/09/lync-2010-address-book-normalization/ but we are failing miserably.

Could someone please suggest the correct rules to use?

Many thanks

Saturday, August 18, 2012 9:42 PM

### All replies

• Hi,

You need to create a normalisation rule in the TXT file:

+(\d{12})[Xx]{1}(\d{3})

+\$1;ext=\$2

And if the user telephone Number in the AD is +441786523923 X123, it will display +441786523923;ext=123 in the contact card.

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

• Edited by Tuesday, August 28, 2012 2:23 AM
Tuesday, August 21, 2012 5:50 AM
• Hi Sean

We have +441786545654;ext=123 in our AD so I assume the pattern to match is as follows:

+(\d{12})[Extx](\d{3})

+\$1;ext=\$2

Not sure if that is right, must learn regex!

TIA

Wednesday, August 22, 2012 12:11 PM
• and wouldn't that be

+(\d{13}) as opposed to 12?

Thanks

Wednesday, August 22, 2012 12:13 PM
• Hi,

Can you tell me why it is +(\d{13}) but not +(\d{12})? Does the number have 13 digitals?

Typically, we use this format in the the AD for teplephone Number which has a extension number,+441786545654 Ext123 or 441786545654 X123. I do not think the +(\d{12})[Extx](\d{3})  can work for the +441786545654;ext=123.

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

• Marked as answer by Friday, August 24, 2012 9:17 AM
• Unmarked as answer by Friday, August 24, 2012 7:05 PM
Thursday, August 23, 2012 1:51 AM
• Hi

Yes the numbers have 13 digits. I was under the misconception that as well at the Line URI having to be ;ext=123 that the AD phone number field had to be the same as well. Once I changed the AD phone number field to be X123 after the dummy main number and used your pattern above everything worked.

• Marked as answer by Friday, August 24, 2012 9:17 AM
• Unmarked as answer by Friday, August 24, 2012 9:17 AM
Friday, August 24, 2012 9:17 AM
• Ok so sorry about that, I still don't actually see the Ext in the contact card after the number. I still only see the main dummy number. I dont see any errors in the event log in regard to the numbers not normalising like I did before. I have also forced an address book sync. We are using the address book web query service as opposed to downloading the address book. Can you confirm the pattern I should be using. Should it be 12 or 13? our numbers have 13 digits including the + sign. Could you confirm the rule should be as follows:

+(\d{12})[Xx](\d{3})

+\$1;ext=\$2

Our numbers in AD are now in the following format: +441285829265 x101

Friday, August 24, 2012 7:11 PM
• Hi,

I am sure to tell you that you need this rule:+(\d{12})[Xx]{1}(\d{3}).

After you change the telephone format in the AD, please run update-CsAddressBook on the Lync FE server. I also delete the local lync user profile(C:\Users\username\AppData\Local\Microsoft\Communicator\sip_userprofile) and log in again, I can find the Extension number in my contact. Please try again. Best luck for you.

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

• Edited by Tuesday, August 28, 2012 2:22 AM
Monday, August 27, 2012 3:09 AM
• Hi Sean

Strange this is still not happening for us. How exactly does your telephone number display in AD?

TIA

Monday, August 27, 2012 7:57 PM
• Hi,

Very sorry for my mistake, the rule should be +(\d{12})[Xx]{1}(\d{3}).

The Normalization Rule in the My TXT file is:+1(\d{10})[Xx]{1}(\d{5}).

In my AD the telephone is :

The contact card telephone number is:

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Tuesday, August 28, 2012 2:29 AM
• Hey no problem Sean just glad of some assistance.

Well I still cannot get this to work :( We are running the hosting pack deployment of Lync and therefore the address book is partitioned. In my Lync File share we have a number of different directories under ABFiles, one for each tenant it would appear. I have copied\added the required info to the .txt file in each directory underneath ABfiles but still no joy. I dont see an invalid number file popping up in any of the directories apart from one which I would expect and this doesn't include any of the tenants numbers we are trying to normalise.

Could you try a test using the exact same number of digits we are using?

TIA

Wednesday, August 29, 2012 6:57 AM
• Hi Sean

Are you still with me?

Thanks

Tuesday, September 4, 2012 9:53 PM

I have test in my lync environment. It is also failed for me. I am working for the cause. I will update if I have any result.

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Thursday, September 6, 2012 4:21 AM
• Hi Sean

Any news on this, is this a bug?

Thanks