Me, Myself and I

Cool – testing PIC making a call between Lync and Windows Live messenger on the same PC  with two webcam’s.

Lync reverse proxy using IIS ARR

Disclaimer : this is part of my Lab install series of posts, it works for me in my lab with a  small number of users but is neither a recommended or supported topology (AFAIK).
I have Lync standard edition server with mediation on the front end running in media bypass mode, Lync Edge server and Exchange server 2010 running on a single server with all roles.
I have decided to use IIS ARR + URL Rewrite as my reverse proxy for Exchange OWA, web services, etc and Lync reach client and web services all on my Lync Edge server. I did this because its already internet facing (and therefore ‘at risk’) and I figured its better to keep machines like this at a minimum. It is also the only machine not domain joined and has very few permissions on my network. Of course I could have setup ISA / TMG / whatever, but I want to focus on building software, not maintaining infrastructure.

1. Ensure IIS and .net are installed.
2. Download & Install ARR (includes rewrite).
3. Add a binding for your certificate (As this is on my edge server and I use the same certificate for both SIP and HTTPS I already have it installed on the machine)
4. Setup server farms for Exchange and Lync
1. 
2. (select advanced settings, choose ports 8080, 4443 – which point to the external bindings on the front end server))
3. (Choose Yes if you see this)
4. (double click routing rules)
5. (ensure URL rewrite is checked and optionally SSL offloading – depending on your bindings on the target server you may need this checked)
6. Repeat from step 4 for Exchange
7. Go to the URL rewrite configuration, either by clicking the link on the right pane on the routing rules screen in step 5 or on the main URL Rewrite icon under IIS when on the Features page for your server.
8. Modify the Lync rule as follows:
   
   Choose Using Regular Expressions and enter this expression :
   

   ((?:^dialin|^meet|^Fonts|^Abs|^CertProv|^ColabContent|^GroupExpansion|^LMStaticData|^MeetingContent|^MeetingFiles|^Reach|^RequestHandlerExt|^RgsClients|^WebTicket).*)

   
   
9. Same for Exchange with this expression :

   ((?:^owa|^OAB|^Microsoft-Server-ActiveSync|^EWS|^ecp|^Autodiscover).*) 

   Also select https protocol (depending on your bindings for exchange)
   
10. For completeness I have an OCS R2 CWA server in my Lync farm and have added a similar proxy for that too.

Now lets test

1. Go to https://yourdomain/owa
   
   
2. You should also run the tests here https://www.testexchangeconnectivity.com/
   
3. Go to https://yourdomain/meet
   (you can also create and join a meeting in outlook)
   
4. Go to https://yourdomain/reach/client/webpages/reachclient.aspx
   

Federating with everyone.

In order to use federation with OCS, OCS R2 and Lync you must obey this:

• The certificate must be issued by an approved public CA that supports subject alternative name. For details, see Microsoft Knowledge Base article 929395, "Unified Communications Certificate Partners for Exchange Server and for Communications Server," at http://go.microsoft.com/fwlink/?LinkId=202834.

This is a short list of official certificate providers :

Entrust
http://www.entrust.net/microsoft/ (http://www.entrust.net/microsoft/)

Comodo
http://www.comodo.com/msexchange (http://www.comodo.com/msexchange)

DigiCert
http://www.digicert.com/unified-communications-ssl-tls.htm (http://www.digicert.com/unified-communications-ssl-tls.htm)

Now in reality (and if you don’t need to be in a fully supported configuration) you just need a certificate that is issued back to a root certificate that you know everyone has. So assuming you might be federating with partners using OCS, OCS R2 or Lync Server 2010 we can assume their edge is running Windows 2003, Windows 2003 R2, Windows 2008 or Windows 2008 R2. So to narrow down your requirements you want a certificate that we know is installed by default on those platforms. In theory on Windows 2008 the root certificates are supposed to auto download on demand – however it seems OCS R2 doesn’t demand them, so they don’t get downloaded . Ok… so this is now quite a short (and getting shorter) list. So if you encounter weirdness that you can federate with some partners but not others then chances are that their certificate is issued by a root cert not installed in your system.

So as a certificate buyer, you really should buy a cert from an officially approved vendor. That said, after a bad experience with federation using GoDaddy certs, in my lab, I use (in an unsupported manner – as I use a single CN and don’t list any SAN’s) a RapidSSL cert from ServerTastic for $13.00 per year for a single domain cert – conveniently its issued from a root cert by GeoTrust / Equifax, which is far more prevalent than GoDaddy. I have had no issues since using this cert.

As a federating partner, if you want to expand your scope to ‘cheap’ federation partners, try installing the latest root certificate package here – after reading the warnings here .