none
EWS Autodiscover resolves a right address but Send method uses a different wrong one RRS feed

  • Question

  • Hi,

    I'm using EWS to do some test, but I'm really stuck just starting to work with this API.

    I installed my own Exchange 2007 SP1 server, which is also the Domain Controller and has my test Active Directory. Of course I use my own internal fake domain (called gdi.com), but I didn't set it to be accessed outside my LAN, so it can't be accessed from internet.

    So far, I managed to configure some Exchange accounts, use them properly with Outlook 2007, the corresponding OWA, and set up the autodiscover service, the OAB, the UM, the EWS and so on. If I use the 'Test E-mail Autoconfiguration' tool, I get all the paths properly configured and no errors.

    Then I try to develop my first app using EWS: just the EWS first example to send a 'Hello World' mail to one recipient. When it reaches the service.Autodiscover() sentence, it resolves fine the URL (https://myExchangeServer.gdi.com/EWS/Exchange.asmx), but some lines below, after the message item is composed, I try to execute the Send method and I get the following error:

    "Request failed. Unable to connect to the remote server ---> No connection could be made beacuse the target machine actively refused it 208.73.210.50:443"

    Of course 208.73.210.50 is not neither any of my IP addresses nor a known address for me, so I'm understanding that Autodiscover method is getting the right EWS URL, but the Send method is using another wrong URL and I don't know why.

    Could anybody help me?

    Could it be any problem with the DNS server which can be resolving my domain in a wrong way or looking for it on the internet?

    Any help will be appreciated.

    Tuesday, June 15, 2010 4:38 PM

Answers

  • I assume you are using the EWS Managed API.

    Each and every call to EWS the API makes will use whatever URL is set in the ExchangeService.Url property, and only that URL. If you used Autodiscover (by calling AutodiscoverUrl) to automatically determine the EWS URL, then the ExchangeService.Url property will be set to the URL returned by Autodiscover after the call to AutodiscoverUrl. You can verify that the API is using the appropriate URL by either:

    • Manually setting ExchangeService.Url to the appropriate EWS URL
    • Making sure that ExchangeService.Url is set to the appropriate URL after the call to AutodiscoverUrl

    If you are seeing this error message even though the ExchangeService.URL property is set to the appropriate EWS URL (https://myExchangeService.gdi.com/EWS/Exchange.asmx) then this FQDN must somehow resolve to 208.73.210.50, and you might want to check you DNS configuration.


    David Claux | Program Manager - Exchange Web Services
    • Proposed as answer by David Claux - MSFT Tuesday, June 15, 2010 11:15 PM
    • Marked as answer by sayago Monday, June 21, 2010 10:23 AM
    Tuesday, June 15, 2010 11:15 PM

All replies

  • I assume you are using the EWS Managed API.

    Each and every call to EWS the API makes will use whatever URL is set in the ExchangeService.Url property, and only that URL. If you used Autodiscover (by calling AutodiscoverUrl) to automatically determine the EWS URL, then the ExchangeService.Url property will be set to the URL returned by Autodiscover after the call to AutodiscoverUrl. You can verify that the API is using the appropriate URL by either:

    • Manually setting ExchangeService.Url to the appropriate EWS URL
    • Making sure that ExchangeService.Url is set to the appropriate URL after the call to AutodiscoverUrl

    If you are seeing this error message even though the ExchangeService.URL property is set to the appropriate EWS URL (https://myExchangeService.gdi.com/EWS/Exchange.asmx) then this FQDN must somehow resolve to 208.73.210.50, and you might want to check you DNS configuration.


    David Claux | Program Manager - Exchange Web Services
    • Proposed as answer by David Claux - MSFT Tuesday, June 15, 2010 11:15 PM
    • Marked as answer by sayago Monday, June 21, 2010 10:23 AM
    Tuesday, June 15, 2010 11:15 PM
  • Yes, it was a problem with my local DNS configuration. Once I put the server address in my hosts file, everything worked fine.

    Thank you David.

    Monday, June 21, 2010 10:23 AM