Tuesday, March 1, 2011
Lync 2010 Address Book Normalization
The Address Book Normalization process of OCS is a barely-documented and often misunderstood process. The objective of this blog article is to explain how this process works now in Lync Server 2010.
Overall the process is generally the same, but with a few minor changes that impact both how it is configured and how normalization functions.
Default Behavior
Firstly, just as in previous versions of the client any telephone numbers stored in Active Directory phone attributes directly in RFC3966 complaint formats (+E.164) will be displayed by the Lync Client. The number will appear both on the contact call menu and the contact card details. For example the pattern +13125557501 is populated on the following AD user account and appears in Lync.
Secondly, following the same basic principles of previous versions the Lync client will also not display any phone numbers on contacts which fail to normalize into a +E.164 pattern. For example the pattern (312) 555-7505 is populated on the following AD user account and does not appear in Lync.
In order to display number formats in the second example Lync Server will need to be manually configured to properly normalize these numbers. As a general best practice the format should be pretty uniform among all AD users and contacts but if they are not then multiple rules can be added to match and normalize various numbering formats.
Configuring Address Book Normalization
By default normalization is already enabled in Lync Server which can be verified by the viewing the Lync Server’s current Address Book configuration.
Browse to the share directory on the server and locate the ABFiles subdirectory.
\\lab1ls\LyncShare\1-WebServices-1\ABFiles
Create a new text file named Company_Phone_Number_Normalization_Rules.txt in the ABFiles directory. This normalization rules file must be stored in this location and not down a few directories where the actual address book files are stored as it was in OCS.
Edit the file with Notepad and enter the following example normalization and translation patterns. This rule will apply to the users configured with phone numbers in this standard 10-digit format: (312) 555-7500. (The first three lines are commented out and are not required in the text file.)
Up until this point anyone familiar with Office Communications Server should recognize that everything is about the same, other than the required location of the normalization text file. An improvement in Lync Server’s address book normalization process is instantly noticeable when looking at the simplicity of the example pattern above. In the past long, complicated regular expressions (regex) were required to filter-out any non-digit information which could be potentially stored in the telephone field.
But now Lync Server automatically ignores non-telephony related digits in the strings and only looks at the continuous 0-9 numerical digits (and also recognizes the + symbol). So there is no longer a need to include regex code like [\s()\-\./]* in patterns to ignore spaces, parenthesis, dashes, etc.
At this point the contacts previously not displaying phone number information should now be working.
Overall the process is generally the same, but with a few minor changes that impact both how it is configured and how normalization functions.
Default Behavior
Firstly, just as in previous versions of the client any telephone numbers stored in Active Directory phone attributes directly in RFC3966 complaint formats (+E.164) will be displayed by the Lync Client. The number will appear both on the contact call menu and the contact card details. For example the pattern +13125557501 is populated on the following AD user account and appears in Lync.
Secondly, following the same basic principles of previous versions the Lync client will also not display any phone numbers on contacts which fail to normalize into a +E.164 pattern. For example the pattern (312) 555-7505 is populated on the following AD user account and does not appear in Lync.
In order to display number formats in the second example Lync Server will need to be manually configured to properly normalize these numbers. As a general best practice the format should be pretty uniform among all AD users and contacts but if they are not then multiple rules can be added to match and normalize various numbering formats.
Configuring Address Book Normalization
By default normalization is already enabled in Lync Server which can be verified by the viewing the Lync Server’s current Address Book configuration.
- From the Lync Server Management Shell execute the cmdlet Get-CsAddressBookConfiguration and note that theUseNormalizationRules value should already be set to True.
- But this setting in and of itself does nothing yet as the normalization file needs to be configured first. Just as with OCS the Address Book does not leverage any Enterprise Voice normalization patterns which may have been created to support EV calling. Note that if the value is set to ‘False’ (Set-CsAddressBook –UseNormalizationRules $false) then even numbers already entered in +E.164 format will not appear in the Lync client.
- Locate the Lync Server’s shared directory which was configured during the initial server deployment. The file server FQDN and share name can be identified in the Topology Builder under File Stores
Browse to the share directory on the server and locate the ABFiles subdirectory.
\\lab1ls\LyncShare\1-WebServices-1\ABFiles
Create a new text file named Company_Phone_Number_Normalization_Rules.txt in the ABFiles directory. This normalization rules file must be stored in this location and not down a few directories where the actual address book files are stored as it was in OCS.
Edit the file with Notepad and enter the following example normalization and translation patterns. This rule will apply to the users configured with phone numbers in this standard 10-digit format: (312) 555-7500. (The first three lines are commented out and are not required in the text file.)
Up until this point anyone familiar with Office Communications Server should recognize that everything is about the same, other than the required location of the normalization text file. An improvement in Lync Server’s address book normalization process is instantly noticeable when looking at the simplicity of the example pattern above. In the past long, complicated regular expressions (regex) were required to filter-out any non-digit information which could be potentially stored in the telephone field.
But now Lync Server automatically ignores non-telephony related digits in the strings and only looks at the continuous 0-9 numerical digits (and also recognizes the + symbol). So there is no longer a need to include regex code like [\s()\-\./]* in patterns to ignore spaces, parenthesis, dashes, etc.
- Execute Update-CsAddressBook to import the new settings configured in the text file and apply them to numbers stored in the address book files.
- After 5 minutes have elapsed force an address book update on the Lync client as described in this article.
At this point the contacts previously not displaying phone number information should now be working.
Lync 2010 Bandwidth Management (CAC)
In this post I will show you how to configure CAC or bandwidth management and describe how the user experience will be when making calls where no bandwidth is available.
Imagine the setup below. Two network segments (10.164.28.0 and 10.164.25.0) with a router between. Two sites in the topology – Copenhagen and Odense. One user, a Lync Server 2010 SE box and a PSTN Gateway on both segments and the user is signed in to the local SE box. Both users are UM enabled in a dial plan hosted on the Exchange 2010 SP1 server in Copenhagen.
I want to configure CAC to disable all audio and video between Copenhagen and Odense. In order to do that I use the PS script below:
# Bandwidth PolicyProfile
New-CsNetworkBandwidthPolicyProfile -Identity AllBlocked -AudioBWLimit 0 -AudioBWSessionLimit 200 -VideoBWLimit 0 -VideoBWSessionLimit 3000
# Network Regions
New-CsNetworkRegion -NetworkRegionID DK1 –CentralSite site:cph1 -Description "Copenhagen"
New-CsNetworkRegion -NetworkRegionID DK2 –CentralSite site:od1 -Description "Odense"
# Network Region Links
$a=New-CsNetworkRegionLink -NetworkRegionLinkID rl1 -NetworkRegionID1 DK1 -NetworkRegionID2 DK2 -BWPolicyProfileId AllBlocked
# Network InterRegion Routes
New-CsNetworkInterRegionRoute -InterNetworkRegionRouteID nr1 -NetworkRegionLinks $a.identity -NetworkRegionID1 DK1 -NetworkRegionID2 DK2
# Creates a new CsNetworkSite and assigns that the bandwidth policy we just created
New-CsNetworkSite -NetworkSiteID Cph -Description "Copenhagen" -NetworkRegionID DK1
New-CsNetworkSite -NetworkSiteID Od -Description "Odense" -NetworkRegionID DK2
# Create new CsNetworkSubnets
New-CsNetworkSubnet -SubnetID 10.164.28.0 -MaskBits 24 -Description "Copenhagen" -NetworkSiteId Cph
New-CsNetworkSubnet -SubnetID 10.164.25.0 -MaskBits 24 -Description "Odense" -NetworkSiteId Od
# Setup bandwidth management
Set-CsNetworkConfiguration –EnableBandwidthPolicyCheck $true
Let’s assume that the above configuration is in effect and that Alice and Bob would like to call each other. There is not enough bandwidth available to setup the call and the call experience of Alice and Bob is therefore controlled by two parameters (EnableBWPolicyOverride and AllowPSTNReRouting) in the voice policy, they have been granted. In the table below I’ve described what the call experience will be given different values for the two parameters.
Imagine the setup below. Two network segments (10.164.28.0 and 10.164.25.0) with a router between. Two sites in the topology – Copenhagen and Odense. One user, a Lync Server 2010 SE box and a PSTN Gateway on both segments and the user is signed in to the local SE box. Both users are UM enabled in a dial plan hosted on the Exchange 2010 SP1 server in Copenhagen.
I want to configure CAC to disable all audio and video between Copenhagen and Odense. In order to do that I use the PS script below:
# Bandwidth PolicyProfile
New-CsNetworkBandwidthPolicyProfile -Identity AllBlocked -AudioBWLimit 0 -AudioBWSessionLimit 200 -VideoBWLimit 0 -VideoBWSessionLimit 3000
# Network Regions
New-CsNetworkRegion -NetworkRegionID DK1 –CentralSite site:cph1 -Description "Copenhagen"
New-CsNetworkRegion -NetworkRegionID DK2 –CentralSite site:od1 -Description "Odense"
# Network Region Links
$a=New-CsNetworkRegionLink -NetworkRegionLinkID rl1 -NetworkRegionID1 DK1 -NetworkRegionID2 DK2 -BWPolicyProfileId AllBlocked
# Network InterRegion Routes
New-CsNetworkInterRegionRoute -InterNetworkRegionRouteID nr1 -NetworkRegionLinks $a.identity -NetworkRegionID1 DK1 -NetworkRegionID2 DK2
# Creates a new CsNetworkSite and assigns that the bandwidth policy we just created
New-CsNetworkSite -NetworkSiteID Cph -Description "Copenhagen" -NetworkRegionID DK1
New-CsNetworkSite -NetworkSiteID Od -Description "Odense" -NetworkRegionID DK2
# Create new CsNetworkSubnets
New-CsNetworkSubnet -SubnetID 10.164.28.0 -MaskBits 24 -Description "Copenhagen" -NetworkSiteId Cph
New-CsNetworkSubnet -SubnetID 10.164.25.0 -MaskBits 24 -Description "Odense" -NetworkSiteId Od
# Setup bandwidth management
Set-CsNetworkConfiguration –EnableBandwidthPolicyCheck $true
Let’s assume that the above configuration is in effect and that Alice and Bob would like to call each other. There is not enough bandwidth available to setup the call and the call experience of Alice and Bob is therefore controlled by two parameters (EnableBWPolicyOverride and AllowPSTNReRouting) in the voice policy, they have been granted. In the table below I’ve described what the call experience will be given different values for the two parameters.
Subscribe to:
Posts (Atom)