Consideration for Remote Users

One of the big strengths of Lync Server 2013 is the capability to communicate with users that are outside the corporate environment. This might include partner companies or 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 2013, 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 2013 without the need for a Virtual Private Network (VPN) connection into the network.

The primary consideration for remote users includes planning for availability of the Edge Server role to ensure that they can always get a connection into the Lync Server 2013 environment and planning for integration of certificates for Secure Sockets Layer (SSL) connections.

If the Lync Server 2013 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, you should not only plan 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 2013 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 demilitarized 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 Lync:Mac client to connect to Lync Server 2013, 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 2013 or older versions of Communications Server. Federating is the creation of a formal relationship between the two environments that gives 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.

Planning for public users means making a determination of whether the Lync Server 2013 system will integrate with existing public IM services such as AOL, MSN, or Skype. 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 IM-only integration with Google Talk as well as Cisco Jabber.