Although instant messaging (IM) is one of the simplest features offered
by Lync Server 2010, it is nonetheless important to plan for the
implications of supporting this feature. Decisions around remote users,
public users, and federated users influence how the environment is
architected and deployed.
1. Considerations for Internal Users
When planning a deployment including IM, there are a few items to
take into consideration when there will be internal users on the
system. Although things such as server capacity are accounted for with
the capacity planning of the Front End Server, it is important to
consider the following impacts:
• Compliance and regulatory requirements
• Impacts on supporting systems
• End-user training
• Appropriate usage policies
When planning a deployment, always be aware of laws and regulations
that might affect your users and your implementation. For example, find
out whether there are requirements around archiving IM traffic for
particular departments such as legal, finance, or executives. If there
are, be sure to account for the Archive role in the deployment and
determine how much space is required to archive the data for the period
specified by company policy or specific applicable regulations.
For general users, determine whether there will be integration
between the Lync client and applications such as Outlook. By default,
Lync wants to store conversations in Exchange so
that they can be recalled later by the user. If this will be enabled,
account for the added storage usage in Exchange. If storage quotas are
already enforced in Exchange, this might not be an issue, but users
should be made aware that their usage within Exchange might increase
and that they might end up with a shorter window of messages in their
mailbox in order to stay within their quota.
Tip
Consider creating archive rules within Outlook to manage the Conversation History folder.
One area often missed by deployments of enterprisewide applications,
such as Lync Server 2010, is the creation of appropriate end-user
training. Although administrators spend a lot of their time researching
and learning technologies, most end users do not. As such, it is the
responsibility of the team deploying the application to develop
training for end users. This typically should consist of cheat sheets
explaining how to perform basic tasks and when possible, include
screenshots to make it clear to users where to click and what to do.
The last thing to consider when planning a non-voice deployment of
Lync Server 2010 is the creation of an appropriate use policy. This is
where you can set the rules around the usage of IM and define behaviors
that are to be avoided. For example, although it might seem common
sense to some, set a policy stating that instant messaging is not to be
used to send sensitive materials outside the company.
Tip
By setting guidelines ahead of time, you
greatly reduce the chances of the new tool being used to circumvent
other protective measures that have already been put in place in the
enterprise. The main point is to make sure that IM is seen as another
potential source for data leak.
2. Consideration for Remote Users
One of the big strengths of Lync Server 2010 is the capability to
communicate with users that are outside the corporate environment. This
might include partner companies or it might include random users on the
Internet who need to participate in the occasional conversation and
usually includes internal users who are in remote locations. When
planning for Lync Server 2010, be mindful of which scenarios need to be
supported. Typically, account for the following three major groups of
external users:
• Remote users
• Federated users
• Public users
A remote user in this context refers to one who belongs to
the organization but needs to connect from outside the organization.
This might include situations in which the user travels or otherwise
connects to Lync Server 2010 without the benefit of a virtual private
network (VPN) connection into the network.
The primary consideration for remote users include planning for
availability of the Edge Server role to ensure that they can always get
a connection into the Lync Server 2010 environment and to plan for
integration of certificates for Secure Sockets Layer (SSL) connections.
If the Lync Server 2010 deployment uses public certificates, this
will likely not be a problem because the major public certificate
authorities are already trusted by the operating systems supported by
the Lync client and the Communicator client. If, on the other hand, you
plan to use an internal Certificate Authority, plan for not only the
deployment of the root certificate into the certificate trust store of
the clients, but also ensure that the Certificate Revocation List of
the Certificate Authorities involved are reachable by users when they
are connecting remotely.
Because most Lync Server 2010 deployments using internal PKI use
Active Directory–integrated certificate authorities, typically you can
depend on the directory to present the CRL to clients. Because domain
controllers are almost never exposed to a demilaritized zone (DMZ) or
the Internet, you must depend on the HTTP publishing of the CRL.
Because this needs to be reached by remote clients who aren’t connected
to the internal LAN, the CRL path in the CRL distribution point should
reference a web server that is reachable through the Internet. This
ensures that systems can access a valid CRL to ensure that the
certificates are good and thus enable successful connections over SSL.
The other value of an HTTP published CRL is for the support of
clients that aren’t bound to Active Directory. In many environments,
Macintosh computers, which can run the Communicator client to connect
to Lync Server 2010, aren’t bound to Active Directory. As such, they
can’t access the CRL through the LDAP path, so they’ll end up using the
HTTP path for CRL checking.
Federated users refer to those from companies that also run
Lync Server 2010 or older versions of Office Communications Server,
such as OCS 2007 or OCS 2007 R2. Federating is the creation
of a formal relationship between the two environments that give each
the capability to share contact lists and presence information with one
another. The primary items to plan for are the creation of an external
access policy and the establishment of a list of federated domains.
Both of these items are configured through the Lync Server 2010 Control
Panel in the External User Access pane.
Planning for public users means making a
determination of whether or not the Lync Server 2010 system will
integrate with existing public IM services such as Yahoo!, AOL, or MSN.
This gives the capability to consolidate all IM traffic into a single
client because users would no longer need a secondary client to talk to
their public contacts. This can be especially useful in environments
that archive IM traffic for regulatory or compliance reasons. It also
enables users to potentially use an existing public IM identity through
Lync to maintain their original identity in the eyes of Internet public
IM users.
Some additional public services can be integrated by using an XMPP
gateway. This allows integration with Google Talk as well as Jabber.
Note
Public IM connectivity with MSN,
AOL, and Yahoo! requires a separate license. If you plan to offer
public IM connectivity, don’t forget to purchase the license and
account for the fact that it might take several weeks for these
providers to process the SIP routes.
