After an arduous few weeks building my Lync 2013 lab, I finished a typical deployment plan of getting the internal workings complete (load balancing using the Citrix Netscaler Standard free licenses, redoing certificates after signing up with StartSSL on their Class 2 validation level) then moving on to the external access. I built an Edge server and am using that for external access plus federation with Google Talk but now it was time for the dredded reverse proxy.
It’s been some time since I’ve updated my topology so I wanted to take this opportunity to share what my lab environment looks like:
Besides my onsite OWA & Sharepoint being web-facing, the web-facing components for Lync 2013 are hosting in a remote datacenter, simply due to the fact that I am limited on inbound SSL and IP addresses from my provider. A VPN tunnel provided connectivity to the internet-facing side of Lync. Even the SIP trunks provided by Asterisk are hosted here.
Onsite however, you can see that a Citrix Netscaler (Hyper-V VM) is providing load balancing for my front end pool. The Persistent Chat pool, along with the Edge Server pool, are both single member nodes and DNS is setup in such a way to resolve to these machines VS a load balancer. Im sure those will come in time!
With the topology out of the way, you can see that I’m left needing to pass my Lync web access traffic across a VPN to the load balancer – not an easy feat! I tried to use TMG, in both a single network adapter and back end firewall (two network adapter) configuration but could not get the traffic to pass properly. So after 2 installs and countless hours troubleshooting, I thought I would give UAG a try. This is simply TMG with a different interface and a lot more routing/gateway components, not to mention far more complex than TMG. So I was left with a problem: these didn’t work. I tried looking into HAPROXY, but even that was a royal nightmare to even get into.
Just by chance I happened to be browing the Technet forums and stumbled across a link to Richard Bryntenson’s article on using the IIS web platform module “Application Request Routing” as a TMG replacement. After wasting hours with TMG/UAG, I had nothing to lose. I already had the VM in a WORKGROUP, stripped down to a single network adapter. Firewall ports 80/443 already forwarded, and nothing really but IIS installed.
On my non-domain joined Windows Server 2008 R2 SP1 server (which is still called VL-UAG-01) with a single network adapter, I ran the Web Platform Installer module and installed the 3.0 BETA component plus it’s prerequistes:
Afterwards, I followed along with the rest of Richard’s instructions, with a few exceptions:
- For my server farm, I used the IP address of my load balancer. I tried to add in both of my FE servers individually, but when I did I would get a “Page Cannot be Displayed.”
- I created a clean IIS site and bound the IP (versus using All Unassigned) to each port. As the instructions provided, I already had my FE certificate imported and bound on port 443.
- I did disable the autocreated HTTP rule and created a Lyncdiscover rule for mobility autodiscover.
- While I messed around with the different URL rewrite rules, I did not use either option A or B. I ultimately ended up putting the SSL rule back to the defaults. This seemed to work the best.
- The autodiscover rule as follows:
- Finally, for the proxy keepalive, I set this to 1800 seconds as a result of a comment I read at the Nexthop blog regarding Lync mobility. The comment was that mobility checks in at 180 and 900 second increments, so keeping with a divisible number into these (see, you do use math in IT) I kept it over this. No problems with my Lync 2013 client on my Android!
With all of these in place, I was still running into an odd issue. I would hit the Lync FE servers, and while it would try to load the meet or dialin URL, it would give a 404 error trying to access the subpath (IE lwa/WebPages/LwaClient.aspx for the MEET url, and /Dialin/Conference.aspx for the DIALIN url). The IIS logs showed a 443, which was odd. I also tried looking at Failed Request Tracing, but it got me nowhere.
Turns out, just by sheer luck, I reenabled SSL offloading, hit Apply, unchecked SSL offloading, hit Apply, and when trying again it worked!
I immediately opened my Lync client offsite, and through the Edge started a meeting. Then, using RDP to another network, attempted to join and was successful! I stayed connected for 5 hours with no issues. I also was connected to a chat in Lync via my Android with no problems for hours.
Needless to say, this accidental discovery of “Application Request Routing” is probably one of the biggest finds to date. My next step will be to try and bind additional IPs to the IIS box and work to publish Exchange and Sharepoint through the web-facing datacenter. Then I can free up an IP, my only IP, for use at my onsite datacenter 😎