Lync 2013 external access to Exchange Web Services (EWS) via TMG

***** UPDATED as I realised the procedure wasn't quite right *****

I recently deployed Lync 2013 with external access at a client who runs Exchange 2010 with external access via TMG.  During initial testing all was well but later testing showed that both the Lync mobile client and Lync 2013 full client couldn't connect to EWS externally.

I'd already created pass-through rules for autodiscover and EWS (more on that later) and I was pretty sure Lync was setup correctly.

The front end's Lync Server event log was showing error ID 32054 for the LS Storage Service:

Storage Service had an EWS Autodiscovery failure.

StoreWebException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed, smtpAddress=test@domain.public, Autodiscover Uri=https://autodiscover.domain.public/autodiscover/autodiscover.svc, Autodiscover WebProxy=<NULL>, WebExceptionStatus=TrustFailure ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
.......(truncated)
Cause: Autodiscovery Uri was not correctly configured or unreachable, that there is a problem with the Proxy, or other errors.
Resolution:
Check event details.  Check autodiscovery Uri is properly configured and reachable. Check that proxy setting is properly configured and reachable.  Validate Lync to Exchange Autodiscovery configuration by following the trouble shooting guide. If problem persists, notify your organization's support team with the event details.

Watching the TMG logs I noticed that connection attempts to Autodiscover were initially anonymous, unauthenticated and successful, followed by another successful connection but with a http response of 405 "method not allowed".  There were no subsequent EWS connections.

Then I randomly tried to connect from a different external location and everything worked, the Lync client successfully connected to EWS and all meetings and conversations appeared!!!

I started to realise there may be multiple issues so I looked at the front end server's event logs again.  The front end server was attempting to update my Lync account's presence information by connecting to a CAS.  The SIP domain uses the public namespace as Exchange (e.g. domain.public) which is different from the AD forest domain name (e.g. domain.internal).  The event log error showed me that the front end server was trying to connect to autodiscover using the public domain.

It seemed to be connecting but failing so I checked and there was a DNS record internally for autodiscover using the public domain (autodiscover.domain.public).  Then I realised that the CAS server certificate didn't include autodiscover.domain.public.  Why would it?  No prior need for it internally!  I re-issued the Enterprise CA certificates to the CAS servers and included all the public names on it, too.  Ta-da!  No more 32054 errors.

Back to TMG.  I'd correctly planned and deployed new rules for autodiscover and EWS using the web listener I'd created for Lync as it doesn't require authentication and the edge firewall will already have TCP 443 passing through to it.

Here's my method for this:

1. Assign a new public IP address for Autodiscover/EWS and route/NAT it through to TMG on TCP 443
2. Create a new public DNS A record for EWS (e.g. ews.domain.public), pointing to the newly-assigned IP
3. Add the new IP (or NATd IP) to TMG's external NIC
4. Create a new TMG web listener for EWS:
1. Require SSL
2. Listen on the EWS IP
3. Use the Exchange certificate
4. No authentication
5. Create a new TMG Exchange 2010 web client access rule above the existing Exchange rules:
1. Use Outlook Anywhere with additional folders
2. Use the EWS web listener
3. Use two public names: autodiscover.domain.public and ews.domain.public
4. Set the authentication delegation to 'No delegation, but client may authenticate directly'
5. Set the users to 'All Users'
6. Remove all paths except for /ews/* and /AutoDiscover/*
6. Change the Exchange web services virtual directories' external URL to use the new public name ews.domain.public (e.g. to change all CAS servers: Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -ExternalUrl https://ews.domain.public/EWS/Exchange.asmx)
7. Change the autodiscover public DNS record autodiscover.domain.public to use the same IP as ews.domain.public

Back to the problem, in TMG I watched the logs while I tested logging on to various Lync clients externally.  I had one of those 'I'm so dumb' flashes: TMG was configured to send traffic to a web farm of two CAS servers.  One was responding correctly, the other wasn't.

I looked at the rogue CAS and couldn't see any issues in the logs or any other signs that it wasn't working properly so I used the EMC to reset the Autodiscover virtual directory then ran iisreset /noforce.

That was it, all my external Lync 2013 clients were now able to access EWS and display meetings and conversations, no matter which CAS they hit.  Mucho happy me!


This post in its entirety is the copyright of Roland Paix. I don't mind if you link to it but if you copy any of the content you must provide a link to the post and credit me appropriately.