Those who are familiar with publishing OCS Web Components through a reverse proxy may be in for a bit of a surprise when they go to publish their Lync services to the world and find the friendly meeting URLs not working . Unlike OCS, Lync depends on the host headers to route users correctly to the friendly meet and dial-in URLs. This means that although the services are using the same IIS website, going to https://<Friendly Meet URL>/somepage and https://<Web Components URL>/somepage are actually handled differently. In other words, you can’t take a meeting link, replace the friendly meeting URL part with the web components address and expect it to work even if the destination web server is the same.
Note the Forward the original host header instead of the actual one (specified in the Internal site name field) selection box is checked. This ensures the reverse proxy passes along the original URL the user requested so IIS knows what content to serve up. If you don’t select this option the reverse proxy will simply pass along the Internal Site Name field (lync-fe1.confusedamused.local in this case) as the host header. This works for web components, but not Meet or Dial-In URLs.
And while not the focus here, but another “gotcha” is to make sure you include the Meet and Dial-In friendly URLs on the Public Names tab for the rule or the reverse proxy won’t respond to external requests for those names.