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=222for North America, or tel:+4420555111;ext=222for 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.
Background
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 +4420555111instead 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 ConfusedAmused.com 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 catch....you 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
$y.PolicyEntry.Add($x)
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
$y.PolicyEntry
...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 fine...at 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:
\+(\d{6,14})\D+(\d+)
+$1;ext=$2
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.
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.
0 komentar:
Posting Komentar