Setup a Fully Functional Lync 2013 Lab Using only One Public IP Address

Note: This article assumes you know how to setup Lync 2013 already and just need to know the intricacies of changing the default ports.

Ever since I was exposed to Lync in 2011, I've been a huge proponent of using chat to communicate at work. Years ago, I recall corporate chat being a hard sell, but now it seems generally accepted; many customers who don't use chat are open to it, they just haven't have the resources to set it up yet. I've setup Google Apps w/Talk for small businesses in the past, but I've have been curious implementing Microsoft Lync on-premise so I setup a lab last week to better understand it.

Because my lab is limited on RAM, I attempted to use just one server to accomplish everything I wanted -- chat, "PC-to-PC" calls, and video conferencing. I was able to get chat working fine for internal and external users, but video conferencing and calls failed for users who were not on the same internal network.

After learning about the Edge server's role in providing media services, I gave in and added an Edge server to my topology. I also added a Reverse Proxy because holy smokes, setting up a Reverse Proxy using IIS ARR was way easier than I thought it'd be (and I already had a web server that could do this.)

Here's the thing about the Edge server: both the Front End and the Edge server use port 443 for very different things. Autodiscovery, which is provided by the Front End/Reverse Proxy, requires HTTPS (though you can use HTTP but I don't want), and Autodiscovery was a requirement that I gave myself so, I was left having to modify the A/V port for the Edge server. In the setup below, you can see that I changed it to port 442. Modifying the port in the Topology was easy enough, but then I had to figure out exactly what DNS records needed to change.

The DNS change seems obvious now, but I started this with little knowledge about AutoDiscovery and service records. Because of this, I ended up with a ton of unnecessary/incorrect DNS entries.

Here's how my lab is configured:

* I'm not entirely sure this needs to be exposed, but I opened mine anyway. ** In order to support the widest variety of Lync clients, 5061 appears to
be required for authentication even if you don't do federation.

Some DNS providers offer an SRV Host field. This is useful if your users authenticate as [email protected] instead of [email protected]. In this case, "x" would be your host. Also, I've seen different numbers of Priority and Weight. I left mine at 100 and 1, though I've seen it at 0 and 0. I don't think it matters much unless you're doing load balancing.

Also, after examining client logs, I noticed that some external logins for desktop clients failed when sip.acme.com didn't exist, so I added it to DNS. Microsoft documentation mentions A records in a whole lot of places, but I found CNAMES work just as well.

A few things to note:

I didn't hook Lync into Exchange and I didn't even attempt Enterprise Voice because I don't have the equipment (or desire.) Authentication was accomplished by adding [email protected] to each AD account email property, then using [email protected] as the sign-in name and ad\username for User Name. Of course, my domain's Root CA cert had to be installed on all of the client computers, including mobile devices.

I did test to see if Office Web Apps was required for Lync-to-Lync calls (it wasn't) and blew up one of my server's IIS configs in the process. OWA doesn't like to share and deletes all of your IIS Sites during configuration, so don't install it on a server that does anything else related to IIS.

Also, if you have just one internal subnet and you're comfortable with the security repercussions, you don't need a reverse proxy -- just a router that can forward from port 443 to port 4443. Also, your edge server will need 2 IPs (no way around that), so you can just give it two on the same subnet and make sure your router NATs to the "External" IP of the Edge server as listed in the Lync Topology.