92
Microsoft Lync Server 2013 Basic Administration Release 2.1 Author: Fabrizio Volpe
Microsoft Lync Server 2013
Basic Administration
Release 2.1
Author: Fabrizio Volpe
1
Acknowledgements
This book is dedicated to those who live every day with me, my family, Federico and
Antonella and to my parents. It is dedicated to Flavia who has just started her life, and
to my grandmother Ines who still lives in my thoughts.
There Ain't no Such Thing as a Free Lunch
You will read this book at no cost.
I hope the work that I am making available to you, which is the result of the end of an
interesting and complex collaboration with the publisher Manning Publications will be
useful to you in understanding and managing Lync. But I do not believe in free lunches.
So if this text will be useful to you, and you will have the desire to pay for it, I invite you
to make a donation to Save the Childrens or to another association for the protection of
minors.
Then you will have paid for your meal.
Disclaimer
This release “2.1” adds a full chapter (6, Firewall Requirements for Lync Server 2013) to
the previous work. Again, I had a great technical review and useful hints from Lync MVP
Thomas Poett (@ThomasPoett). The “Lync client debugging” paragraph you will find in
chapter 6 comes from his hands-on experience and is outstanding imho.
This time I had also another reviewer that gave me a great feedback not only on the final
draft, but also on the first versions I have published on my website. Alessio Giombini
(@AlessioGiombini), an experienced solution architect and Lync professional, gave a
fundamental help to this work. To both of them I say thank you. The Lync community is
a big place to be because there are people like you.
Cover image: Calgary skyline and a pedestrian bridge in Calgary, Alberta Canada. Used
under Extended Print RF License
2
About the Author
Fabrizio Volpe – Has worked in the Iccrea Banking Group since 2000, as Network
and Systems Administrator. Since 2011 he has been awarded Microsoft MVP on
Directory Services from Microsoft. In the year 2014 he has been awarded Microsoft
MVP on Lync. Fabrizio has authored books dedicated to the IT and security
professionals, has participated as speaker on well-known IT conferences and is
committed to creating content that is accessible to a wide number of people, so he often
publishes contents
on his channel on YouTube ( http://www.youtube.com/user/lync2013)
on his personal blog (http://blog.lync2013.org)
on SlideShare ( http://www.slideshare.net/fabriziov )
About the Reviewers
Thomas Poett - Professional, consistent, and experienced expert who is technically
savvy with over 20 years of experience in IT, telecommunication and software
development. Additional extensive experience in business and market development.
Specialized in intercultural and business relationship in Asia. Successful in providing
leadership on new topics and complex global projects that require interfacing with
internal/external teams and ecosystems. Early adaptor of visionary technologies. 20+
3
year career within different companies in the areas software development,
telecommunication, IT, mobility and hosted/cloud services.
Alessio Giombini - Alessio is an Infrastructure Solutions Architect, with a strong
focus in Microsoft and Unified Communications area. Over 15 years' study and hands on
experience delivering small to large-scale projects for major EMEA enterprise
industries, mainly based on Microsoft and other leading edge technologies, systems
applications and operations running on top of them. He has Broad and mixed technical
background in infrastructure and communications field, systems integration, Systems
Management, security, as well as an in-depth understanding of the business of
computing and networking in enterprise organisations. Currently works for InterCall
UK and his main tasks are Architectural design and delivery of Microsoft environments,
with specific focus on multi-vendor UC solutions, based on Microsoft Lync 2013 with
Enterprise Voice, Exchange Unified Messaging, migrations from Lync 2010 and OCS
2007, load balancers, reverse proxy, firewall, Exchange UM.
4
ACKNOWLEDGEMENTS ......................................................................................................................................... 1
THERE AIN'T NO SUCH THING AS A FREE LUNCH ...................................................................................................... 1
DISCLAIMER ......................................................................................................................................................... 1
ABOUT THE AUTHOR ............................................................................................................................................. 2
ABOUT THE REVIEWERS .......................................................................................................................................... 2
1 BEFORE YOU BEGIN .................................................................................................................................. 7
WHAT IS MICROSOFT LYNC 2013 SERVER? ............................................................................................................ 7
WHY LYNC 2013 MATTERS?.................................................................................................................................. 7
LOOKING AT LYNC 2013 FROM THE CLIENT ........................................................................................................... 8
LOOKING AT LYNC 2013 FROM THE SERVER ........................................................................................................ 13
ADOPTING LYNC: WHAT I NEED AND HOW MUCH DOES IT COST ........................................................................ 14
EXTRA COSTS TO BE AWARE OF WITH LYNC 2013 ................................................................................................ 18
FINAL WORD ..................................................................................................................................................... 19
2 BUILDING YOUR LYNC 2013 LAB ........................................................................................................... 20
PLANNING A MINIMAL WORKING INFRASTRUCTURE ................................................................................................ 20
INTERNAL LYNC SERVER SERVICES ONLY .............................................................................................................. 20
Try it now .................................................................................................................................................................. 21
LYNC SERVER AVAILABLE FOR EXTERNAL USERS .................................................................................................... 21
Try it now .................................................................................................................................................................. 22
EXCHANGE 2013 AND SHAREPOINT 2013 INTEGRATION ...................................................................................... 22
ASSEMBLING THE REQUIRED SOFTWARE AND HARDWARE ....................................................................................... 23
Virtualization ........................................................................................................................................ 23
Acquiring the Required Resources ................................................................................................... 24
REALIZING THE DEPLOYMENT SCENARIOS ............................................................................................................. 25
Try it now .................................................................................................................................................................. 25
DEPLOYING THE LAB ........................................................................................................................................... 26
Domain controller ............................................................................................................................... 26
Try it now .................................................................................................................................................................. 27
Lync Server Front End ......................................................................................................................... 28
Office Web Apps Server .................................................................................................................... 28
Reverse Proxy ...................................................................................................................................... 28
Lync Edge ............................................................................................................................................ 28
Exchange and SharePoint ................................................................................................................. 28
LAB ................................................................................................................................................................... 29
3 MANAGING USERS WITH LYNC SERVER CONTROL PANEL .................................................................. 30
INTRODUCING LYNC ADMINISTRATION FROM THE CONTROL PANEL ....................................................................... 30
CHOOSING BETWEEN THE CONTROL PANEL AND THE MANAGEMENT SHELL ........................................................... 31
POLICIES AND POLICY SCOPES IN LYNC ADMINISTRATION..................................................................................... 32
ROLES IN LYNC ADMINISTRATION ......................................................................................................................... 34
Try It Now .................................................................................................................................................................. 34
5
ENABLING AND CONFIGURING USERS ................................................................................................................. 35
ENABLING A USER TO LYNC ................................................................................................................................. 36
Pool assignment .................................................................................................................................. 37
SIP URI configuration ........................................................................................................................... 38
Telephony options .............................................................................................................................. 40
Dial plan policy ................................................................................................................................... 41
Voice policy ........................................................................................................................................ 43
Policy assignment ............................................................................................................................... 43
Try it Now .................................................................................................................................................................. 46
LAB ................................................................................................................................................................... 46
4 MANAGING CLIENTS, AND DEVICES WITH LYNC SERVER CONTROL PANEL ...................................... 48
SOFTWARE CLIENTS ............................................................................................................................................ 51
Try It Now .................................................................................................................................................................. 53
HARDWARE DEVICES .......................................................................................................................................... 54
MOBILITY ........................................................................................................................................................... 56
SOME THINGS YOU HAVE TO DO OUTSIDE THE CONTROL PANEL .......................................................................... 58
Try It Now .................................................................................................................................................................. 60
LAB ................................................................................................................................................................... 60
5 MANAGING USERS WITH LYNC SERVER MANAGEMENT SHELL ........................................................... 62
ADMINISTERING USERS FROM THE MANAGEMENT SHELL ....................................................................................... 62
ENABLE OR DISABLE LYNC USERS ......................................................................................................................... 65
Try It Now .................................................................................................................................................................. 67
MOVING LYNC USERS BETWEEN DIFFERENT POOLS ............................................................................................... 67
HANDLING POLICIES FROM THE MANAGEMENT SHELL .......................................................................................... 69
LAB ................................................................................................................................................................... 73
6 FIREWALL REQUIREMENTS FOR LYNC SERVER 2013 .............................................................................. 74
PLANNING A LYNC DEPLOYMENT THE RIGHT WAY: TOOLS YOU WILL LOVE (PART 1) ............................................. 74
THE BASIC DIAGRAM OF A LYNC DEPLOYMENT WE WILL USE IN THE CHAPTER ....................................................... 75
LYNC SERVER 2013: INTERNAL NETWORK ............................................................................................................ 76
Servers located in the LAN ................................................................................................................ 76
Servers located in the DMZ ................................................................................................................ 78
Try it now .................................................................................................................................................................. 80
INFRASTRUCTURE REQUIREMENTS .......................................................................................................................... 80
FIREWALL RULES REQUIRED FOR LYNC SERVER 2013 ............................................................................................. 81
6.1 NETWORK TRAFFIC FROM SERVERS IN THE DMZ TO SERVERS IN THE INTERNAL NETWORK ................................. 83
6.2 NETWORK TRAFFIC FROM THE SERVERS IN THE DMZ TO THE EXTERNAL NETWORK ........................................... 83
6.3 NETWORK TRAFFIC FROM THE EXTERNAL NETWORK TO THE SERVERS IN THE DMZ ........................................... 84
6.4 NETWORK TRAFFIC FROM THE SERVERS IN THE INTERNAL NETWORK TO THE SERVERS IN THE DMZ ..................... 86
6.5 NETWORK TRAFFIC RELATED TO LYNC CLIENTS IN THE INTERNAL NETWORK .................................................... 87
NOTES RELATED TO THE FIREWALL RULES REQUIRED FOR LYNC SERVER 2013 .......................................................... 88
6
VERIFYING A LYNC DEPLOYMENT IN THE RIGHT WAY: TOOLS YOU WILL LOVE (PART 2) .......................................... 89
VERIFYING A LYNC DEPLOYMENT IN THE RIGHT WAY: SOME HIGH-LEVEL DEBUGGING STEPS IF LYNC CLIENTS ON THE
EXTERNAL NETWORK ARE NOT WORKING ............................................................................................................ 90
LAB ................................................................................................................................................................... 90
7
1 Before You Begin What is Microsoft Lync 2013 server?
Lync 2013 server is a unified communication system. Lync is able to deliver instant
messaging (IM), audio conferencing, video conferencing, multi-party high-resolution
meetings and voice over ip (VOIP), as well as persistent chat. You can integrate Lync
with the public switched telephone network (PSTN) to offer full telephony features and
to replace existing IP PBX.
If we define unified communications (UC), usually it integrates:
Real-time communication services such as instant messaging (chat), presence information, telephony (including IP telephony), video conferencing, data sharing, call control and speech recognition
Non-real-time communication services such as unified messaging (integrated voicemail, e-mail, SMS and fax)
Talking about Lync there are some features missing from the aforementioned list.
Speech recognition, fax and SMS depend from third-party products while voice mail and
e-mail are "integrated" only if we interface with Exchange
Why Lync 2013 matters?
Lync server 2013 has the following benefits:
Integrates out of the box with Active Directory, Microsoft Exchange, and
Microsoft SharePoint
Uses Microsoft management tools to enable easier management
Grants access to external users and federated with UC partners and public IM
systems like SKYPE, via secured Internet access, reducing the costs (no dedicated
secure connection or VPN is required)
Act together with hardware from different makers in an agnostic manner
Lync is the probable winner in the confrontation for the control of the unified
communication market for the next few years. On one side, we have enterprises that
produce hardware and that have created a software interface to manage only their
products. On the other side, we have Microsoft, a software developer. Microsoft has
8
decided to make Lync compatible with as many hardware products (dedicated to voice
and conferencing) as possible. A large number of coexistence scenarios with other
unified communication solutions is also available. Finally yet importantly, Lync has high
quality interfaces for administrators and users that are proving to be the strong point.
Looking At Lync 2013 from the Client
One of the best ways to get an idea of the capabilities of Lync is to open one of the
available clients, as I did in figure 1.1.
Figure 1.1 Full Lync 2013 client with presence indicators
As soon as a user logs into Lync, he uses the first feature of Lync called "rich presence".
Virtually all the people connected and enabled to our Lync infrastructure (colleagues,
employees of partner companies or business associates) display the rich presence
indicator as a “status marker”. Rich presence is like a simple traffic light with green,
yellow or red colors. It shows whether the person is able (and willing) to communicate
with us in a direct way (green indicator) rather than receive messages using a non-real-
time method (yellow or red indicator).
In the first situation, if you need to communicate with the other user, an instant
message or a call are a good solution, while you could prefer e-mail or invitations to a
scheduled meeting for a “busy” contact.
9
Rich presence status in Lync includes a set of information that allow the user to specify
the reason why he or she is not available. You can see the indicators summarized in the
following figure
Figure 1.2 a quick look at the presence status you can use in Lync client 1
Presence indicator of Lync are extended also to Exchange and SharePoint, so if we are
going to write a mail message or to organize a meeting, we know the presence status of
other users as you can see in figure 1.3
Figure 1.3 scheduling a meeting in Outlook for Lync enabled users. Some of them are “busy” at the moment
1 Via an individual configuration, based on standard xml files, those presence indicators can be
enhanced with up to 4 additional, corporate based standards (see
http://technet.microsoft.com/en-us/library/gg398997.aspx )
10
Other Microsoft and 3rd party vendor application, e.g. Microsoft Office, Dynamic CRM
or most of the web based application also support a native integration with Lync Client
API. This enables us to start a quick communication regardless what we are doing.
Figure 1.3a Contact in Microsoft Word
I just mentioned the possibility to see the presence status of contacts that are not part of
our company. That is achieved using a further feature, Lync federation. Federation is
the capability of two companies with a Lync infrastructure to extend functionalities (IM
but also conferencing and voice) to each other if they establish a trust relationship. The
federation feature has been improved recently to include Skype users. Lync 2013 can
federate also with non-Microsoft services based on XMPP. You can see an example of
Lync users shown inside a Skype client in figure 1.4
Figure 1.4 Lync users are available in Skype if their company is using federation
11
Instant Messaging (including the ability to exchange files between users) and the
direct video conference between two users are an experience similar to what you
may have already seen in other systems like Skype. One feature often not available in
other UC systems is the capability to use a web interface (the Lync Web App) to
enable people with no Lync client installed on their workstation to participate in a
meeting. In figure 1.5 you can see the logon screen for the Web App
Figure 1.5 the Lync Web App plug-in is required if you want all the meeting features
Lync 2013 Web App comprises all the possibilities, including participation in audio and
video (in Lync 2010 it was limited to IM). This tool broadens the participation to those
who are working on a temporary workplace. External users using the Web App are able
to take part to a Lync meeting with an interface they are familiar with (as you can see in
figure 1.6)
Figure 1.6 a Lync meeting seen from the Lync Web App. Voice and video are available in the browser
Lync 2013 for Mobile clients is another tool that will expand your Lync user base. It
is available for Windows Phone, iPhone, iPad and Android. As you can see in the next
12
figure, the mobile client includes almost all of the features comprised in full client,
including video conferencing and VOIP functions.
Figure 1.7 doing a video call from a Windows Phone is no longer a big problem
The quality of this new mobile client is a major asset of Lync 2013, and it is very popular
with top management in the companies.
A series of plug-ins and third party packages exists to optimize the Lync client in a
virtualized working place (including both virtual desktops and remote desktop
services).
Lync includes a feature known as persistent chat that lets you create “rooms”. Rooms
are a way to categorize IM messages and preserve them. Anytime a user needs to read or
update a conversation, it is available on the server.
To complete this quick overview of the client side of Lync, I have to talk about the
enterprise voice features. Lync can replace seamlessly an IP PBX and provide all kind
of service you can expect from a VOIP solution. It is also easy to integrate with pre-
existing solutions (such as the Cisco CUCM). Extending the voice functionalities to users
connecting from an external network requires only the Lync client we have already seen
Available Mobile Clients are:
Windows Phone 7.x (Lync 2010)
Windows Phone 8 (Lync 2013)
Windows App (Lync 2013 App)
iPhone
iPAD
Android
13
Lync server 2013 supports also hardware desk phones like the ones you see in figure 1.8
Figure 1.8 some desk phones you can use with Lync Enterprise Voice
Adding support for more traditional-looking devices like the aforementioned ones, Lync
give to the users the capability to choose between these telephones and headsets
connected directly to the computer (a more practical choice especially for mobile users).
Looking At Lync 2013 from the Server
Often, as a Lync administrator, you will see the infrastructure and features from the
server point of view. There are many tools to help you managing or debugging a Lync
deployment but the two main instruments, the ones you will use for day-by-day tasks,
are the administrative graphical interface of Lync (Lync Server Control Panel) and
the administrative command line (Lync Server Management Shell) based on
PowerShell.
You can see both of them in figure 1.9
Figure 1.9 the Control Panel and the Management Shell side by side
14
The Control Panel is the tool you can use for around 80% of all the administrative tasks.
The remaining 20% is available only in the Management Shell (that includes also all the
features you have in the Control Panel).
Adopting Lync: What I Need and How Much Does It Cost
Lync clearly distinguishes between two editions (Standard and Enterprise). The
basic server license costs the same in the two versions. However, the kind of edition you
will use has an impact on the available continuity features and on the number of
required servers.
To understand the aforementioned differences, it is required to explain also Lync server
“roles”.
Roles:
Every role grants to the infrastructure one or more Lync features
Roles can be held by one or more Lync server at the same time
Roles make the architecture of Lync Server 2013 highly scalable. A deployment in a
small business with no external users can consist of a single standard edition server,
with the role of Lync Front End. This is because the Lync Front End is the
fundamental role, and runs a great part of the basic Lync Server functions.
Adding to the scenario an Active Directory server (Directory Services are required for
Lync) and a server with Office Web Apps installed (this is required for PowerPoint
presentations inside a Lync meeting) we have the fully functional (internal) Lync
deployment you can see in figure 1.10
Figure 1.10 a minimal infrastructure that will grant Lync features to our internal user
15
Users are “homed” on a Front End and their capability to work with Lync depends on
the availability of this role or of a server able to replace their home server in case of
errors.
The solution based on standard edition is interesting, especially to keep the costs as low
as possible.
It requires no additional licenses outside a single standard edition of Lync and does not
use an external database, as is the case for the enterprise edition. This kind of solution,
based on a single “box”, has its limits. Lync standard edition cannot guarantee high
availability. There is, as you will see, a method to “pair” two Front End server to grant
resiliency but this is not automatic and requires operations by the Lync administrator.
The enterprise edition deployment is more expensive and complex. At least two Lync
Front End servers are required to create a Pool. It also requires the deployment of a
load balancer. This is required due to session persistence for http/ https.
A pool is a group of servers with identical configuration that provide high availability. In
a pool Lync features will be available even if one server goes offline. The functional
databases of Lync aren’t cohosted on the Front End (as it was for the standard edition)
but are active on an external SQL server. If we need also database continuity, we are
able to use the SQL mirroring mechanism. Clustered SQL installation is supported too,
but you have to keep in mind that this kind of high availability is focused on the SQL
server itself and does not give the additional continuity to the database that we have
with mirroring.
In Lync high availability of the server roles requires the deployment of pools.
16
In figure 1.11 you can see a plan for a Lync deployment with an enterprise edition Front
End pool.
Figure 1.11 a plan for a Lync deployment including a pool for Front End high availability
Office Web Apps is not a Lync role, so if you need it in high availability you have to use
its mechanism that is deploying a “farm”.
The cost of this solution derive from:
From licenses for Lync enterprise edition servers
From SQL server licenses, needed to create the Lync database infrastructure,
called Back End.
Note: SQL 2012 Licensing Guide states that, if the second SQL server is used only as
a “passive” copy, you need only a single SQL license (the one for the first server)
http://download.microsoft.com/download/7/3/C/73CAD4E0-D0B5-4BE5-AB49-
D5B886A5AE00/SQL_Server_2012_Licensing_Reference_Guide.pdf
Usually the next step after the installation of services for the internal network is the
exposure of the Lync features to external users.
To achieve the aforementioned result you are required to deploy a Lync Edge server
and a reverse proxy.
The Lync Edge server is a Lync role installed on a standalone machine, typically located
in a perimeter network and not added to the Active Directory domain. Lync edge makes
audio, video and conferencing services of available to the external users in a secure
17
manner, acting like a “man in the middle” that receive requests from the Internet and
forwards them to the Lync Front End. There is no direct connection between the user
and the Lync servers on the internal network.
A reverse proxy is similar to a Lync edge, but it exposes safely the web functionalities
(like the Web App, Address Book or Simple URLs) of the Front End, placing itself in the
middle between the client and the target server.
A reverse Proxy solution could be Microsoft TMG, Microsoft IIS ARR, Microsoft Web
Application Proxy (2012 R2) or any other supported firewall.
In figure 1.12 , you can see a schema including the servers required for external users
access.
Figure 1.12 schema with a perimeter network and the servers required for external user access
Adding the Lync edge and a reverse proxy does not require additional costs, because
edge requires no license and there are many free solutions to deploy reverse proxy
functionalities.
Talking about Lync roles there are some of them that I have not mentioned yet:
Monitoring is a role dedicated to the registration of quality parameters and to the
related reporting.
Archiving role saves the contents of IM communications for legal and compliance
requirements and archives IM, Conferencing and Persistent Chat.
18
In Lync 2013 server monitoring and archiving role are always collocated on the Front
End. The decision to make is whether these roles are required. Monitoring is very useful
for troubleshooting and gains additional value if you use the enterprise voice. The
presence of archiving is related only to legal constraints.
Persistent Chat is a role that enables the creation of IM “chat rooms”. You will be able
to create thematic areas and the room are persistent. A user can re-read the
conversation or add something at any time. A function like this makes sense, for
example, to create a corporate knowledge base. Persistent chat can be collocated on a
standard edition Front End or deployed as a dedicated server (or pool).
Mediation server is required to operate the enterprise voice (it manages the
"signaling" data stream). In Lync 2013, the hardware requirements have been reduced
due to the presence of the media bypass (which will be discussed in the chapters devoted
to the implementation of voice). This innovation allows collocating the mediation as a
role on a Lync Front End. The possibility of creating a server or a pool of mediation is
still available.
Director is a role that manages user authentication before they connect directly with
Lync Front End. In Lync server 2013 this role is not really useful. It could provide an
additional layer of security but director adds (also) a potential critical point.
Extra Costs to Be Aware of with Lync 2013
During the previous explanation, I have not mentioned some costs that have their
importance in the design of a Lync solution. The first aspect to consider is the cost of the
base operating systems on which we will install Lync and the required additional
servers (Office Web Apps and reverse proxy). Lync supports installation on a virtual
environment, so we could use the “virtualization rights” of Windows to reduce costs (for
example, the Datacenter edition of Windows 2012 allows you to install unlimited virtual
machines on a single physical host). Nevertheless, a complex structure, such as the one
with a Front End pool, will also require a significant expense for the base operating
systems.
The second aspect is the cost of client licenses. Lync requires a CAL (Client Access
License) for each user or machine that logs on to the server. CALs are of three types and
each one is entitled to the use of a part of the features. Access to premium functionality
is determined by adoption of the Standard CAL and then you have to add
19
supplemental CALS, an Enterprise CAL and, for some additional features, a third
license called Plus CAL (you may think to Enterprise CAL and Plus CAL as
supplemental to the Standard CAL).
Standard CAL: offers IM (Instant Messaging) and Presence, as well as PC-PC
audio and video communication
Enterprise CAL: the user can use multi-party Lync meetings (including Gallery
View, a feature allowing up to five active video streams to be displayed at once)
and PSTN conferencing dial-out..
Plus CAL: enables enterprise voice capabilities
The Lync 2013 client software can lead to a further increase in costs. The full Lync 2013
client for desktop is available as part of Office 2103 Plus or as a standalone application
under an Enterprise Agreement contract, so we'll have to consider the cost of this
package. The free alternative (Basic client for Lync 2013) has some limitations, for
example the Lync enterprise voice features are scaled down for such a client. It is also
possible to keep on using the pre-existing Lync 2010 clients but, however, the choice of a
client solution requires a proper assessment of the costs.
Note: Lync CALs:are additive, so possible combinations under the licensing agreement
only are:
Standard CAL
Standard CAL + Enterprise CAL or Standard CAL + Plus CAL
Standard CAL + Enterprise CAL + Plus CAL
Final Word
This brief overview has introduced concepts that you will see in detail throughout the
book. Many of the ideas presented here will make a greater sense when viewed in their
context, then I invite you to start with the first main chapter, Building your Lync 2013
Lab.
20
2 Building your Lync 2013
Lab
Usually a book like the one you are reading starts with a step-by-step installation
procedure of the product. This chapter is dedicated to help you building up a laboratory
to study Lync 2013 with a high-level overview of the required resources and of the
different operations from a logical point of view.
Planning a minimal working infrastructure
I will consider three different scenarios for the test bed. Each one will be the base
building block for the next:
internal Lync server services only
External users enabled to Lync services
Exchange 2013 and SharePoint 2013 integration
In paragraph 2 I will survey the different tasks related to the hardware and software
required and the available solutions to make the aforementioned settings work.
Internal Lync Server Services Only
Lync is based on Active Directory, so the first mandatory server you have to deploy is
not Lync but a domain controller. The good news is that this server will be used for more
than a single role and it can also be your DNS (names resolution is a critical aspect of
Lync) and your enterprise C.A.
The second server of you list should be a Lync Front End joined to the domain.
NOTE: We are talking about a lab with limited resources. Anyway this is a server that
needs at least 3 Gb of RAM (else Lync installation will not start at all).
An additional requirement is an Office Web Apps server for the PowerPoint
presentations during meetings.
21
With the three servers above, you have a working Lync environment. It is a good idea to
add a virtualized client to test the behavior of a Lync user inside and outside the domain.
Your lab should look like the one in the next figure
Figure 2.1 the basic lab environment
With the above deployment (and adding a DHCP server on your domain controller) you
could even test a Lync phone edition.
Try it now
Are you able to install Lync Front End with no Office Web Apps server available? What
are the consequences?
Lync Server Available for External Users
If you want to test also the external user access, you have to add a Lync Edge and a
software or hardware to reverse proxy Lync Front End services (for example IIS or
Forefront TMG). An additional requirement will be to simulate the most common
scenario, a DMZ network between the Internet and your internal network. You could
achieve the result with a schema like the one in the next image using Forefront TMG as
a three legged firewall, configuring RRAS on a virtual Windows server or using a
hardware to simulate the network topology.
NOTE:
Under all circumstances, if you deploy Lync Edge Server in a real, fully supported
environment, you MUST ensure that each Edge Server is deployed with TWO network
interfaces , one for internal and the other for external access!
22
Figure 2.2 lab environment with three simulated networks
Try it now
Accepting to work in an unsupported scenario to limit the number of servers required,
are you able to deploy Lync for the external users with no reverse proxy? Is it possible to
achieve the result without the Lync Edge server?
Exchange 2013 and SharePoint 2013 Integration
Exchange and SharePoint add a lot of interesting features to Lync (Unified contact store
and high resolution images from Exchange 2013, skill based search with SharePoint
2013). With Exchange you should consider also the Unified Messaging feature to
integrate voice mail and other voice services. Also, to explore the integration between
Lync and Outlook you will need to “mail enable” your Lync users with an Exchange
mailbox. The lab at this point is not easy to deploy and manage as the ones we have seen
before
23
Figure 91630_2_3 lab environment with Exchange and SharePoint deployed
Assembling the required software and hardware
So, we are going to build working lab environments. One driver is (usually) keeping a
low cost (in terms of space, money and time required). Which are the resources we need
to save the much? What we are able to keep on a virtual environment and what we need
to install on a dedicated hardware?
Virtualization
Let’s start from the last of the aforementioned aspects: Lync 2013 enables virtualization
of all the Lync roles. Also, almost everything in the infrastructure that will support you
deployment or add features (domain controllers, mail servers and so on) is virtualizable
too. This is really important and will help you obtaining the first objective (learning
Lync with the least effort) and adds the support for snapshots, so you are able to test
configurations and rollback with a simple command. If you have access to a SIP trunk
(or you can simulate it, for example with a second Lync deployment or an alternative
voice solution like Asterisk) you are able to learn a lot of things about Lync Enterprise
Voice with no required dedicated hardware. If you are able to buy a Lync desk phone
and a switch you are able to explore also the management of telephony hardware with
24
Lync. So, what you will miss with such a solution? Well, what you cannot expect is the
working knowledge on how to configure third party voice gateways, IP PBX and so on.
That is something important that you will have to learn (probably) on the field, hoping
that the vendor documentation is as good as possible.
Acquiring the Required Resources
First let’s examine the single resources you will need. After the next paragraph (in which
you will see the different deployment scenarios) I will try to propose best way to
obtaining them.
RAM (memory): it is a costly asset to attain. On laptops and desktops the maximum
memory you are able to use is limited by the hardware, and a really good motherboard
could use up to a maximum of 32 Gb (but you have to consider the costs of the memory
modules too).So one of your focus will be on creating the required infrastructure using
the less memory possible. A limit here is usability because often you are able to keep
some servers up and running with few Mb of RAM but their performances will be so bad
that they will be like unusable. Virtualization can be of help supporting dynamic
memory but required memory is often a bottleneck anyway.
Hard disks: usually allocating disk space to the servers is fast and cheap (especially if
we are talking about a virtualized deployment). Disk performances may create an issue.
The more virtual machines you put on a single disk physical, the slower they will work.
Again, the solution here could be adding disks (easier on a desktop), to distribute the
files of the virtual servers on external disks or using SSD disks (costly).
CPU: this is a resource that usually overpowers the requirements. If you have a good
x64 processor with multiple cores and hyper threading enabled, that is something you
don’t have to worry about.
Networking: if you want to try also the access for external users you will have to
simulate an “Internet” network and an internal one (with your edge server and reverse
proxy acting as an entry point to your Lync deployment). You could use an hardware
(SOHO firewalls and routers are really cheap) or a software (a virtualized Windows
server system with routing and remote access enables)
SSL Certificates: in a test environment you could use an internal C.A. to create and
distribute your certificates. Keep in mind that in a real world scenario a third party C.A.
is the easiest way to expand Lync services to external users and to avoid headaches and
problems.
25
Software: for the base system (hyper visor) you can use a free product (Microsoft and
VMware offer good solutions). The servers you are going to deploy (Windows 2012 or
Windows 2008 R2) and the back office software you need (Lync, Exchange, Forefront
TMG and SharePoint) are usually available as 180 days trials so this should be the
cheapest and easiest asset to find.
Realizing the Deployment Scenarios
I will base my following explanation on a virtual environment. For a physical deploy the
setup of the different servers requires additional work and complexity (that is an overkill
for a test deploy in my humble opinion). To realize the “internal Lync server services
scenario” a single laptop / desktop with a hyper visor, at least 8 Gb of RAM and a fast
hard disk is enough.
The addition of services accessible from the Internet (second scenario) requires two
additional severs and may be too heavy for a laptop. A good desktop with 12 Gb of RAM
and a couple of disks where you can distribute the different virtual machines could be
enough.
For the “Exchange 2013 and SharePoint 2013 integration” deployment you could try
with a really good desktop (with as much RAM and as many disks as possible) o with a
refurbished server hardware (there are good opportunities to buy old hardware that fits
with your needs with an affordable price).
Another solution I have tried is to buy some virtual private servers on the cloud, from a
hosting provider. They are cheaper than buying the hardware, require no space or
maintenance on your side and often offer public IP addresses, so that you do not need to
simulate the Internet because you have a real directly connected server. The drawback
in such a solution is that the more servers (and time) you need, the more you are going
to spend. So, such a solution is a good one only if you are going to concentrate your tests
and study in a short time.
Try it now
If you need to test a specific aspect of Lync, like the deployment of a Front End or of a
Lync Edge, try the Microsoft Ignite virtual labs http://lynclabs.vlabcenter.com/Signin .
They are free, available to Microsoft customers and Partners and give you a virtual
environment (limited by time) that you can use according to the steps that will be
outlined in the lab or to test feature that you want to verify hands on.
26
Deploying the lab
Starting with the “Internal Lync Server Services Only” scenario you have to deploy:
A domain controller
A Lync Front End (Standard Edition)
An Office Web Apps Server
Domain controller
Lync will use the following servers as a base infrastructure:
Active Directory
DNS
Certification Authority
Lync interacts with Active Directory to build up the infrastructure, modify the schema,
the forest and the domains so that new classes and attributes are created. One of the
boundaries is that you can have only one Lync organization for every forest. It is
required to have at least a Windows 2003 level for the forest and for the domains.
DNS : Lync requires the capability to resolve all the names involved in the
infrastructure, including both the ones associated with the internal domain and the ones
related to the public name (or names) of our company. The latter are usually defined SIP
domains for a company (Session Initiation Protocol or SIP is the protocol used to
initiate or terminate live communication sessions). That makes sense because your
users will log into Lync always with the same SIP address (or by using their mail
address) regardless of their location (tablet outside our company, desktop joined to the
domain and so on). So the internal DNS must be able to resolve the public names of
your domain AND must be able to route the requests to network addresses that are
inside our network. To achieve this result two solutions are available: split DNS (that is
hosting a “fake” public zone on the internal DNS) or to use PinPoint zones, that enables
you to point single public names to internal IPs, without the need to manage the whole
internal copy of the public zone that is typical of the split brain scenarios.
To create a PinPoint zone (for a example for meet.lync2013.org to point to
192.168.1.100), you can use the following commands from a command prompt on the
DNS server.
27
dnscmd . /zoneadd meet.lync2013.org. /dsprimary
dnscmd . /recordadd meet.lync2013.org. @ A 192.168.1.100
In the next image you can see the messages resulting from the dnscmd commands
Figure 2.4 successfully pinpointing the meet record for the Lync Front End
Note: if you try the aforementioned commands from PowerShell, only the first one will
succeed.
Note: Regardless, of the kind of DNS records that you will use, it is important to fully
understand the impact you create for the Lync Clients. Lync Client use a given
procedure to identify their Lync Server, based on the user’s SIP Domain
(“@domain.com”). The process is based on SRV DNS records. For our Test Lab, we will
not go into more detail.
Certification Authority: the whole Lync system is secure by design and communication
travels only in a secure from. That is why certificates are really important in Lync (base
services will not event start if there is an issue with certificates). For a test environment
the C.A. installed on the domain controller is all we need to create internally the
certificates required for internal and “Internet connected” servers.
Try it now
Pinpointing can be done from the graphical interface too. Try it and evaluate what
method best fits for you
28
Lync Server Front End
Talking about the lab deployment what I suggest is to install Lync Standard Edition, and
collocate the Monitoring role, the Group Chat role and the Mediation server.
Note: to collocate the Monitoring role, you need to deploy also the monitoring reports. The whole process is well
described on the Matt Landis’ blog http://windowspbx.blogspot.it/2012/07/aaa-donotpost-install-lync-
standard.html
Office Web Apps Server
The installation is well described on the TechNet article Deploy Office Web Apps Server
http://technet.microsoft.com/en-us/library/jj219455.aspx . Only warning here is to select
and remember the internal and public name of the server, because they will be required
for certificates and for Lync Topology building.
You have additional requirements for the second scenario “Lync Server Available for
External Users”
Reverse Proxy
Microsoft does not suggest a specific solution for the Lync 2013 publishing process.
With TMG on the road toward the end of life, a viable solution is to use IIS as a reverse
proxy. Such a solution is outlined on the NextHop blog Using IIS ARR as a Reverse
Proxy for Lync Server 2013
http://blogs.technet.com/b/nexthop/archive/2013/02/19/using-iis-arr-as-a-reverse-
proxy-for-lync-server-2013.aspx
Lync Edge
Lync Edge installation ill be discussed in chapter 25. In a test environment I suggest to
use the hosts file on the edge server to resolve the names of the internal Lync
infrastructure.
Exchange and SharePoint
The setup of Exchange and SharePoint is tied to the version of the aforementioned
servers you are going to deploy. Lync is able to integrate with Exchange 2007, 2010 and
2013. SharePoint is supported if the selected release is 2010 or 2013.
Some hints here:
29
In Exchange 2013 there is no UM role:
The functionality is into the Mailbox server role.
Client Access server role provides the UM Call Router service
Server-to-server authentication and authorization, OAuth (Open Authorization)
is a protocol required by Lync Server 2013, Exchange 2013 and Microsoft
SharePoint Server User credentials and passwords are not transmitted from one
computer to another (OAuth is based on the exchange of security tokens) Tokens
grant access to a specific set of resources for a specific amount of time
Lab
The configuration of OAuth can be started from Lync 2013 “Assigning a Server-to-
Server Authentication Certificate to Microsoft Lync Server 2013”
http://technet.microsoft.com/en-us/library/jj205253.aspx or from Exchange 2013
“Integrating Exchange 2013 + Lync 2013 for UCS & OWA integration” http://memphistech.net/?p=280
Try both the methods and evaluate pros and cons of the different approaches.
30
3 Managing users with
Lync Server Control Panel
The Lync Control Panel is the first administrative tool you’ll head to after the Lync
installation is complete. Around 80-90% of all the administrative tasks can be managed
with this graphical interface (the remaining operations will be limited to the Lync Server
Management Shell that I will explain starting from chapter 5).
This chapter is ideally split in two base topics:
An high level overview of the Control Panel and of some fundamental concepts of
Lync administration (policies, policy scopes and administrative roles)
A complete explanation of the user configuration parameters available in the
Control Panel, including pool assignment, SIP URI configuration, telephony
options and policy assignment
Introducing Lync Administration from the Control Panel
If you are not a PowerShell expert and if your Lync deployment does not require
frequent troubleshooting, the Control Panel is the tool you will use more often in the day
by day administration of Lync.
The first operation you will usually perform in the Control Panel (and the one that is
suggested by default) is to enable users to Lync. The aforementioned operation may
sound logical if we ignore one basic fact: the configuration your user will receive is based
for a large part on Lync policies and rules while his / her Enterprise Voice configuration
will depend largely on the dial plans and voice routes you will deploy in your company.
So the unspoken assumption here is that before enabling the first user you should have
all the required settings already in place and the planning for voice, workload balancing
and so on done by this time.
My personal experience says that usually (for a lot of good reasons) you will have to
enable users to Lync and later modify the user settings accordingly to the configurations
you will deploy in a second moment.
31
So let’s examine some of the steps you need to take if you’re going to enable our users
(Patricia Johnson, Peter Duggan and Julie Penny) to Lync keeping in mind their
different needs. Summarizing what we said about here in the 1st Chapter, they will
Enterprise Voice (for Julie with the external access prefix configured, for Peter with
delegation), mobility, conferencing (with gallery view feature for Patricia) and
federation with an XMPP external provider (again for Patricia).
Choosing Between the Control Panel and the Management Shell
A decision you need to make before you begin the actual work is about what tool you will
use. As I said at the beginning of the chapter, Lync 2013 enables management from a
graphical interface (Lync Server Control Panel) and a command line (Lync Server
Management Shell). Managing with a GUI is easier, but for example, if you are going to
enable a large number of users with a batch modification, the best tool it the
Management Shell.
The Control Panel may be confusing because you will have all the administrative
interfaces available, including ones related to features that you have still not deployed
(and ones that you will never use). Looking at the next image, for example, you see the
Persistent Chat tab in the Control Panel of a Lync deployment that does not have
persistent chat enabled.
Figure 3.1 The Home screen of the Control Panel
32
Now, before actually doing administrative operations, let’s translate the information we
about Patricia in a list of Lync parameters: she will need a telephone number, reachable
from the public telephone system with an internal extension (I will use 1(555)555-5555
and her extension will be 5555). The company dialing habit is to add the 9 before dialing
an external number and we want to keep this pattern. Patricia will be enabled for the
advanced voice features, including call transfer, simultaneous ringing, and so on and
from the video conferencing point of view she will use also the gallery view (multiple
simultaneous video streams).
Policies and Policy Scopes in Lync Administration
The whole Lync experience of our users will be dictated by the policies we apply to them,
to the Lync site (i.e. network location), to the Lync Pools and to the organization as a
whole.
When your scope is to create a configuration or constrains for the larger part of your
users it is advisable to use a global policy. The default policies that Lync applies just
after the installation phase are all global ones. Let’s say, for example, that Lync2013.Org
has an internal policy to deny delegation (a feature that enables users to specify other
users to send and receive calls on their behalf). To address a requirement like that we
will work on a global policy (a Voice Policy with a global scope, to be more specific)
As said, policies apply in a hierarchical order, which is illustrated in the schema below:
33
The policy will apply to all the Lync infrastructure (see figure 3.2)
Figure 3.2 a global policy with delegation not enabled
Few Lync users like Peter Duggan (that will delegate to Julie Penny) will have access to
the aforementioned feature. To create an exception to the rule you will create an
additional Voice Policy (with scope = user) and then you will be able to apply it to the
requiring users. We are going to define a new voice policy to respond to this need in
figure 3.3
Figure 3.3 selecting the scope to create policies that will be applied to specific users
If you had a branch office with a lot of users in need of the delegation feature, you could
have used the third scope (site) that applies to all the users in a specific Lync site. The
more specific policy overrides the others to allow a granular management (i.e.
conflicting parameters will be resolved by the User policy “overriding” the Site policy
and the site policy replacing the Global policy parameters).
As a consequence, the network aspect of your deployment will influence your Lync
administration; this is obvious because if you have a single site, you will lose a level of
“flexibility” when managing your policies.
34
Roles in Lync Administration
Role Based Access Control (RBAC) is the permissions model used in Lync 2013. During
the forest and domain preparation that is mandatory for the deployment of Lync, some
universal groups are created and permissions are assigned to them.
The aforementioned groups are the base of RBAC and enable you to control what
administrators and end-users can do. The division between Lync roles and other
administrative tasks (like Directory Services administration) is so net that just after the
domain preparation you have to insert at least one user in the CsAdministrator
group, to define the first administrator of Lync 2013.
Each RBAC role is associated with a set of Lync Server Management Shell cmdlets
corresponding to the tasks that can be carried out by users the users in a specific group.
Let’s try to imagine a scenario: Lync2013.Org wants to delegate to a group of operators
the monitoring of Lync health. The only operation that the Lync administrator will need
to perform is to insert their users in the CsViewOnlyAdministrator group (the tool
to use is Active Directory Users and Computers, there is no way from Lync to
perform this task)
Try It Now
We said that the groups have a limited subset of cmdlets available. To verify what
commands every group is able to perform you can use the following string in the Lync
Management Shell
Staying with the aforementioned example, you can launch the following line
GET-CSADMINROLE -IDENTITY "CSVIEWONLYADMINISTRATOR" | SELECT-OBJECT -EXPANDPROPERTY
CMDLETS
The result will show a list of the cmdlets related to the CsViewOnlyAdministrator group.
You can try the same command with CsAdministrator and see the differences.
35
Enabling And Configuring Users
In figure 3.4 I have divided the New Lync Server User screen into four “zones”:
Pool assignment
SIP URI configuration
Telephony options
Policy assignment
I will use the aforementioned division to separate the different tasks related to user
parameters that you have at your disposal to configure your users (later in the chapter,
we will do the same thing for clients and devices).
Figure 3.4 The New Lync Server User page with the options divided into four “zones”
36
Enabling a User to Lync
Let’s take a look to a standard process to enable to Lync one our users, Patricia Johnson.
We want to give her a Lync user that matches with her mail address, to assign her to the
Lync pool that is located in the company’s headquarter and to give her a phone number
that is directly reachable from the public telephony system 1(555)555-5555.
She will use the Lync capability to view multiple video streams in a single conference
(gallery view) and she required to simplify her access to public IM services like
Jabber.Org (at the moment she has many different accounts on the various systems).
Patricia and her colleagues have used for many years a PBX that required dial 9 before
you were able to compose an external number. We want to accommodate also this
dialing habit.
We can start from the Control Panel, Users tab and select Enable Users
Figure 3.5 Starting with the enabling process
In the next screen select Add
Figure 3.6 The New Lync Server User screen
In the Select From Active Directory screen you are able to search the user with a
search or you can simply press the Find button and have a list of all the Active Directory
users not enabled to Lync. Select Patricia Johnson.
37
Figure 3.7 Starting with the enabling process
Pool assignment
Several parameters are already set to automatic, meaning that the Global policy will
apply as long as we do not decide otherwise. The first area is used to decide which pool
will host the user account (Patricia Johnson) as you can see in the following screen
capture (figure 3.8). The information related to the pool in which the user is “homed”
are shown in the first part of the menu and are important, for example, if we need to
move our users from one server to another one in case of a disaster recovery.
Figure 3.8 Assigning the user to a Standard Edition server
In Lync 2013 the so called Front End pool is in charge of a great part of base Lync
functionalities including authentication and registration. A Front End pool could be
38
constituted by a single Lync Standard edition server or by a group of Lync Enterprise
edition servers (the suggested minimum is two servers for an Enterprise pool).
Every user enabled to Lync must be homed on a pool. If the pool contains more than one
server, every person connecting to Lync will have a defined registration order (that is
build and updated using an algorithm) containing a primary server, a secondary server
and so on. The aforementioned mechanism balances the users on the pool “nodes” and
gives continuity if one or more of the servers fails. If you have a geographical network
with different Lync sites, the standard scenario is to have users homed on a pool that is
on their local network, although this is not mandatory.
With the so called “brick” logic implemented in Lync 2013, we have an additional
continuity feature (Front End pairing). If you have two separate pools, you are able to
failover and failback the accounts from one Front End pool to another. This is not the
same continuity level that you have with a single enterprise pool because you will have
to manually fail users form one Standard edition server to the other one. However this
method supports continuity (not high availability) because data are replicated in a way
that permits the user to be moved with no information lost.
SIP URI configuration
Patricia Johnson has a mail address on our company’s Exchange system
([email protected] ). She will be more comfortable if you enable her to use the
same address to access also the Lync services( afeature called “unified communication”).
Customers and partners will expect to contact her via Lync / Skype federation using the
same mail address (reported also on his business card). A second reference, different
from the aforementioned address, could be confusing.
As you know, Lync uses Session Initiation Protocol (SIP) as the signaling protocol. To
citate the RFC 3261 “SIP is an application-layer control protocol that can establish,
modify, and terminate multimedia sessions (conferences) such as Internet telephony
calls. SIP can also invite participants to already existing sessions”.
SIP URI is the SIP addressing schema to call another person. In other words, a SIP URI
is the software version of a traditional phone number based on the SIP protocol.
Each resource in an SIP network needs a unique URI (uniform resource identifier) and
Lync is no exception. The second zone, “SIP URI Configuration” is where you can
39
configure an SIP address for your user that must be unique in the Lync structure and
should be as easy as possible to remember for both internal and external users.
Figure 3.9 The SIP options available for every user
The available choices for the SIP URI depend heavily on the choices you make in the
Lync Topology Builder. When you design (and publish) your Lync infrastructure, you
are required to list all the SIP domains that your deployment will manage.
In figure 3.10 you can see the configuration related to the default SIP domain and to the
additional ones you are able to add. SIP URI containing domains that are not existing
here are not configurable in Lync Server 2013.
Figure 3.10 Adding or removing SIP domains requires modifications to the topology
If one of the SIP domains is also a public mail domain for the company, the “Use user’s
email address” option should be your first choice.
The option to use the UPN (user principal name) has been widely used, but if your
Active Directory domain uses an internal name, the limits on the third party certificates
that will be effective on November 2015 make this option less convenient than it was in
40
the past. The remaining options add flexibility to give you the possibility to use a SIP
URI naming scheme that matches your company’s needs.
Telephony options
In the third zone, telephony options, four settings are available in the first drop-down
menu as you can see in figure 3.11.
Figure 3.11 the Telephony drop-down menu
Audio/video disabled implies that the user cannot make calls with audio and video
and is limited to Presence and IM only
PC-to-PC the user can make only PC-to-PC audio or video calls.
Enterprise Voice enables the user to take incoming and place outgoing voice calls
(this feature requires a specific Client Access License that you will need to buy in
addition to the server license, as I will explain later in the chapter). Remote call control
has two different settings
Remote call control enables the user to remote call control. There are two option,
Remote call control and Remote call control only. If RCC only is chosen, the PC-to-PC
call feature is disabled.
All parameters (excluding Audio/video disabled) require a Line URI (the telephone
number of the user).
Patricia requires full Enterprise Voice features and a number reachable from the public
telephonic system, 1(555)555-5555.
The first parameter we need is a Line URI. We said that Lync is based on the SIP
protocol, so you have to format it according to the ITU-T recommendation E. 164
(tel:+15555555555).
41
Such a format includes a country code, an area code, and a local user number and it is
required to put Lync server 2013 in a position to talk (also) with the Public switched
telephone network (PSTN) and with the outside world in general. Enterprise voice
will be explained in greater detail later in the book.
The aforementioned number may be directly reachable from outside the company (this
is called DID, Direct Inward Dialing) or may be an internal number that requires calling
a main number. In the latter scenario, we have support for an additional parameter, ext.
The Line URI will look like the one in the figure 3.12, where the extension is 5555.
Figure 3.12 Configuring a user DID with extension
Dial plan policy
The Dial plan policy and the Voice policy will add some parameters we need to manage
an Enterprise Voice user.
The Dial plan policy resolves a common issue: you need to normalize the numbers (for
example, the ones that a user dials) so that they are transmitted to the voice gateways or
SIP trunks in E. 164 format. A Dial plan contains one or more normalization rules that
you can apply to a site, a pool, a user, or to the whole Lync system (the default Global
policy).
Normalization rules are created using regular expressions such as “$ match the end” (a
topic we will explore in the Enterprise Voice part of the book).
42
Figure 3.13 Configuring a dial plan with an external access prefix
In the figure 3.13 I have added also an “External access prefix” (9) that’s often used for
calls going outside the company.
This parameter is useful if your user’s dialing habit includes adding a number to identify
calls that are going outside the company. Our user Julie Penny usually uses a desktop
phone and composes telephone numbers after she has lift the receiver off the hook (off-
hook dialing). She adds 9 at the beginning of the external number (a habit she has
learned with the old company’s PBX) and then reads the number and composes it. The
external access prefix says to Lync that 9 will be used for external number (so rules for
internal numbers will be ignores) and that the number 9 is not to be considered when
normalizing the number.
43
Voice policy
Voice policies are made up from two “parts”: features (that you can enable or disable)
and PSTN Usage records, as shown in figure 3.14
Figure 3.14 Editing a Voice policy
The previous screen capture shows the default configuration for a voice policy. For our
user we will enable also the call park feature (that is, the capability to leave a call
“waiting” and pick it up from another phone). The PSTN records are labels that we use
to group rules needed to manage call costs and voice routing. We’ll talk more about
Enterprise Voice in the third part of the book.
Earlier, we mentioned Lync CALs. Lync licensing is honor-based, so there is no control
or limit on the features you are able to use even if you haven’t acquired the necessary
licenses and you have no dedicated screen or configuration to add or remove licenses.
The only way you have to keep control over the number of required licenses is with the
policies you assign to Lync users, adding or removing features.
Policy assignment
We said that Patricia will use a feature called Gallery view. This is a new conferencing
layout that features up to five active video streams at the same time. The “Allow multiple
video streams” parameter (enabled by default and introduced for the first time in Lync
2013) can be disabled in situations where we need to inhibit access to a conference that
uses Gallery view. This is something we have to enable using a policy (that is, by working
44
in the last area of the Control Panel). The parameters are set in the screen you see in
figure 3.15 (in the Conferencing tab, editing the conferencing policy).
Figure 3.15 Editing the global conferencing policy to enable multiple video streams
Patricia Johnson keeps in touch with a large number of customers of our company and
she is often required to meet them on public IM services like jabber.org . You want to
make it easy for her to connect with the aforementioned external services using her Lync
account (and replacing with the latter a long list of accounts she uses on the various
platforms). You can achieve the result configuring a federation based on XMPP. I will
explain the details later, but basically what you need to do is to configure the policy in
the Federation and External Access tab, editing the External Access Policy as
shown in figure 3.16
45
Figure 3.16 Configuring a policy, with a scope limited to the user, for XMPP federation
It is important to point out that the policy will be a User scope policy, because we want
that XMPP integration not to be a generally available feature.
Returning to the user’s parameters for Patricia (figure 3.17) we will bind her to the
“XMPP Federation” policy, leaving the global/default policy with no changes.
Figure 3.17 Applying a User policy for Google Talk
The various policies we see in this screen will dictate the whole user experience and will
be discussed deeper in the next chapters. To give you a quick idea of the available
parameters, we have:
Conferencing policy—Defines the features and capabilities that users have available
during a meeting, including the audio and video features and the data sharing tools.
Client Version policy—This policy defines for Lync the versions of clients that are
supported in your environment.
PIN policy—To participate in a dial-in conference, a Lync user requires a personal
identification number (PIN). PIN policy dictates maximum logon attempts, PIN
expiration, and so on.
46
External Access policy—You can configure which public systems (including XMPP
federated partners) or external users can collaborate with internal users.
Archiving policy—Archiving enables your company to keep a record of IM
conversations involving your Lync users. The aforementioned feature could be required
for legal reasons and could be turned on only for specific users, with a dedicated policy
applied to the people you need to track.
Location policy—Location policy contains the E9-1-1 settings.
Mobility policy—The features you can control from here are related principally to the
Lync 2013 clients for mobile devices, e.g. Wifi Connection requirement for Video Calls
from those devices.
Persistent Chat policy—The parameters you can modify here are related to the
persistent chat service.
Client policy—The client policy dictates which client features will be available for the
user.
As you’ve seen, even the configuration of a user that doesn’t have particularly complex
requirements involves several steps. A user’s policies and configuration (especially
projected on a large scale) have a deep impact on costs and on the performance of your
system and are not to be undervalued.
Try it Now
Move a user from one Lync pool to another and to disable their conferencing policies
using the Control Panel.
Lab
NOTE For this lab, you’ll need your domain controller and a Lync Front End up and running.
Proceed to enable a new users in Lync
Delegate to this user the capability to enable and disable users for Lync Server
Launch the Lync Control Panel whit the aforementioned user and enable two new
users to Lync
Define their policies so that one of them is enabled only to IM while the other one
is an Enterprise Voice user
47
For the latter, configure a dial policy that includes 0 as an external access prefix
Try an audio call and then configure everything so that users are able to talk each
other with Enterprise Voice
Test the delegation feature, enabling it for a Lync user and applying the number
delegation from the Lync client
48
4 Managing Clients, and
Devices with Lync Server
Control Panel
As a Lync server administrator, one of your tasks is to manage software updates and
usage policies for the clients. The definition of client in Lync includes Lync client
software installed on the user workstation or on a mobile device and IP deskphones. You
can add to the list the Lync Web App, a web interface accessible to the users with no
client software on their local machine. The Web App is not a full featured client but
enables participation to an existing meeting.
In figure 4.1 you can see the full client, the Web App and a deskphone side by side.
4.1 A graphic representation of some of Lync 2013 clients
The Control Panel of Lync 2013 server will be of great help in this task with the tools
incorporated in a tab called CLIENTS (as I explained previously, the Control Panel is
the graphical interface for Lync administration). You can see it in figure 4.2
4.2 The left pane of Lync 2013 server Control Panel. The green circle shows the clients tab
In the client tabs we have the instruments to manage:
49
Clients: Lync and OCS client software installed on desktop clients (OCS 2007 R2 was
the UC product published from Microsoft before Lync)
Hardware: this definition includes all the deskphones you can use with Lync. These
can be divided into two broad categories:
Compatible IP Phones Tested and Qualified for Lync that are phones that use a
third-party software compatible with Lync
IP Phones Optimized for Lync that are phones based on Lync Phone Edition (see
figure 4.3). Lync Phone Edition is a client software from Microsoft that runs on qualified
devices and provides traditional and advanced telephony features.
Figure 4.3 the phone on the left uses Lync Phone Edition while the one on the right uses a software from the
hardware manufacturer
Mobility: dedicated to the management of client functionality designed for mobile
devices such as smartphones and tablets
In Figure 4.4, in addition to showing contents of the Clients tab, I have divided it into
three "zones" (client, hardware and mobility). It should be easier to explain the different
tools this way.
Figure 4.4 Clients tab in Lync Control Panel with the three zones
50
As you can see, two tabs are for Software Clients management, four are for Hardware
Devices and two focus on Mobility.
You can map each tab with the administrative tasks you accomplish inside, like in the
following table
Client Version Policy Client version policies enable you to specify which clients will accepted from Lync Server
Client Version Configuration
Here you can specify a default action for clients with no client version policy defined
Device Update You are able to approve and distribute software updates to the devices
Test Device You can add a test device and use it to verify new updates before deploying them to production devices
Device Log Configuration
You can manage settings related to the device updates logging
Device Configuration Device configuration enable you to modify management options for Lync Phone Edition like phone lock after time-out
Mobility Policy You can create a mobility policy to allow or deny Lync features to mobile users
Push Notification Configuration
You can enable o disable push notifications. A notification is an on-screen warning about missed Lync communications. It is available only on certain versions of the Lync mobile client
I will explain some of the configurations available in the various tab, keeping the logical
division into three areas to improve the clarity.
NOTE: Usually client management is not a job that you will perform on a daily basis.
Usually you will work in the face of new software updates or if you need to change
policies for your clients.
Now, to start with a practical example, let’s imagine that you have just migrated your
corporate’s Lync infrastructure to Lync server 2013. You will probably have the Lync
2010 clients displaying the following error: “Microsoft Lync 2010 is not a version that
can be used to sign in to the server”, as you can see in figure 4.5
51
Figure 4.5 Default error with Lync 2010 clients
The solution to your problem is in what I have called the “software clients” zone of the
clients tab in the Lync serve Control Panel.
Software Clients
The parameters in the Client Version Policy and in the Client Version
Configuration tabs dictate together which clients can login to Lync server.
Every time a Lync user logs on, the client version configuration select if it is subject to
client version checks or not.
If the Client Version Configuration is enabled (see figure 4.6 the Client Version Policy
will check the release of the client software and allow (or deny) it the access.
Figure 4.6 Client Version Configuration enabled
Then the Client Version Policy establishes the rules for admitting or blocking the
different clients.
52
The default policy is a global one (that means that it applies to the entire infrastructure
Lync) as you can see in figure 4.7
Figure 4.7 client version policy with the default (global) policy
Opening the policy, you will see the list in the image 4.7. The value I have pointed out in
green is the one that regards our Lync 2010 clients. If they are older than version
4.0.7577.4103 they will not be able to connect to Lync server 2013.
Figure 4.7 client version policy with the parameter regarding Lync 2010 client highlighted
The default settings are too restrictive, for our scenario, cutting out a part of the Lync
2010 clients. What you have to do is modify to set to allow the OC 4.0.7577.4103 version
of the “User agent” (corresponding to the Lync 2010 client) as you can see in the next
screen capture
53
Figure 4.6 Enabling Lync 2010 clients
Now, let’s add some information to go beyond the specific issue you have just seen.
Version Configuration includes a setting to allow or block unidentified clients. That is an
important set because it dictates how Lync will manage any client it is not able to match
with the versions listed in the policy parameters.
To manage scenarios with a company’s deployment of the Lync clients that is not
homogenous you can create site or user policies to manage exceptions for a single office
or employer.
Note: If you want to keep also Microsoft Office Communicator 2007 R2 clients running,
the version to modify is 3.5.6907.233
Hint: I suggest you a free tool (Find Lync Versions
http://www.stumper66.com/software/lync.html ) that queries the RTCLocal database to
retrieve the client versions that your users have on their workstation.
Try It Now
Open a Lync client and identify its version number.
Prepare a list of the required steps to allow connection to the Lync server for
legacy clients in a branch office with a local Lync Front End server where the
users are homed.
Now, imagine the aforementioned branch office with a SBA deployment of Lync (
Survivable Branch Appliance is a an hardware with limited Lync features to
increase voice resiliency in branch-office scenarios). The list of required steps to
keep legacy clients working will change ?
54
Hardware Devices
If your company uses the Enterprise Voice of Lync server 2013 (that is the Lync term to
define voice communications over Internet Protocol or VOIP) you probably have also
deployed deskphones as the ones you have seen at the beginning of the chapter.
A part of your administrative tasks is to keep up to date and to align to the last version of
software the aforementioned physical phone devices.
In this zone of the Control Panel you are able to approve and distribute updates to the
devices (and to rollback in case an issue arises), to test them or to configure some
parameters (see figure 4.7)
Figure 4.7 Device Management in Lync Control Panel
Let’s assume that you need to update an HP4110 phone to the last release of the
software. The first step is to download an updated .bin file (this file, deployed to the
deskphones, will update their software). Then you need to make it available to the
devices.
Lync enables software distribution to the devices through the web service installed by
default on the Lync Front Ends.
Note: the procedure will require also the use of the Lync Management Shell (that is the
“command line” based on Windows PowerShell for Lync administration) and its cmdlets
(a lightweight command that is used in the PowerShell environment)
You need a cmdlet to import the .bin files in Lync server. The base command is Import-
CsDeviceUpdate but you need also to know a parameter of your Front End called
identity.
If you do not know the “-identity” parameter for your server you can use the following
cmdlet Get-CsService –WebServer.
In my example I have a value equal to Webserver:2012SE1.Lync2013.dom.
The .bin file I have downloaded is located in c: and named ucupdates.cab. The ending
cmdlet to import it will be
Import-CsDeviceUpdate -identity WebServer:2012SE1.Lync2013.dom -FileName
c:\ucupdates.cab
55
To verify if the update have been imported correctly you have to go in the Lync Control
Panel and open the Device Update in the clients tab.
The result is the one you can see in figure 4.8 (I have also opened the Action menu for
the approval).
Figure 4.8 Updates are available for approval in Lync Control Panel
Before deploying it on a large scale you can verify the new updates on a test devices
using the dedicated menu (Test Device) in the Control Panel. The hardware can be
identified using the MAC address (unique identifier of the network interface of the
deskphone). In my case 00:04:13:72:00:7F. You could also use the serial number
(M08400000) as shown in figure 4.9
Figure 4.9 Configuring a Test Device
If the test device shows no issue, you can deploy the update approving it in the
aforementioned Device Update tab.
56
Note: The pre-requirements for a successful Phone Edition deployment include a
working Lync Enterprise Voice implementation and modifications to the network
infrastructure servers like DNS and DHCP.
Mobility
Let’s say that our user Patricia Johnson needs:
To use a mobile client and the call via work feature (i.e. the capability to call from
her cell phone using her work number)
We want her to use voice and video only if a Wi-Fi connection is available (so
mobile data connection should be inhibited for those features)
The bad news are that you can’t achieve the result using only the Control Panel.
The default policy (global) that you can see in the Mobility Policy tab (figure 4.10)
does not satisfy the aforementioned requirements and that there is no way to force the
Wi-Fi parameter from the Control Panel.
Figure 4.10 The Mobility Policy with the default policy opened
I have zoomed the previous image in figure 4.11. As you can see, the settings are only to
enable or disable mobility and call via work.
57
Figure 4.11 Global Mobility Policy
The solution is to use (again) the Lync Management Shell. If you launch the cmdlet Get-
CsMobilityPolicy you will see a result like
Identity: Global
Description:
EnableOutsideVoice: True
EnableMobility: True
EnableIPAudioVideo: True
RequireWIFIForIPAudio: False
RequireWIFIForIPVideo: False
So to get the result you want (limiting it to a user scope because we want to apply it to
the single users) the cmdlet will be something like
New-CsMobilityPolicy -identity "Wi-Fi required" -RequireWiFiForIPAudio $True -
RequireWiFiForIPVideo $True
Push Notifications
Depending on the kind of mobile device the user will work with, you could prefer to
enable the push notifications of Lync (as we said before, on-screen warning about
missed Lync communications).
58
Push Notification are disabled by default (see Figure 4.12)
Figure 4.12 Default Policy for Push Notifications
To continue with our previous example, if Patricia has Lync 2013 Mobile on an Apple
device, you do not need push notifications because the new version of the client for IPad
and IPhone does not support them. If she uses Lync 2010 Mobile on an Apple device or
a Windows Phone, notifications useful. The aforementioned configurations will use the
push service to notify the user for lost IM messages and contacts when the client is in
background.
Note: the feature requires configurations for the Lync Edge and for the reverse proxy
that we will see later in the text.
Some Things You Have to Do Outside the Control Panel
Some devices, like the ones dedicated to conferencing and the common area phones are
not managed from the Control Panel and we will talk about them.
A part of the client management and configuration (bootstrapping policy) is managed
through Group Policies (Lync 2013 administrative templates are included in the “Office
2013 Administrative Template files (ADMX, ADML)”) as you can see in figure 4.13
Figure 4.13 Microsoft Lync 2013 administrative template in Group Policy editor
As you may already know, Group Policies enables you to modify the whole working
experience of a user, adding or removing features, programs and permissions from the
client based on his / her group membership, the organizational unit in which we insert
59
the Active Directory account, the computer object and so on. Usually this is something
managed from the administrative group responsible for the company’s Directory
Services. As a Lync administrator, you can use the Active Directory infrastructure to
configure Lync client parameters. Group Policies for Lync are policies for the computer
object, so you are able to modify some settings of the Lync client based on the
workstation that the user is logged on.
A useful application of the Group Policies with Lync 2013 brings a solution to the Lync
– Sign In error “Lync cannot verify that the server is trusted for your sign-
in address. Connect anyway?”.
Usually this is an error related to some mismatching information in the Lync
certificates, where the users SIP Address is not matching the internal Server DNS Suffix.
For example, your Active Directory domain is Lync2013.dom and that your Lync Front
End name (and DNS records) are associated to the Lync2013.org domain.
All the Lync clients, the first time you try to connect, will show the aforementioned
error. You can manually add the server to the trusted domains list but a smarter solution
is to use the Group Policies. Adding the Lync server in the “Trusted Domain List
(TrustModelData)” parameter (see next image).
Figure 4.14 the Trusted Domain List
The error will never show in any of the clients joined to your Active Directory domain.
This is only one example of the results you are able to obtain with Group Policies. In the
next “Try it now” I will show you some additional tasks that you can perform.
60
Try It Now
To further explore the power of the Group Policy for Lync 2013 you could try to create
two different policies: the first one (that you can call Tracing) will enable the tracing for
troubleshooting on the client (Turn on tracing for Lync enabled in the policy) and you
can link it to an organizational unit that you can call Debug. The second policy (that you
can call No Tracing) will have the same tracing parameter configured in disable and will
be linked to an o.u. called Lync clients.
The situation will be the one you can see in the next figure
Figure 4.13 Organizational units with the two Lync group policies linked
Now, every time you have a problem with the Lync client of a single workstation, you
can move the computer object to the Debug o.u. so that the next time the client logs on
to the domain tracing is enabled. When the issue is resolved, you can move the endpoint
back to the original o.u. and the tracing will be disabled at next log on.
Lab
In this chapter you have seen a portion of the management through the Lync control
panel that encompasses all the client solutions available to the users (Lync clients for
desktop and mobile environments and external users based on mobile devices options).
As you have seen, some specific tasks have to be executed outside the graphical interface
and the characteristics of the Lync management shell are the topic of the next chapters.
NOTE For this lab, you’ll need your domain controller and a Lync Front End up and
running.
61
Try to answer the following questions and complete the specified tasks. This lab is
focused on the features that the Lync Control panel offer to manage the different kind of
clients and devices.
Can you inhibit the use of Lync for a group of users? How do you perform this?
How do you enable the use of Lync 2010 client only for a specific site?
What is the best method to test a Lync desktop phone firmware before deploying
it to all the devices?
How can you dictate that audio and voice features for mobile clients are available
only if a Wi Fi Network is connected?
62
5 Managing Users with
Lync Server Management
Shell
Lync Server Management Shell is and administrative interface built on the Windows
PowerShell 3.0. Although it is possible to perform around 80% of the management and
configuration tasks from the Lync Control Panel, you have to remember that the
aforementioned graphical interface implement only a subset of the cmdlet that you have
at your disposal in the Management Shell. The Lync Server Management Shell also the
best tool to automate administrative tasks.
Administering Users From The Management Shell
Using the new PowerShell 3.0 means that new features and improvements are available
to manage Lync. The first useful tool is the Show-Command cmdlet. As you can see in
figure 5.1, the new version of this cmdlet opens a graphical interface that lets you select
the PowerShell module you want to use and then brings up a list of available cmdlets.
5.1 Using the Show-Command cmdlet to explore Lync commands
63
Selecting a cmdlet you are able to see the available parameters (see figure 5.2)
Figure 5.2 the parameters are shown in the graphical interface
Get Information About Lync Users
You can start examining one of the most used cmdlets for Lync user management: Get-
CsUser
Figure 5.3 the Get-CsUser cmdlet with a list of the available options
64
Figure 5.3 shows of the most common properties that you can use with the get-CsUser
command. A first, interesting cmdlet that you can use is
Get-CsUser | Get-Member -MemberType Properties
This command will show all the properties you could query with Get-CsUser
In the following image I have launched filtered only the name of the properties to have a
clearer list
Get-CsUser | Get-Member -MemberType Properties | select-object Name
Figure 5.4 the result of the previous cmdlet with the selected values in a table
Some examples:
65
Get-CsUser | Select-Object DisplayName
The command will list all the users enabled to Lync and will show only the display name
for each one
Get-CsUser -Filter {EnterpriseVoiceEnabled -eq $true}| Select-Object DisplayName
The command will list all the users enabled to Enterprise Voice and will show only the
display name for each one
Get-CsUser | where {$_.LineURI -like "tel:+39*"} | Sort-Object LineURI | Select-Object
Displayname, LineURI, PrivateLine
The command will show all the users enabled to Lync enterprise voice with a number
starting with +39 and sort them based on their telephone number in a table as you can
see in the next figure
Figure 5.5 the result of the previous cmdlet with the selected values in a table
$list = Get-CsUser
$list.Count
To count the users enabled to Lync and display a numeric value
$list=Get-CsUser -Filter {EnterpriseVoiceEnabled -eq $true}
$list.count
If you want to list only the users enabled to Enterprise Voice you can mix the
aforementioned command and one of the previous exaples
Get-CsUser | where {$_.registrarpool -match "Lync01.lync2013.intra"}
If you want to list the users hosted on a specific registrar pool (for example
Lync01.lync2013.intra)
Enable or Disable Lync Users
To enable a user to log on Lync server you have to enable he or she to the Lync services.
The aforementioned user must have a valid account in the Active Directory forest.
66
While you were able to launch the Get-CsUser cmdlet with no parameter, the Enable-
CsUser cmdlet has some required parameters. Identity, RegistrarPool and SipAddress
have to be defined (although the latter can be parameterized automatically or manually
in the cmdlet).
Figure 5.6 required parameters of the Enable-CsUser are in yellow
Some examples:
get-csaduser -filter {windowsemailaddress -like ‘*@domain.com’} -OU
“ou=OrganizationUnitName,dc=domain,dc=com” | Enable-CsUser –RegistrarPool
“PoolServer.domain.com” -SipAddressType EmailAddress
Bulk enabling of Active Directory users to Lync is something that is really often
required. I have used the solution published on this blog
http://jamesosw.wordpress.com/2012/01/16/enabling-lync-users-in-bulk/
This one builds on the get-csaduser cmdlet and lets you pick user objects from a specific
organizational unit, filtering them using the e-mail address end enabling them to Lync
with an auto-generated address based on the aforementioned mail address.
67
The Control Panel can’t modify domain users that are part of an administrative group. If
you try to do that you will have the error shown in the next figure
Figure 5.7 the error message related to the modification of an administrator
It is required to operate from the Management Shell with the following cmdlet
Enable-CsUser –Identity "Administrator" –RegistrarPool Lync01.lync2013.intra -
SipAddressType EmailAddress
Try It Now
Try the WhatIf parameter to test an Enable-CsUser cmdlet
Try the difference between the Set-CsUser –Identity "username" –Enabled $False cmdlet and the Disable-CsUser –Identity "username" cmdlet. You will notice that
the first one disables the user from Lync with no configuration or policy lost,
while the second clears all the Lync parameters.
Moving Lync Users Between Different Pools
The Move-CsUser cmdlet enables you to move a user account from one Registrar pool to
another.
The command is important in Lync 2013 because we can use it to failover / failback
Lync enabled users from one pool to another one if we have decided to take advantage of
the Front End pairing feature (see later in the text for a detailed explanation).
The parameters related to Move-CsUser are the ones you can see in figure 5.8, with the
ones in yellow (Identity and Target) required.
68
Figure 5.8 the Move-CsUser cmdlet with the required and optional parameters
As a part of the failover procedure if a paired Front End is no longer available, you have
to use the following cmdlet (including the –Force parameter)
Get-csuser -Filter {RegistrarPool -eq "Lync1.Lync2013.Intra"} | Move-CsUser -Target
Lync1.Lync2013.Intra -Force
Lync2013.Org has deployed a hybrid environment with a split domain. Although we will
talk about this kind of configuration in Chapter 21, at the moment it is important to
remember that it enables your users to work on-premises and online with the same SIP
domain. You can also move the users online and back on-premises using the Move-
CsUser cmdlet. The syntax will be similar to the one you can see here
Move-CsUser -Identity “UserURI ”@Lync2013.Org” -Target sipfed.online.lync.com -
Credential “Office 365 administrator credentials” -HostedMigrationOverrideUrl
“Migration URI taken from the Office 365 Portal”
69
Handling Policies From The Management Shell
As you have seen in the previous chapters, Lync Server provides a number of
policies to manage features and configurations. For every policy you have seen in the
Control Panel there is a matching cmdlet in the Management Shell. Policies related to
clients and devices (Client Version, Pin, Client Policy) will be explained in Chapter 6.
Regarding Lync users we have the schema you can see in figure 5.9. Note that the
schema uses only the “New-“ cmdlet used to create a new policy, but you have also
“Grant-“ to assign an existing policy, “Get-” to retrieve information about policies,
“Remove-“ to remove policies and “Set-“ to modify an existing policy.
Figure 5.9 User policies paired with the cmdlet used to generate a new policy
The first policy Lync2013.Org wants to deploy for conferencing, will limit the users with
a standard CAL to IM, presence and participation (not scheduling) in conferences. Tim
Harrington has done a great job here http://howdouc.blogspot.it/2011/09/understanding-and-enforcing-licensing_21.html with a policy that does what you need using the Management Shell (the articles were
based on Lync 2010 but standard CAL limits and cmdlets to use are the same in Lync
2013):
New-CsConferencingPolicy –Identity “Conf-StandardCAL” –AllowIPAudio $false –
AllowIPVideo $false –AllowUserToScheduleMeetingsWithAppSharing $false –AllowPolls
$false –EnableAppDesktopSharing None –EnableDialinConferencing $false
70
The policy will disable all the features not included in the standard CAL as you can see
in the results shown in figure 5.10
Figure 5.10 configuring a new policy to enforce a standard CAL
The next step will be to apply the policy to users. For example let’s say that when Julie
Penny was hired in the company the features we granted to her were the ones included
in the standard cal
Grant-CsConferencingPolicy –Identity "Julie Penny" –PolicyName "Conf-StandardCAL"
When Julie began working with Stacey Duggan the Lync administrator decided to align
them to the “Global” policy, which includes additional features.
Again, from the Management Shell, we are able to perform the task using:
Grant-CsConferencingPolicy –Identity "Julie Penny" –PolicyName $Null
CsExternalAccessPolicy is dedicated to manage your external access policies (like
federation). So, the first step you could perform is to get a list of the existing policies
with Get-CsExternalAccessPolicy. Now, let’s suppose that the interns of your company
should be not able to use the external access features. You are able to address the need
creating a user policy with a cmdlet like this:
New-CsExternalAccessPolicy -identity Intern
71
You don’t need to specify parameters, because the features will default to $False (i.e.
disabled) like you can see in the next figure 5.11
Figure 5.10 Configuring a restrictive policy for a group of users
Now all you need to define is a parameter that identifies the intern users enabled to
Lync and applies the aforementioned policy in a consistent manner. If their Title in
Active Directory is Intern, the cmdlet will be something like the following one
Get-CsUser –LdapFilter "Title=Intern" | Grant-CsExternalAccessPolicy –PolicyName Intern
Lync Server (with the Archiving role) enables organizations to archive IM content,
conferencing (meeting) content, or both. The first step will be to read the policies
running in your company with the Get-CsArchivingPolicy cmdlet. The default
configuration a global policy like the one you can see in the figure 5.11
Figure 5.11 Reading the Archiving policies
Being involved in the legal affairs, Stacey Duggan has required to have her internal and
external conferencing to be archived.
You can proceed to create and apply the policy to her with the following cmdlet:
New-CsArchivingPolicy -Identity “LegalAffairs” -ArchiveInternal $True –ArchiveExternal
$True
Grant-CsArchivingPolicy –Identity "Stacey Duggan" –PolicyName “LegalAffairs”
Some configuration associated to the mobile clients are available only from the
Management Shell. Working on Stacey account, you want to enable her to Call via
Work (the user is able to make and receive phone calls on their mobile phone by using
their work phone number) but you want also to be sure that she is able to use the VOIP
72
and Video features of the Lync 2013 mobile client only when a Wi-Fi network is
available (avoiding to use her data plan).
The latter parameter is available only from the Shell and it is not visible in the Control
Panel after you have added the new policy.
The cmdlet will be like the following one:
new-CsMobilityPolicy -Identity "CallviaWork" -EnableOutsideVoice $True -
RequireWIFIForIPAudio $True -RequireWIFIForIPVideo $True
In the next figure the different visualization is shown, with the Control Panel and the
Management Shell combined
Figure 5.12 the mandatory Wi-Fi connection for VOIP is not shown in the Control Panel
After you have granted the CallviaWork policy to Stacey, the settings on her mobile
client will be locked so that she is not able to use a connection different from the Wi-Fi
(figure 5.13)
Figure 5.13 the client settings are dictated by the policy
Lync2013.Org will use the Persistent Chat feature (we will talk about this in Chapter 10)
and you will need to use the dedicated cmdlets (that are new in the Lync 2013
Management Shell).
The New-CsPersistentChatPolicy cmdlet creates a new Persistent Chat policy to
determine if the user is allowed access to Persistent Chat rooms.
A policy you will need is to enable users to Persistent Chat
73
New-CsPersistentChatPolicy -Identity "ChatPolicy" -EnablePersistentChat $True
Lab
To test the flexibility and power of the Management Shell a good starting point is to try
the following “well known” one-liners
Get-CsAdUser | ?{$_.UserAccountControl -match "AccountDisabled" -and $_.Enabled -
eq$true} | Disable-CsUser
This one is from Pat Richard and disable users for Lync who are already disabled in
Active Directory
(get-csuser -OnLyncServer -Filter {EnterpriseVoiceEnabled -eq $true}).count
This one is from Mike Pfieffer and in this example uses AD PowerShell to import a
photo named rhouston.jpg for a user named rhouston
(get-csuser -OnLyncServer -Filter {EnterpriseVoiceEnabled -eq $true}).count
From Chris Norman, it counts the number of voice enabled Lync users.
74
6 Firewall Requirements for
Lync Server 2013
As I have explained in previous chapters, Lync Server 2013 contains many unified
communication features and each one of them will require the use of a series of
protocols and network ports. If you sum all of the available functionalities, the number
of firewall configurations required is high and not trivial. In this chapter I will try to
explain some resources you should use to design your network security for Lync Server
2013, the rules required on your firewalls and some useful tools to verify and debug your
deployment.
Planning a Lync Deployment the Right Way: Tools You Will Love (Part
1)
TechNet Gallery is full of outstanding (and free) tools. I would suggest a couple of them
for this part of your Lync Server 2013 planning:
Lync 2013 Detailed Design Calculator: by Alessio Giombini
(@AlessioGiombini ), Alberto Nunes (@AA_Nunes ). Quoting the
overview “it is an offline, free, Excel-based, low-level design calculator for
Microsoft Lync 2013 deployments”
http://gallery.technet.microsoft.com/lync/Lync-2013-Standard-Edition-
324bf0f1 . Based on your planned design it will generate a lot of useful
information, including the required firewall rules
Lync 2013 Firewall Diagram V2: by Randy Chapman. It is a base
Visio diagram of a Lync Server 2013 deployment
http://gallery.technet.microsoft.com/lync/Lync-2013-Firewall-Diagram-
9a7e3c92 . You can modify it to explain your requirements to the security /
firewall people. Quoting the overview “So I took to Visio and made a
picture which I hope is worth at least a thousand words.” I strongly agree
on that.
Port Requirements: a TechNet post that links to all the different
resources related to Lync Server 2013 firewall requirements
http://technet.microsoft.com/en-us/library/gg398798.aspx
75
Microsoft Lync Server 2013 Protocol Workloads Poster: this one
shows in a .pdf / .vsd file all the different workloads related to Lync Server
2013 and the protocols and ports you need to enable for them
http://www.microsoft.com/en-us/download/details.aspx?id=39968 . This
resource is outstanding for quality but a bit hard to use if you are not
already experienced with Lync.
Microsoft Lync Server 2013 Internal Certificate Planning and
Deployment: this resource will help you in understanding and managing
Lync Server 2013 requirements, with a focus on internal certificates
http://lyncuc.blogspot.de/2014/04/internal-certificate-deployment-in-
lync.html.
The Basic Diagram of a Lync Deployment We Will Use in the Chapter
The explanation of Lync requirements will start from a diagram in figure 6.1 (identical
to the one shown in figure 2.2), representing the minimal infrastructure required to
deploy a Lync server 2013 that is available also for external users
Figure 6.1 A minimal working infrastructure of Lync Server 2013 including external users
To explain the Lync infrastructure, as I said, we will need to add names and network
addresses (IPs) to our Lync design. To grant the name resolution we will use the same
DNS server that is already required for the Active Directory Domain Services (AD DS).
76
Note: There will be two different DNS names resolutions required, one for the Internet
and one for the internal network. The latter is the one that will leverage the existing
DNS server. Those DNS servers are internally used for Active Directory member servers
and for users SIP domain auto-login process.
Lync Server 2013: Internal Network
In figure 6.2 I have added names, network address and Virtual LANs (VLANs) to the
schema shown in the previous figure 6.1
Figure 6.2 The previous Lync diagram, populated with names, IPs and VLANs
Servers located in the LAN
The Domain Controller, Aphrodite will be in charge of user authentication,
permissions and DNS service. Lync is built over Active Directory, so the internal
deployment will require a Domain with the following requirements:
All domain controllers have to be at least 32-bit or 64-bit versions of the
Windows Server 2003 operating system
Domain functional level at least Windows Server 2003
Forest functional level at least Windows Server 2003
Note: see the TechNet post Active Directory Infrastructure Requirements
http://technet.microsoft.com/en-us/library/gg412955.aspx for additional information
77
For a user that is connected to the internal LAN, all the Lync services are available
directly on the Front End (Apollo). A part of the aforementioned Lync services (like
dialin and meet) will be deployed through the locally installed Internet Information
Services (IIS) feature and will be reachable on port 80 and 443 of Apollo. Additionally,
the internal IIS will be listening on port 80 also for Lync Phone Edition.
On Apollo we will have a second group of web services, similar to the aforementioned
ones, but listening on TCP port 8080 and 4443. It is easy to distinguish them using the
default names Internal Web Site (listening on TCP port 80 and 443) and External
Web Site (listening on TCP port 8080 and 4443). The aforementioned separation is
driven by a security motivation, separating the resources for the clients coming from an
external network from the ones for users on the internal network.
Figure 6.3 The IIS configuration on a Lync Server 2013 Front End
The External Web Site will be used to grant the services to the external users using a
reverse proxy
In figure 6.4 I have expanded the Internal Web Site of Lync
Figure 6.4 The IIS “Internal” site on a Lync Server 2013 Front End
78
As soon as we share a PowerPoint presentation, during a meeting, we will be redirected
to the TCP port 443 (or 80) of the Office Web App Server (Demeter).
Note: Lync clients for mobile will always require access to the Lync services as they are
coming from the Internet, also if they are connected to an internal network (see next
paragraphs). Their internal request have to be re-routed from the internal LAN through
the Reverse Proxy back to the published external Web Site. This is regarding moving
mobile clients between Wi-Fi (internal) and 3G/ Wi-Fi (external) and their need to hold
the initiated server session.
Servers located in the DMZ
To make Lync Server 2013 available to external users, we will publish the services from
the single Front End through two different servers that we will locate in a
Demilitarized Zone (DMZ). The servers should be standalone (or, at least, not part
of the internal Active Directory Domain).
Note: it is a commonly used solution to match the internal Active Directory DNS zone
as primary DNS suffix in the Lync Edge. This makes the deployment of the
aforementioned server a little easier.
Both servers should have two different network interfaces (NICs), one dedicated to
talk with the internal LAN and the other one to be published on the Internet, in our case
here for both, with Network Address Translation (NAT). I have also physically
segregated the two logical networks using VLANs, so that communication from one NIC
to the other one will never mix. VLAN2 will be connected to the internal LAN through a
back-end firewall, while VLAN3 will be connected to the Internet using a front-end
firewall.
Web services of the Lync Front End will be published using a reverse proxy (Ares)
that will answer on a public Internet IP on TCP port 443 and will proxy the requests to
the port 4443 of the Front End (or on TCP port 80 to proxy on port 8080 of the Front
End).
If we share a PowerPoint presentation in a meeting that contains external users, the
reverse proxy will redirect them to the TCP port 443 of the Office Web Application
Server. ANY reverse proxy solution should work, including Windows Server 2012 R2
Web Application Proxy (as long you are deploying ONLY a SINGLE SIP Domain). (I
have shown how to configure it for Lync 2013 on this video:
http://www.youtube.com/watch?v=iKpi8UomRDo ).
79
Forefront Threat Management Gateway is also a solution that many companies
used over the past years (please consider that the whole Forefront family of products is
“ending its life”).
All the remaining services will be deployed using a dedicated Lync server role, the Lync
Edge Server (Dionysus) that has to be defined and published using the Lync
Topology Builder (more details on Edge Server and Topology Builder will be added in
further chapters). Three network addresses will be required to publish the Edge services.
Lync supports two different configurations on your front-end firewall and Lync Edge
Server:
A single public IP and a single public name for the three services, Access
Edge, Web Conferencing Edge and A/V Edge (with three different TCP ports
listening)
Note: this will create issues and limitations for Web Conferencing Services. The
TCP port 444 suggested by default (or your custom defined port) normally are
not open on corporate firewall’s.
A simple deploy with three public addresses, one for each one of the
aforementioned network addresses.
In figure 6.5 you can see the option that enable the use of a single public name and IP
Figure 6.5 The “Use a single FQDN and IP address” option in the Topology Builder
In figure 6.6 I have shown the two different configuration you while building the Lync
Topology. On the left, the scenario if we selected single IP and single FQDN. On the
right scenario with multiple IPs and FQDNs
80
Figure 6.6 on the left, “Use a single FQDN and IP address” enabled. On the right multiple FQDNs and addresses
Note: It is easy to understand that the solution using a single IP will be less “costly”, but
will be more prone to problems with external firewall, moving the services from a
“standard” TCP port 443 to a group of custom TCP ports.
Try it now
Add information about a Lync deployment (you could use the one I have just described,
for example) and feed them inside the Detailed Design Calculator. Look at the firewall
rules and try to understand why they are required. Then, take the Workload Poster and
use it to identify the feature that requires the rules you were not able to recognize at first
sight.
Infrastructure requirements
Now that I have outlined the building blocks of a Lync infrastructure, there are three
more topics to understand if we want to have a working infrastructure:
Firewall rules required to allow communications for Lync clients, Lync servers
and for the aforementioned non-Lync servers with additional services we need
DNS settings to make Lync services available both on the internal network and
from the Internet
Structure of the certificates. Lync is secure by design and digital certificates are
mandatory for every Lync 2013 infrastructure
Internet facing systems need to be configured, in most cases, with a default
gateway on their external Network Adapter and with static route to all internal
networks, where Lync Server and Clients are located.
81
Note: on Lync Edge Server, for security reason, best-practice is deploying an external
DNS server on the external network card and use hosts file for internal Lync server. You
can use an internal DNS only which is able resolving external DNS zones. But should an
Edge server be compromised the attacker could have access and knowledge of your
internal infrastructure.
Firewall Rules Required for Lync Server 2013
A deep dive about firewall rules for Lync Server 2013 should include the already quoted
TechNet article Port Requirements and the Lync 2013 Protocol Workloads poster (i.e.
to check the requirements for the different scenarios). However to make the topic easier
to understand, I have tried to create an explanation based on some assumptions.
The first assumption I will make here is that your network has a segregated DMZ
to make services available to the Internet in a secure manner. Possible solutions
for such a deployment are:
o Using two firewalls.
Note: usually the technology used for the firewalls is not
important. However if a SIP trunk is required in our scenario, it is
important to have a SIP Application-level gateway (ALG),
especially if you are going to use NAT for SIP trunks.
o A three-legged firewall that will create a logical demilitarized zone
There is no difference in the result, from a functionality standpoint, going for the
first option or the second one. A single firewall would imply a single point of
failure and higher security risk, because a single Internet-connected device will
be exposed both on the DMZ and on the internal network. Having two different
firewalls, a front (FW2) and a back firewall (FW1), as shown in figure 6.7, is
more secure, especially if we are going to use two different platforms or solutions
for security. In the aforementioned scenario, an exploitable security vulnerability
on a single technology will not affect the second firewall.
82
Figure 6.7 layout including only firewalls and networks that will have an impact on our Lync deployment
The second assumption will be that we will not deploy High Availability or load
balancing systems (including Enterprise Edition pools of Lync Front Ends).
Although you may require them in a real-world design, they add configuration
overhead that will not help understanding the fundamentals of Lync Server 2013
network traffic requirements
The third assumption is that we will use NAT every time a public IP is required.
Exposing directly a server to the Internet usually is not the best security solution
available
Fourth assumption is that the Edge Server will use three addresses on the
"external" network interface card to expose services to the Internet. The
addresses are the ones we have already seen:
Last assumption: no integration or connection with Office Communications
Server 2007 deployments or clients is required
We will have to grant the following types of network traffic:
6.1 From servers in the DMZ to servers in the internal network
6.2 From servers in the DMZ to the external network
6.3 From the external network to servers in the DMZ
6.4 From servers in the internal network to servers in the DMZ
6.5 Network traffic related to Lync clients in the internal network
Note: point 6.5 of the list only applies if you have firewalls (or end-point firewalls)
separating the networks containing the Lync clients and the Lync servers.
83
6.1 Network Traffic from servers in The DMZ to Servers in the
Internal Network
On the Back-End firewall, FW1, for traffic starting from the reverse proxy, the following
ports will be required:
Reverse proxy Rules on Back-End firewall (FW1)
Source Interface Protocol Source Port
Destination Port
Destination Service
Internal NIC of the reverse proxy
TCP (HTTPS)
Any 4443 Lync Front End Web Services on the Lync Front End
Internal NIC of the reverse proxy
TCP (HTTPS)
Any 443 Office Web Apps Server
PowerPoint presentation sharing
On the Back-End firewall, FW1, for traffic starting from the Edge Server, the following
ports will be required:
Lync Edge Server Rules on Back-End firewall (FW1)
Source Interface
Protocol Source Port
Destination Port
Destination Service
Internal NIC of the Edge
TCP (SIP/MTLS)
Any 5061 Lync Front End
Inbound SIP traffic
Internal NIC of the Edge
TCP Any 80 Internal C.A. CRL download or check
6.2 Network Traffic from the Servers in the DMZ to the External
Network
On the Front firewall, FW2, from the Edge Server, the following ports will be required.
It is helpful to remind you the fourth assumption: we have three different IPs on the
external network interface of the Lync Edge Server: Access, Webconf and AV. The
84
firewall rules for network traffic from the external network to the Edge will have to point
to one of the three IPs, as explained in the following table:
Lync Edge Server Rules on Front-End firewall (FW2)
Source Interface
Protocol Source Port
Destination Port
Destination Service
External NIC of the Edge (Access IP)
TCP (XMPP)
Any 5269 To federated XMPP partners
Standard server-to-server communication port for XMPP
External NIC of the Edge (Access IP)
TCP (SIP/MTLS)
Any 5061 Federation Services and Partners
Lync and Skype Federation using SIP
External NIC of the Edge (AV IP)
UDP (Stun/Turn)
Any 3478 Any Stun/Turn negotiation for candidates
External NIC of the Edge (AV IP)
TCP (Stun/Turn)
Any 443 Any Stun/Turn negotiation for candidates
Note: The dynamic port range is recommended for backward compatibility to OCS
2007 as Microsoft writes. This is only half of the truth. Also Lync 2013 makes use of
dynamic ports, but if they were closed on firewall, the ICE protocol will do a client
redirect to the static ports. If you have deployed an Edge Pool, also here it is
recommended opening the dynamic port between those servers. See the Thomas
Binder’s speech “Lync Deep Dive: Edge Media Connectivity with ICE” here
http://channel9.msdn.com/Events/TechEd/Europe/2012/EXL412
6.3 Network Traffic from the External Network to the Servers in
the DMZ
On the Front firewall, FW2, traffic from the external network to the reverse proxy, the
following ports will be required
85
To the reverse proxy from the external network on Front-End firewall (FW2)
Source Interface
Protocol Source Port
Destination Port
Destination Service
Any TCP (HTTPS)
Any 443 Reverse proxy external network interface
Access to the web services on the Lync Front End
Note: TCP port 80 could be required, for example, if you decide to publish
Lyncdiscover (used by Lync client’s for autodiscovery) using HTTP and not HTTPS.
On the Front firewall, FW2, traffic from the external network to the Edge Server, the
following ports will be required
To the Lync Edge from the external network on Front-End firewall (FW2)
Source Interface Protocol Source Port
Destination Port
Destination Service
Any TCP (SIP/TLS)
Any 443 External NIC of the Edge (Webconf IP)
Web Conferencing Media
Any TCP (SIP/TLS)
Any 443 External NIC of the Edge (Access IP)
Client-to-server SIP traffic for external user access
Federated XMPP partners
TCP (XMPP)
Any 5269 External NIC of the Edge (Access IP)
Standard server-to-server communication port for XMPP
Federation Services and Partners
TCP (SIP/MTLS)
Any 5061 External NIC of the Edge (Access IP)
Lync and Skype Federation using SIP
Any UDP (Stun/Turn)
Any 3478 External NIC of the Edge (AV IP)
Stun/Turn negotiation for candidates
Any TCP (Stun/Turn)
Any 443 External NIC of the Edge (AV IP)
Stun/Turn negotiation for candidates
86
6.4 Network Traffic from the Servers in the Internal Network to the
Servers in the DMZ
On the Back-End firewall, FW1, for traffic starting from the internal network, the
following ports will be required
To the Lync Edge from the internal network on Back-End firewall (FW1)
Source Interface
Protocol Source Port
Destination Port
Destination Service
Lync Front End
TCP (XMPP/MTLS)
Any 23456 Internal NIC of the Edge
Outbound XMPP traffic
Lync Front End
TCP (SIP/MTLS)
Any 5061 Internal NIC of the Edge
Outbound SIP traffic
Lync Front End
TCP (PSOM/MTLS)
Any 8057 Internal NIC of the Edge
Web conferencing traffic
Lync Front End
TCP (SIP/MTLS)
Any 5062 Internal NIC of the Edge
Authentication of A/V users
Lync Front End
TCP (HTTPS) Any 4443 Internal NIC of the Edge
Replication of CMS on the Lync Edge
Lync Front End
TCP (Stun/Turn)
Any 443 Internal NIC of the Edge
Stun/Turn negotiation for candidates
87
6.5 Network Traffic Related to Lync Clients in the Internal
Network
The following rules are required on any end-point firewall and on any internal
firewall that controls traffic coming from the Lync clients on the internal network.
From To Feature Protocol Port Bidirectional Note Internal Client
Lync Front End
Presence and IM AV and Web Conferencing Application Sharing Enterprise Voice
SIP/TLS 5061
Presence and IM AV and Web Conferencing
STUN/TCP
Enterprise Voice STUN/TCP 443 AV and Web Conferencing Application Sharing
SRTP/UDP /TCP
49152-65535
AV and Web Conferencing
PSOM/TLS 8057
Enterprise Voice TURN/TCP 448 Internal Client A
Internal Client B
AV and Web Conferencing Application Sharing
SRTP/UDP 1024-65535
Yes Peer to Peer Sessions
Internal Client
Lync Edge AV and Web Conferencing Application Sharing
STUN/TCP 443
Enterprise Voice TURN/TCP 443 AV and Web Conferencing
UDP 3478
Internal Client
Exchange UM
Enterprise Voice SRTP/RTCP 60000-64000
Yes
Internal Client
Voice Gateway
Enterprise Voice SRTP/RTCP 30000-39999
With Media Bypass
Internal Client
Director Presence and IM SIP/TLS 5061
88
Notes Related to the Firewall Rules Required for Lync Server 2013
Lync Server 2013 Edge Server requires DNS resolution and http access to revocation
lists of certificates. Depending from your network design, the aforementioned services
could be on the Internet or could be available using services on the internal network
(like a proxy). The following rule is to be adapted to your network layout
Additional Lync Edge Server Rules on Front-End firewall (FW2) or on Back-End firewall (FW1)
Source Interface
Protocol Source Port
Destination Port
Destination Service
External NIC of the Edge (Access IP)
TCP Any 53 DNS servers for DMZ DNS resolution
External NIC of the Edge (Access IP)
UDP Any 53 DNS servers for DMZ DNS resolution
External NIC of the Edge (Access IP)
TCP (HTTP)
Any 80 Depends on the HTTP navigation service available
CRL verifications
Note: TCP and UDP port 53 are used on the external NIC as long as the required
records for the internal resources are in the HOSTS file of the Lync Edge. Another
solution could be using the internal DNS to resolve both private and public FQDN. In
this situation open TCP and UDP port 53 from the edge to the internal DNS servers.
Centralized Logging Service (a new feature in Lync Server 2013) requires additional
ports on the back-end firewall (for more details see the TechNet article Using the
Centralized Logging Service http://technet.microsoft.com/en-us/library/jj688101.aspx
89
Lync Edge Server Rules on Back-End firewall (FW1) for centralized logging
Source
Interface
Protocol Source
Port
Destination
Port
Destination Service
Centralized
Logging Service
TCP
(MTLS)
Any 50001 Internal NIC of
the Edge
Centralized
Logging Service
Centralized
Logging Service
TCP
(MTLS)
Any 50002 Internal NIC of
the Edge
Centralized
Logging Service
Centralized
Logging Service
TCP
(MTLS)
Any 50003 Internal NIC of
the Edge
Centralized
Logging Service
Verifying a Lync Deployment in the Right Way: Tools You Will Love
(Part 2)
Now that you have configured all the required rules, you need some instrument to check
your deployment.
Lync Edge Port Tester Tool: From James Cussen (@mylynclab )
Despite the name, the tool is good to test internal server ports and client
ports too http://www.mylynclab.com/2014/02/lync-edge-testing-suite-
part-1-lync.html
Remote Connectivity Analyzer: this one requires ALSO that digital
certificates are working in the right manner. However, it is a great test to
check your firewall ports from an external internet source
https://testconnectivity.microsoft.com/
Transport Reliability IP Probe: if you are going to use Lync Online,
this tool could give you useful hints regarding your deployment
http://tripphkn.online.lync.com/
90
Verifying a Lync Deployment in the Right Way: Some High-Level
Debugging Steps if Lync Clients on the External Network Are Not
Working
In my experience over the last years, a large part of the issues related to Lync
deployments are connected with the firewall configurations. Here I will give some high-
level suggestions on how to troubleshoot a deployment that is not working correctly.
Even if you are pretty sure that the firewall is not configured correctly, I always suggest
to start the process in this listed order:
1. Check the external DNS zone and make sure the clients have nothing in the
naming cache.
a. Delete the user Lync profile under:
C:\Users\<your_alias>\AppData\Local\Microsoft\Office\15.0\Lync\Traci
ng\ b. Clear the DNS cache: ipconfig /flushdns
c. With ipconfig /displaydns check if the correct DNS resolution occurred
2. Use netstat –ano on the Edge Server to verify all required ports are listening, else
check the Lync services.
Note: to perform the next two steps (3 and 4) the Remote Connectivity Analyzer can
be very useful. However, like any tool, it does not cover any scenario and maybe you
will have to manually perform all the analysis.
3. Use a port scanner and query the ports defined in the firewall configuration
4. Check the certificate applied to the Reverse Proxy and Edge Server
5. Only now it is a good idea using OCSLogger and Snooper. Do not trace
immediately on the Edge server, start with the client log:
C:\Users\<your_alias>\AppData\Local\Microsoft\Office\15.0\Lync\Tracing\Ly
nc-UccApi-0.UccApilog
Note: Definitely you will find in the aforementioned folder also the most
interesting information about the causes why a client can’t login.
Lab
A Lync deployment with a single public IP available would require some
modification to the firewall rules you have seen in this chapter. Try to draw a schema
of the rules required for the aforementioned scenario
91
Try to explain if using a single, three-legged firewall would give some advantage
when going to manage firewall rules? Why?
Write down the hosts file that would be required on the Lync Edge servers,
supposing that you are using the deployment in figure 6.2
