Simple URL Exceptions
The first, and probably the most obvious task is to make sure that you have exceptions in place for your Lync Simple URLs. These URLs are designed so that the root path you connect to stays the same whether you connect internally or externally (i.e. https://meet.sipdomain.com). This can create a bit of a conflict, particularly in deployments with split-brain DNS because the SIP domain is usually not considered an "internal" address space and will, by default, get routed through the web proxy. Regardless of which Simple URL design you choose, internal users will be connecting to the internal web services hosted on the Lync Front End servers and sending this traffic through the web proxy is less than ideal.
Using the Simple URL Naming Options from the Planning Guide (found here), I'll outline the exceptions for each design below:
Simple URL Naming Option 1
https://meet.contoso.com, https://meet.fabrikam.com, and so on (one for each SIP domain in your organization)
Simple URL Naming Option 1 Exceptions:
- meet.otherSipDomain.com (1 per each supported SIP domain)
Simple URL Naming Option 2
https://lync.contoso.com/Meet, https://lync.fabrikam.com/Meet, and so on (one for each SIP domain in your organization)
Simple URL Naming Option 2 Exceptions:
- lync.otherSipDomain.com (1 per each supported SIP domain)
Simple URL Naming Option 3
Simple URL Naming Option 3 Exceptions:
As you can see, Simple URL Naming Option 1 will result in the most exceptions for the web proxy. If you're leveraging Group Policy to apply the exceptions, make sure that you keep in mind the 1024 character limit for the GPO. If there are already a significant number of exceptions in the list, Option 1 can easily drive you past the character limit. For organizations that support a large number of SIP domains, then Option 3, in my opinion, is really the only choice.
Internal Web Services Exception
If you've kept Best Practices in mind when deploying an Enterprise Edition Front End pool, you'll have implemented a "hardware" load balancing solution to handle the session-sensitive HTTP/S traffic destined for your Front End pool. You'll also have overridden the internal web services FQDN so that it differs from your Pool FQDN. Typically, I will assign the Lync internal web services FQDN a name from the internal DNS name space so that it will be excluded from web proxy filtering automatically. However, if you run into a situation where internal addresses are not automatically bypassed, or the internal web services FQDN assigned is in an external domain, you will need to add it as an exception as well.
Issues Encountered Connecting to External Meetings
In a couple of cases, I have run into an issue where internal users were having problems joining Lync Meetings hosted by external organizations. The most common issue is when an internal user tries to join a meeting hosted by a federated organization. In the majority of these cases, the user was not able to join the meeting because they were not enabled for Federation by policy. Lync prevents the user (who is not enabled for federation) from joining a meeting hosted by a federated partner to prevent circumvention of the External Access Policy assigned to the user.
In one instance, I had an issue where internal users could not connect to external Lync meetings with their full Lync client, regardless of who they were hosted by. Users were enabled for federation, and everything else was working as expected. We were able to hit the root meeting landing page and received the error stating we had an invalid meeting ID. We were also able to connect to the meeting by forcing the use of the Lync Web App (by adding ?sl=1 to the end of the meeting link). However, when we clicked through to the meeting from the invite, IE would just hang (white screen) and never take us into the meeting. Ultimately, we ended up having to disable the HTTPS inspection that their web proxy was performing. Apparently the web proxy didn't like the fact that (or the way) that Internet Explorer was launching an external program, and therefore blocking the handoff from IE -> Lync client.