This blog post is part 3 of a multi-article series and is a continuation of this previous article:
Lync Server 2010 Deployment – Part 2

Update:  This process is identical to (and has been tested with) the public release version of Lync Server 2010.

The next step is to enable a few existing user Active Directory accounts for Lync so that client connections can be tested to the Standard Edition Front End server.  Notice that ‘existing users’ was stated as the Lync Control Panel can only enable AD user accounts and not create new user accounts; that must first be performed using Active Directory for Users and Computers (ADUC) or whatever similar tool is desired.

• On the Lync Control Panel select Users and then Enable Users.  Search for the first user account to enable (e.g. Jeff) Select a different user account than the one currently used to logon the Lync Server as an ‘insufficient rights’ error will be returned if an attempt is made to enable the current account.  Assign the user to the single pool in the environment and then generate the SIP address using the desired format (e.g. <SAMAccountName>@csvmp.net).  Leave the Telephony and other policies at the default setting for now, these setting will be modified later on.
• Enable additional accounts now so that this test user account will have at least one other account to contact within the Lync client.

• Sign-in to two separate clients with any of the new accounts and enter the names of the other accounts in the search bar.  Depending on if the previous address book files were downloaded or are still in the process then no results should appear, returning either “No results found” (address book was downloaded but no name was match found) or “The address book is preparing to synchronize”.

• Manually update the address book files using the process detailed in this previous article.

Now all standard modalities should be available between the clients, including IM/Presence, conferencing, and application sharing.  The next step is to enable these users for Enterprise Voice (EV) and then configure the Voice features in Lync Server so that not only will Communicator calls be available between them but also Enterprise Voice calling.

Enabling Enterprise Voice

Configuring Enterprise Voice is basically the same steps as it was in OCS but some of he individual steps are handled differently in Lync Server.  For example the OCS Location Profile has been replaced with a Dial Plan in Lync which is an expanded scope that is not just a global definition now but can also be assigned at the user, pool, or site level as well.

For the purposes of this lab a single site will be defined (Chicago) and a single block of telephone numbers will be dedicated to internal Lync users (312-555-75xx).  As usual a fully RFC3966 compliant numbering pattern will be used throughout the Lync and Active Directory fields and a basic 4-digit extension pattern will be added to allow for easy 4-digit dialing.

• Start off by setting the desired phone numbers on each AD user object in the Telephone Number field (telephoneNumber attribute).  Two different formats are shown in the example below.

Regarding the format used for the phone numbers there are two ways this can be approached.  The easiest solution which requires no additional configuration is to populate the numbers directly into RFC3966 format as in +13125557500.  Lync will display these by default as they require no normalization.  But if a more common display format of (312) 555-7500 is used then these numbers will not be normalized by Lync for contacts and require additional configuration of the Address Book service to be displayed in the Lync client.  See this previous blog article for more details on this process.

• Manually update the address book files using the process detailed in this previous article.

And in keeping with the running theme of pointing out differences between OCS and Lync another beneficial change can be seen at this point.  In OCS the was no default EV configuration; no location profile, no route, no normalization rules. They all had to be created from scratch.  But in Lync Server the Voice Routing section of the Control Panel will show that number of default configuration object are already defined: a default global dial plan (Global), a default route (Localroute), etc.

So instead of creating all these objects only some minor changes will be applied to customize them for the desired numbering plan.

A logical place to start out would be the dial plan, which will be customized with two new normalization rules.

• On the existing Global dial plan create a New Normalization Rule which will be used to properly handle many different formats of 10 and 11 digit strings.  This pattern is discussed in detail in one of my older OCS articles.

\+?[\s()\-\./]*1?[\s()\-\./]*\(?\s*([2-9]\d\d)\s*\)?[\s()\-\./]*(\d\d\d)[\s()\-\./]*(\d\d\d\d)[\s]*

+1$1$2$3

• Add another New Normalization Rule which will be used to support direct dial of 4-digit extensions in the 7500-7599 range.  This simple pattern will match against any 4-digit string starting with 75 and then translate it into a normalized RFC3966 pattern (+E.164).

^(75\d{2})$

+1312555$1

• Remove the default Prefix All rule and reorder the new rules so that the Extension Dialing rule is at the top.  This will not impact the functionality at this point as the only two records are mutually exclusive and do not overlap. But as a habit more specific records should be placed towards the top of the rules list and more generic rules should be towards the bottom.

• Save the changes to the Global dial plan and then Commit All changes.

Now a couple of the Lync-enabled user account need to be enabled for Enterprise Voice as well since all enabled accounts were previously only configured for PC-to-PC Communications.

• Search for and edit the properties of the two primary test accounts in the Lync Control Panel under Users.  Select Enterprise Voice for the Telephony setting and enter the user’s telephone number using the proper Line URI format.  Commit the changes to each user (e.g. tel:+13125557501).

• Sign-out and back into both Lync clients with the two updated test accounts and the first indication of the change should be the addition of the Call Forwarding menu at the bottom of the Lync client.

• To test Enterprise Voice calling for internal users as well as the extension-specific normalization pattern enter a 4-digit extension into the search bar and notice that both the normalized number and the resolved internal user are returned in the results.

Now would be a good time to define a phone number for the Conferencing Attendant, which can be performed using the Control Panel and is similar to the configuration used by OCS.  But before a Dial-In Access Number can be created a region must first be defined.

• Edit the Global Dial Plan under Voice Routing and enter a descriptive name for the Dial-In Conferencing Region (e.g. Chicago).  Then Commit All changes to apply the change to Lync Server.

• Under the Conferencing options select Dial-In Access Number and create a new entry, using a unique Line URI and SIP URI.  The Display Name and Display Number will be displayed on the Lync contact for this number.

Display Number

(312) 555-7555

 

Display Name

Conference Bridge

 

Line URI

tel:+13125557555

 

SIP URI

sip:confbridge@csmvp.net

 

Pool

lab1ls.csmvp.net

• Add an Associated Region and select the region created in the previous step (e.g. Chicago).

• Manually update the address book files using the process detailed in this previous article.
• Search for 7555 from the Lync client to show the new contact object (it is normal for it to appear Offline as the presence is not active on contact objects).

Deploying a Media Gateway

As this walkthrough is meant primarily for test usage in a lab this media gateway will be configured in a unique, yet applicable scenario.  As SIP Trunking becomes more common (which may be addressed in a future article) media gateways will be used less for a default route to the PSTN and more often to bridge Lync Server to an existing legacy PBX system.  So in this lab the routing configuration will be sending only calls to numbers in the r(312) 555-77xx range.  Later on a SIP Trunk will be configured with a default route to handle any calls outside of the defined 75xx and 77xx ranges.

A step which was skipped during the initial deployment in Part 1 must first be addressed: specifying a PSTN gateway. In my lab there is a NET Tenor AF configured on 192.168.207.5 and the Lync Topology must now be updated to reflect this.

• Launch the Topology Builder , download the topology from the existing deployment, and then save the latest configuration data to a .tbxml file.
• Locate PSTN Gateways and select the action to create  a New IP/PSTN Gateway and enter the IP address of the desired media gateway, changing the default port and protocol options to allow for TCP connections to the default listening port on the media gateway of TCP 5060. Normally a secured (certificate-based) TLS connection would be used and is recommended for all production deployments, but for the purposes of this article and the lab a TCP connection is used. Also some older media gateways do no have the ability to have certificates imported on them and thus cannot supported TLS connections.

• Edit the properties of the existing Mediation Pool and select Enable TCP Port on the Mediation Server and leave the default TCP port of 5068 which is the where the Mediation Server will listen for incoming TCP connections for the media gateway.

• Also click Add to associate the Mediation Server with the newly defined PSTN Gateway.

• Publish the topology to apply the changes for the Mediation Server configuration to the Lync environment.

• Modify the Global Voice Policy and create a new PSTN Usage Record (e.g. TenorAF), and add a new Associated Route using the setting in the following section.

Name

Analog Phones

 

Description

Routes calls to 77xx numbers to internal analog phones.

 

Match this Pattern

^\+131255577

 

Associated Gateways

PstnGateway:192.168.207.5

 

• Enter a sample telephone number (in it’s normalized end-state) within the route’s defined range to test the pattern match.

• Apply and Commit All changes.

At this point +E.164 numbers in the +131255577xx range will be routed to the Tenor gateway but the normalization rules will need to be updated to allow for 4-digit dialing of these numbers within Lync (e.g. 7701).  The simplest approach may seem to be to just create a new normalization rule to handle (7700-7799) digits, but because the internal Lync numbering plan is so similar (7500-7599) then the existing rule can be slightly tweaked to handle both ranges.

• In the Global dial plan edit the Extension Dialing normalization rule and edit the pattern.  Replace the 5 with [5,7] which will expand this regex rule to apply to both 75xx and 77xx (but not include 76xx) as the comma means to match either 5 or 7.

^(7[5,7]\d{2})$

• Commit the changes and tests both 75xx and 77xx extensions from the Lync client (a restart of the client may be required if testing immediately).

Well, that wraps up Part 3 of this series and nearly every feature on Lync Server has been activated for use.  Upcoming articles may focus on configuring Conferencing features, deploying currently available Lync Phone Edition devices (e.g. CX700/Tanjay), and finally Edge Server deployment to allow external access to all these features.  Exchange Integration for UM and IM features will also be covered.