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.
this is really sad by microsoft, the lync client should look for the externalURL!
ReplyDeleteSo on the resolution are you saying that for it to work the internal and external web services URL's MUST be the same?
ReplyDeleteNot really. The resolution is to make sure the internal URL is resolvable by public DNS; and published. It makes sense (if you have a split horizon DNS namespace) to use the same name and in these cases it isn't an issue. I think when the testing was done someone assumed the internal and external URL's are going to be the same.
ReplyDeleteJason: its no surprise that this whole topic is very unfamiliar to the community and also the internal+external URL trick is known only to maybe a handful people worldwide. Do you know why? Because the Lync docu team is not saying a damn word about how to do the Exchange webservices publishing properly! With EXAMPLES! Yes I know the publishing is done in the TMG code, and the webservices are running on Exchange CAS box. Yes, so whose homework is to deliver the configuration guide? Lync docu team keeps pointing to the Exchange team, write them the config guides. And the Exchange team's answer? Hey man, this is Exchange, we dont tell you how to publish and configure your stupid Lync mobile client. It is very lovely, everytime I work with Lync and face an interoperability issue between 2 MS products (read: not 3rd party, same vendor), I can start doing the "guess who" game, who SHOULD be responsible writing the document, and start digging into the bottomless pits of the technet.
ReplyDeleteI feel the pain. I can also see it from the Product Group (PG) side as well. I've found the NextHop blog posts to be great and if you search for implementation articles you often find posts from others who have extensive how-to guides. At the same time it would be prudent to have an end-to-end configuration guide for a platform which requires, or at least recommends TMG/UAG.
DeleteThat is really great to hear that we both agree, but this still doesnt resolve the problem: somebody has to make his hand dirty, and do the work actually :(
DeleteThis is still true of the Lync 2013 mobile clients - they will only try to connect to the internal EWS URL.
ReplyDelete