Configuring Lync for External Access

Out of all the posts I've made on this blog, the one post that gets the most page hits and has generated the most comments is my post on http://maxyaquos.blogspot.com /2011/01/lync-external-web-services-without.html">Lync External Web Services without Reverse Proxy. Obviously, there are a large number of users that don't want to deal with putting in a reverse proxy solution such as ISA or TMG.

I always recommend that companies do use a reverse proxy instead of going direct to the front-end, simply because its more secure.  Opening up any domain-joined server to the Internet directly is risky, but as long as the company understands the risks, I will configure Lync to work without a reverse proxy.

The majority of comments on my aforementioned post are questions around which DNS names point to what, and what ports to open to where.  This post will attempt to clarify how to configure Lync for external connectivity by using a simple example with a single Standard Edition Lync front-end and a single Lync edge server.  This is the minimum number of servers required to provide all Lync functionality, and is the most likely configuration for a lot of small companies with limited resources.

The Lync team has done an admirable job of simplifying what has typically been a complicated install process.  The Topology Builder and the Deployment Wizard make it so that complex Lync installations can be done with relative ease.  However, I have found that administrators get confused fairly early in the deployment process and if things aren't done right, problems will arise later.

Web Services URL
Imagine a small company called Contoso (yes, original, I know).  Their external web presence uses contoso.com and their internal Active Directory domain name is contoso.local.  They are in the initial stages of their Lync deployment and are using the Topology Builder to configure their deployment.  As with a lot of administrators, rather than spending days reading the reams of documents around Lync, they have decided to dive right in.  Things go well using the Topology wizard, and most things are clearly explained and the admin can click Next with confidence.  They set the SIP domain to contoso.com and the front-end server name to FE.contoso.local. 

However, once they get to the Specify the Web Services URL screen, things will be set incorrectly if they accept the default and click Next.

The Web Services URL is a hidden URL used to direct Lync clients to the proper place to download address book files, meeting content and other things.  This connection is done via HTTPS.  Internally, the client uses the internal FQDN of the server (FE.contoso.local), but externally, they will need to use a publicly accessible URL.  Since contoso.local is not a publicly accessible domain, they should use contoso.com.  It doesn't really matter what the URL is (clients never see this), but I will use LyncWeb.contoso.com in this example.  For deployments with multiple front-ends and/or directors, I would use something a bit more descriptive like LyncFE1.contoso.com.

Edge Configuration
Now, with that set properly, the administrator can continue on to the edge configuration.  The FQDN of the edge pool should be something like Edge.contoso.local, but it could really be anything.  The next critical thing is the external FQDNs.  Again, since clients need to be able to access this URLs externally, it must be a publicly available URL.  With the edge, you can either use a single URL or 3 separate ones for the Access, Web Conferencing and A/V URLs.  I recommend using 3 separate URLs if you have the available external IP addresses.  If you elect to use a single URL, you may have A/V issues  with companies that still use OCS.  In this imaginary case, we used SIP, WC and AV (all contoso.com).

If you are NATting your edge server (and you selected The external IP address of this Edge pool is translated by NAT on the Select Features page), you will be presented with a page that will likely make you pause and wonder:

If you are using only a single IP for SIP/Web/AV, then it should be pretty straightforward what to put here.  You would put the public IP address that external users will connect to.

If you are using separate IPs for each service, then you need to type the public IP address of the A/V service.  Lync needs this information so A/V services will work reliably across the NATted interface.  I'm hoping Microsoft will make this dialog box more informative in a future release. 

Meet/Dialin URLs
Once you enter the required IP addresses and finish the wizard, you should have all that is required to install Lync on your servers.  At the main Topology Builder screen, you will notice the Simple URLs have been automatically set to https://meet.contoso.com and https://dialin.contoso.com.  These URLs are used by clients to join meetings, view dial-in access numbers and change their PINs. You can accept this default, or if you are trying to minimize costs, you can change the URLs to something else like https://Lync.contoso.com/meet and https://Lync.contoso.com/dialin.  This way, you can get a cheaper certificate without a SAN.

External Network Configuration
For all this to work, you will have to make several firewall rules and DNS entries.  Since a picture is worth a thousand words, I figure I'd summarize it with this snazzy Visio I made for a design doc for a client (click on it for a larger view).

The main points to notice is that both Lync.contoso.com and LyncWeb.contoso.com end up pointing to the internal Lync front-end server. If you follow my blog post that describes http://maxyaquos.blogspot.com /2011/01/lync-external-web-services-without.html">how to configure external access without a reverse proxy, you can eliminate the ISA/TMG server shown here (again, can't stress enough that you SHOULD use a reverse proxy if possible).  Everything else points to the edge server. 

Certificate requirements should be relatively self-explanatory.  One exception is the internal SRV record.  You will notice that I used contoso.com instead of contoso.local for both the SRVLync clients will automatically query for an SRV record for contoso.com, but by default will reject the connection if the SRV record points to a different domain (ie. contoso.local).  You can override this with a registry key, but its likely easier if you create a FE.contoso.com A record (and add that name to the front-end certificate). 

Hopefully, this post will clear up the questions that often come up as a result of my Lync without a reverse proxy post.  If not, please let me know in the Comments section.