Deep Diving into Lync, Part 2

By Chris Blackburn

This second part of the deep dive into Lync takes us into the foundation of our Lync deployment – the topology – as well as the key for connectivity outside of business wall. This is just one of the areas where Lync truly shines and gives it more hope in its future than its closest competitors (Cisco, etc). Even Gartner’s Magic Quadrant for Unified Communications, last rated in August 2011, has Microsoft leading the pack.

Topology

With Lync, Microsoft delves into a new direction by requiring the technical design of the environment, configuring settings, etc, before you even build the first server. Whether building a Standard edition deployment with a single server, or an Enterprise edition deployment with multiple farms and sites, planning ahead of time is now a necessity.

Within Lync expanding your existing environment is simple, given you have Windows plus the prerequisite items installed. Once the topology is updated, it’s simply a matter of installing the local configuration store (IE, the SQL database that holds a copy of Lync topology information on each server) then running Setup to have the server automatically pull down the components related to that server’s place in the topology

While a Standard deployment can handle all of the necessary roles needed for a basic deployment of up to 5000 users, there is no redundancy OR scalability. For a RFP or test lab, its great, but the best place to start is an Enterprise deployment. You can build “pools” of servers and use load balancing, providing multiple points of “strength”, versus a single point of failure.

In your topology, the minimum requirements will look like this:

  • SQL server to run the Lync Configuration store database
  • File server to house the lyncshare (central management files, address books, etc) – this can also be the database server
  • First server of the front end pool
  • First server of the edge pool

Then also have some “supporting” roles:

  • Active Directory domain controller
  • Internal certificate server (if you’re not using trusted third party certificates) – this can also ride on the domain controller
  • Reverse Proxy, like Microsoft Forefront Threat Management Gateway (TMG)
  • Microsoft Exchange 2010 with Unified Messaging (UM) role – this is necessary for voicemail in an Enterprise Voice role

In the initial configuration of Lync, your Front End pools will automatically be populated, as well as your File & SQL stores. This will provide you with a basic IM & Presence experience. With the recent introduction of Lync Mobility and Autodiscover services, firewall setup for the Front End Pool by way of a reverse proxy, as well as in conjunction with an Edge features (AV/Conferencing/Desktop Sharing/File Transfer), are big selling points for remote access.
Access for remote users, as well as connection to federated partners, requires the setup of an Edge pool. For a full list of what features fall under external access, see http://technet.microsoft.com/en-us/library/gg398157.aspx
Finally, the A/V Conferencing Pool (Web & PTSN Conferencing) and Mediation Pool (Enterprise Voice) are all Enterprise CAL features and would depend on your deployment.

Edge Server

With this “deep dive” into Lync, given that the Front End servers are part of the foundation (similar to a Windows installation on a PC), I’m not going to touch much on it but plan on covering it more at a later time as part of a NLB piece.

In referencing back to Technet on the reasons: Why do I need an Edge server? Does IM & presence (and even now, the new Lync Mobility) outside of my network mean I need an Edge server, when they touch only the FE pool? The short answer: Yes, and Technet helps spell this out: http://technet.microsoft.com/en-us/library/gg425727.aspx. And while Microsoft spells it out as being an Edge server and reverse proxy, I have successfully implemented this several different ways (and, all virtual):

  • Edge server with a Hardware Firewall as the reverse proxy (port redirection of 8080/4443 to 80/443)
  • Edge server with a one-legged (single NIC) reverse proxy (TMG) on the private LAN
  • Edge server with a dual NIC reverse proxy

The Edge server network configuration has a few tricks to make it simple, yet effective.Keep in mind that the Edge server is not a domain joined PC, require 2 network adapters, and a dedicated external IP address for NATing traffic properly.

The private adapter only needs the IP/subnet, and NO GATEWAY. Instead, we add a static route (if the adapter is on a different subnet than the Public adapter).

The Public adapter has its Gateway plugged in and the rest of the IP information assigned normally.

For a full walkthrough on the Edge setup, check out Kevin Peter’s blog post.

Reverse Proxy

Without reinventing the wheel too too much I’ll defer a full setup of the Lync Reverse Proxy using ForeFront TMG to DrRez’s walkthrough: http://blogs.technet.com/b/drrez/archive/2011/02/21/remote-conferencing-with-lync-web-app-with-forefront-threat-management-gateway-2010-reverse-proxy-part-1.aspx

With our reverse proxy dedicated to the Lync environment, its a one-legged reverse proxy. This means its not really sitting between the internet and our network but rather solely on the LAN as the hardware firewall’s endpoint for routing traffic TO the Front End server. It runs great as a VM, and only needs one network adapter.

Then, we really only have 1 Firewall rule in the device.

We then specify to redirect the ports to the Lync Internet Web Site on the Front End server

The web publishing rule listens on the primary URL for our Front End pool, plus as another benefit of Lync is hard-coding the URLs that it listens on.

The Web Publishing rule has a corresponding listener, that redirects to the Bridging ports above

And requires a copy of the SSL certificate that was on the FE pool, so make sure when you request it so its exportable.

There are some areas in the reverse proxy that are of importance:

Authentication Delegation is a big item to be aware of, because if you’re dealing with external clients (especially non-domain users). Using the “client cannot authenticate directly” states that the user must directly authenticate to the Lync server, which in the case of a reverse proxy, wont happen.


What will happen is that users will get a popup asking them to authenticate, after the 3 times it allows and despite the correct credentials, it will fail.

The solution is to change the Authentication Delegation to “client may authenticate directly”, which passes authentication through the proxy to the destination host.

Share your thoughts

css.php