Consider the following:
An organization uses two different DNS records for their Exchange Web Services URL:
Internal URL:https://exchange.contoso.com/ews/exchange.asmx
External URL:https://outlookweb.contoso.com/ews/exchange.asmx
The internal URL is not registered in public DNS. You sign into the Lync Mobile client from an iOS device. The client signs in but you receive an error shortly after indicating “Can’t connect to Exchange Web Services. You can try again later”.
Upon viewing the iOS logs we see the device receive only the Internal URL through the Exchange Autodiscover process. The External URL is never queried by the device and it’s unknown at this point if this parameter is given to the client or not.
What IS known is that the iOS client will only use the Internal URL parameter, in this case https://exchange.contoso.com/ews/exchange.asmx.
What IS known is that the iOS client will only use the Internal URL parameter, in this case https://exchange.contoso.com/ews/exchange.asmx.
Additional Notes:
1. A common misconception out there is that the iOS device cannot connect to UAG when it’s used to publish the Exchange Web Services, Autodiscover, or Outlook Anywhere URL’s. There is an issue where UAG is used to publish the Lync Mobility URL’s (lyncdiscover and external web farm fqdn).
2. You MUST enable Outlook Anywhere on your Internet facing CAS servers for the Autodiscover URL’s to be given to clients (iOS/Lync 2010) on the Internet. However, you don’t have to publish the “/rpc/*” path through UAG/TMG.
a. The same applies to the Lync 2010 client when it queries for conversation history or voicemail from Exchange when signed in remotely.
3. You CAN use UAG to publish Exchange URL’s with TMG publishing the Lync URL’s.
Resolution:
1. Publish your internal EWS FQDN in public DNS and make sure your TMG or UAG server has a certificate matching the public name you're using. If you have a wildcard certificate you're fine.
2. Consider making the Internal and External Web Services URL's the same.