lync 2013 enterprise voice: 10 deployment pitfalls to avoid · corpinfo page 2 of 13 lync 2013...
TRANSCRIPT
CorpInfo Page 1 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
Table of Contents
Abstract ____________________________________________________________________________ 2
Enterprise Lync Environment Overview ___________________________________________________ 3
10 Deployment Pitfalls & Avoidance Strategies _____________________________________________ 4
1. Calls routed incorrectly ____________________________________________________________ 4
2. Incorrect reverse number lookup (RNL) _______________________________________________ 4
3. Login issues with different internal and external domain names ___________________________ 6
4. Caller ID recognition issues _________________________________________________________ 6
5. Lync mobility issue _______________________________________________________________ 7
6. User adoption challenges __________________________________________________________ 8
7. Network bandwidth issues _________________________________________________________ 9
8. Proper phone number formatting __________________________________________________ 11
9. Lync 2010 to Lync 2013 Upgrade – OCS 2007 issues ____________________________________ 11
10. Lync 2010 to Lync 2013 Upgrade: Public Certificate Issue _______________________________ 11
Conclusion _________________________________________________________________________ 13
CorpInfo Page 2 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
Abstract
The deployment of any companywide solution requires proper planning, extensive testing, strong
project management, and meticulous implementation. Yet, many pitfalls may prevent a smooth
deployment and create challenges for the technical team. As solution complexity increases, so do the
number of potential snares.
Microsoft Lync 2013, is a complex technology that brings together voice, video, IM, presence, and
conferencing. It integrates with many applications including Microsoft Office and a myriad of third-party
software solutions that enhance its functionality. As such, Lync deployments require expertise and
coordination in many technical areas, spanning different teams and business units. A successful
implementation relies on a great understanding of the product, networking, company policies,
telephony, and user adoption issues.
This paper presents a number of common pitfalls encountered in a Lync 2013 Enterprise Voice
implementation and related strategies to avoid them. The areas covered in this paper include:
Call Routing
Active Directory
Telephone number formatting
DNS configuration
Network setup and bandwidth
Issues encountered when upgrading from a previous version
User readiness and adoption considerations
CorpInfo Page 3 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
Enterprise Lync Environment Overview
These findings are based on a Lync Enterprise Voice deployment. The environment consisted of a
headquarter location (HQ) and 5 branch offices with:
Lync 2013 Enterprise Front End pool containing two Front End servers
2 SQL 2012 Standard Edition servers in mirrored mode and a witness server
An edge pool and IIS ARR reverse proxy in the perimeter network
The HQ and branch sites were connected to the PSTN via digital gateways with PRI’s/SIP Trunking.
The solution was deployed enterprise wide, so the user base consisted of executives, executive
assistants, IT engineers, administrative officers, and sales and marketing teams. The organization
contains many business units with unique requirements. The end users’ level of comfort in utilizing new
technologies varied, ranging from highly technical engineers to employees with limited comfort with
new technical solutions. The decision on what end devices to deploy was dictated by the technical
readiness of the recipients. In addition to the Lync client interface (softphone), users received one
specific device or a combination of communication devices, including headsets and IP phones.
The Lync solution was also integrated with a third-party call center application to offer enhance call
handling capabilities, reporting and recording.
The end users’ level of comfort in utilizing
new technologies varied, ranging from highly
technical engineers to employees with limited
comfort with new technical solutions. The
decision on what end devices to deploy was
dictated by the technical readiness of the
recipients.
CorpInfo Page 4 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
10 Deployment Pitfalls & Avoidance Strategies
1. Calls routed incorrectly
When making a call from the Lync client, the behavior and call path are governed by the dial-plans and
voice routing configuration. Depending on multiple factors, a majority of the calls may ultimately route
through the PSTN/SIP trunk. In worst-case scenarios, even internal calls may ultimately route via the
gateway and PSTN. One reason for this is that the work number becomes the default called number.
Apart from setting the correct dial plan, translation rules, and routing rules, it is also beneficial to set the
client policy to call to “VoIP” by default. This can be accomplished using the following command:
‘‘Set-CsClientPolicy -Identity Global -EnableVOIPCallDefault $true’’
[Note: The change needs to be applied to all client policies and not just the global policy.]
This change will ensure that any call defaults to a Lync call instead of work number, mobile number, or
any other number listed in the individual contact. This will apply to all applicable calls including to a
federated user. Should the user desire to call a specific number (work or cell), the appropriate contact
can be chosen from the call options. This will reduce the usage of the PSTN/SIP Trunk channel and result
in cost savings over time.
2. Incorrect reverse number lookup (RNL)
Imagine a situation where the first instinct is to dial the extension of the person and not type the name.
More often than not, the number is normalized to an E.164 format and the call is routed via the
PSTN/SIP Trunk. The fact that the reverse lookup does not happen and the number is not replaced by
the associated user will cause frustration. It may also prevent the caller from choosing other modes of
communication such as “call mobile” or “call voicemail.” Even when the name of the person being called
is typed, additional phone numbers that are listed for that user in Active Directory may not be shown in
Lync.
All these situations occur when the address book is not properly normalized. This may cause the Lync
server to display the message: Event ID 21034 Source: LS Address Book Server.
The solution is to use address book normalization rules.
CorpInfo Page 5 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
The sample address book normalization rules have been installed in the ABS Web component file
directory. The path is:
$installedDriveLetter:\Program Files\Microsoft Lync Server 2013\Web
Components\Address Book Files\Files\
Sample_Company_Phone_Number_Normalization_Rules.txt,.
This file can be copied and renamed as Company_Phone_Number_Normalization_Rules.txt to the
address book shared folder’s root directory. For example, for the address book shared in $serverX, the
path will be similar to:
\\$serverX \LyncFileShare\2-WebServices-1\ABFiles.
To customize the rules, use a text editor, such as Notepad, to open the file:
Company_Phone_Number_Normalization_Rules.txt.
Type the normalization rules in the below format (these are just basic examples, one should customize
these based on what is applicable to one’s country and region)
(\d{10})
+1$1
(\d{11})
+$1
Save the file, and run the following commands in Lync PowerShell:
Set-CsAddressBookConfiguration -identity <XdsIdentity> -
UseNormalizationRules=$true -IgnoreGenericRules=$true
Update-CsUserDatabase
Update-CsAddressBook
Once the update is complete, Lync clients should be able to resolve the numbers to names and populate
the additional phone numbers.
CorpInfo Page 6 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
3. Login issues with different internal and external domain names
The proper configuration of public and private certificates are extremely important for Lync client
authentication. When an organization uses different internal and external domain names it is common
to receive an error message when logging in to Lync 2013 for the first time. The error states: Lync
cannot verify that the server is trusted for your sign-in address. The system will ask
for a verification to connect anyway.
It is recommended to implement pubic certificates on the Front Ends to reduce problems with the
installation of the root certificate on different devices in a BYOD environment.
4. Caller ID recognition issues
Caller ID information is a feature that end users expect and rely on regularly, particularly in their
communications with colleagues within the company and partners outside. When properly displayed,
the caller ID should be on top of the list for ease-of-use and proper communications. To ensure proper
caller ID displays, special care should be taken in porting the DIDs so that proper routes are created and
the required normalization rules are formulated.
In one instance, when a Lync user dialed the telephone number of another internal Lync user, the
company name (or PSTN circuit ID based on setting from the telephony service provider) was displayed
instead of the Lync user name. For a Lync to Lync call, using the recipient contact information, the caller
ID was identified properly; however if dialing the number through the client or using the desk phones,
the caller was not identified nor their contact information. This issue occurred despite the fact that DIDs
of both users had been migrated to the Lync PRI and the problem was consistent for all Lync users.
Similarly, users created in Lync could not see the caller ID/information of other internal users using the
existing TDM PBX voice services. Considering the majority of voice calls were internal to the
organization, this issue needed to be resolved before any new users were migrated to Lync.
The reason for this behavior was that the call was routed via the PSTN instead of directly going through
Lync.
The issue can be resolved by changing call routes. However, the more efficient solution is to add a
normalization rule to the Lync address book. The normalization rule changed the incoming calls from
PSTN trunks to the proper E.164 format. All incoming caller IDs were then being replaced with the
proper contact information through Active Directory Reverse Number Lookup (RNL).
CorpInfo Page 7 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
5. Lync mobility issue
It is critical for DNS records to have the correct entries. The Lync mobile client is heavily dependent on
external DNS servers to resolve names to valid corresponding IP addresses. Therefore close
coordination and communication with public DNS service providers is crucial for proper connectivity.
Ensuring the Lync audio and video calls function properly also requires attention and planning.
In this particular case, mobile devices failed to send or receive Lync calls outside the organization. The
endpoints were not retrieving the right “candidate list” and multiple verifications of the configuration on
the edge, Front End, and reverse proxy, led to no positive result. Router and firewall reports did not
show anything abnormal except that the communication was trying to reach the private IP address of
the devices, and that this communication failed.
Further research indicated that the external public DNS had an entry for the internal domain
(company.local) which acted as a catchall and that internal FQDN name lookups from the Internet
resolved to incorrect IP addresses. This resulted in the communication getting lost in the ether.
Unfortunately, the logs did not indicate any issues with the public DNS.
Correcting the DNS entries resolved the mobility connectivity issue.
The Lync mobile client is heavily dependent
on external DNS servers to resolve names to
valid corresponding IP addresses. Therefore
close coordination and communication with
public DNS service providers is crucial for
proper connectivity.
CorpInfo Page 8 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
6. User adoption challenges
One of the major challenges facing a Lync 2013 deployment is not a technical challenge, but a people
and operational challenge. The success of the Lync implementation is ultimately dependent on the end-
user experience and their perception of the solution as a useful tool.
Using softphones instead of traditional desk phones require some adjustment. Users have developed
certain habits that may not translate properly when using Lync. To make the most out of Lync, users
need to understand how and when to escalate calls from IM, to voice, to video, and when to add screen
sharing or conferencing to a call – this enables true productivity gains when used correctly.
Lync users may also need to allow a grace period at the start of the day for PC updates to run if required.
Additionally, Lync users need to understand that the extra flexibility that comes with using functionality
from home or when travelling is dependent on Internet quality.
One strategy to soften the adoption curve is incremental user training. The first session should introduce
the interface and cover the basics of making and receiving calls, initiating and responding to IM, and
using presence. Additional training should be available as the product is deployed to review the basics
and introduce more advanced features such as creating contact groups, transferring Lync sessions from
device to device, video conferencing, white boarding, and sharing desktop or applications.
It is best to develop a Quick Reference Guide (QRG) for each business unit to cover its specific needs.
The time spent on training and QRGs will prevent end-user frustration and reduce the amount of post-
implementation support required.
Executive assistants and users providing service over the phone (helpdesk and other support team
members) will require more in-depth focused training.
Lastly, since the attendant functionality was changed in Lync 2013, a third-party application may be
required to provide additional features.
The success of the Lync implementation is
ultimately dependent on the end-user
experience…One strategy to soften the
adoption curve is incremental user training.
CorpInfo Page 9 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
7. Network bandwidth issues
According to Microsoft TechNet notes*, if there is adequate bandwidth, implementing Quality of Service
(QoS) is not required. Determining whether there is sufficient bandwidth, however, may prove
challenging. As Lync voice services are used on a regular basis, the network experiences congestion and
call quality suffers.
To mitigate this problem, monitoring tools
should be implemented to analyze the
issue based on collected information, and
to identify congestion points to be dealt
with. The monitoring tools available with
Lync 2013 include daily, weekly, and
monthly communication, call diagnostics,
and system usage reports by user. These
reports encompass IM, VoIP, and audio
and video conferencing.
*http://technet.microsoft.com/en-
us/library/gg405409.aspx
CorpInfo Page 10 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
A Dashboard provides important details at a glance:
CorpInfo Page 11 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
8. Proper phone number formatting
The primary phone number assigned to Lync users is based on the entries in Active Directory. As such, it
is critical for these numbers to be specified with the proper format. Although it is possible to respond to
certain issues through number translations, if the numbers’ formats are not consistent (following a fixed
standard) the maintenance of all translation rules becomes too complicated. Phone numbers containing
extra characters, such as brackets, dashes, spaces and dots, lead to dialing errors.
The Active Directory database should be reviewed for format discrepancies, prior to Lync deployment.
9. Lync 2010 to Lync 2013 Upgrade – OCS 2007 issues
When migrating from Lync 2010 to Lync 2013, the technical team will face a number of additional
considerations.
If the existing Lync 2010 environment was migrated from OCS 2007, it is important to ensure that there
are no remnants of OCS 2007 left in the environment, especially Active Directory. A potential problem is
encountered when you attempt to move a user from the Lync Server 2010 pool to the Lync Server 2013
pool. The move may result in an error stating: Failed while updating destination pool.
The reason for the failure is that the inheritable permissions from the users account object were not
transferred. To resolve this, open up adsiedit.msc, navigate to the users account, open up the properties
and review the Advanced Security Settings of the object. If the “Include inheritable permissions from
this object’s parent setting for the user account” is unchecked, check the box and save the settings. The
user should now be able to be moved.
10. Lync 2010 to Lync 2013 Upgrade – Public Certificate issue
When installing a new Front End pool for Lync 2013, make sure to create a new external Web services
URL. Use the same name as the one used in the Lync 2010 pool. This step is often overlooked. The URL
needs to be set up in the public DNS and should also be a part of the public certificates. The same public
certificate from Lync 2010 cannot be used as is. It must be reissued with the new URL as part of the SAN.
CorpInfo Page 12 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
Conclusion
As any complex technology, the deployment of Microsoft Lync 2013 Enterprise Voice requires proper
planning and meticulous implementation. The success of the rollout is dependent on the soundness of
the existing IT environment, particularly the state of the IP network, available bandwidth, proper DNS
and AD configurations. In addition to the challenges involved with the implementation of a new
technology solution, the ultimate success of the project depends on the acceptance of the end-users
and their perception of the functionality of Lync. Proper user training and useful reference guides will
soften the adoption curve, while reducing the load on the internal helpdesk for assistance.
This paper has discussed and offered solutions to deal with a number of issues encountered in an
enterprise implementation of Microsoft Lync 2013. In planning, designing and deploying complex IT
solutions, engaging an experienced integrator or solution expert would often bring value to the
organization and help alleviate some of the challenges involved.
CorpInfo Page 13 of 13 Lync 2013 Enterprise Voice: 10 Deployment Pitfalls to Avoid
About the Author
Javeed Shaik is a Solution Architect at CorpInfo. Javeed has been architecting and implementing complex
IT solutions based on Microsoft Infrastructure offerings for over 15 years. He is focused on the design
and delivery of state of the art solutions to his clients around Microsoft Lync, Exchange and Active
Directory. He has over 10 years of experience in Messaging and 5 years in Microsoft Unified
communications. Javeed has extensive experience working with large multinational enterprises
including Fortune 100 and Fortune 500 customers.
About CorpInfo
CorpInfo is a leading technology firm based in Southern California providing Cloud Services, IT
Consulting, Infrastructure Solutions, and Managed Services since 1983. With decades of experience, we
ensure that our clients have the best technical solutions to solve their business challenges and bring
value to their organization. CorpInfo optimizes the value of IT investments by thinking “out of the box”
to solve specific or immediate challenges while laying the groundwork for future growth and flexibility.
CorpInfo
Corporate Office
1618 Stanford St.
Santa Monica, CA 90404-4114
Phone: (310) 442-3200
Fax: 310.442.3201
Email: [email protected]
For additional Information, please visit www.corpinfo.com. © K-Micro, Inc. dba CorpInfo Services, 2015