Thursday, May 17, 2012

RESOLVED: Lync iOS Mobile ERROR: Can't connect to Exchange Web Services. You can try again later.

Consider the following:

An organization uses two different DNS records for their Exchange Web Services URL:



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.

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.

8 comments:

  1. this is really sad by microsoft, the lync client should look for the externalURL!

    ReplyDelete
  2. So on the resolution are you saying that for it to work the internal and external web services URL's MUST be the same?

    ReplyDelete
  3. Not 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.

    ReplyDelete
  4. Jason: 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.

    ReplyDelete
    Replies
    1. I 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.

      Delete
    2. That 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 :(

      Delete
  5. This is still true of the Lync 2013 mobile clients - they will only try to connect to the internal EWS URL.

    ReplyDelete
  6. The same with skype for business 2016 mobile clients with IOS - they will only try to connect to the internal EWS URL....

    ReplyDelete