'Autodiscover service couldn't be located' when trying to access Exchange 2010 account with EWS MANAGED API

Question

I am using Auto discover service Url for a specified e-mail address.

ExchangeService Service = new ExchangeService(ExchangeVersion.Exchange2010);
Service.Credentials = new WebCredentials("[email protected]", "Password");
Service.AutodiscoverUrl("[email protected]");
Folder inbox = Folder.Bind(Service, WellKnownFolderName.Inbox);
Console.WriteLine("The folder name is" + inbox.DisplayName.ToString());

If I do like this I'm gettin an error:

The Autodiscover service couldn't be located

What I have to do to avoid this error?

Guadalupeguadeloupe

Answer 1

You got Service.Credentials wrong, use it like this:

Service.Credentials = new WebCredentials(username, password, domainname);

Using domain credentials, not the email address.

Also doublecheck the following:

1. The version you specify in new ExchangeService() matches server's
2. the parameter passed to Service.AutodiscoverUrl(); is correct (email address which data needs to be fetched)

The following works for me (in a new Console Application):

// Tweaked to match server version
ExchangeService Service = new ExchangeService(ExchangeVersion.Exchange2007_SP1); 

// Dummy but realistic credentials provided below
Service.Credentials = new WebCredentials("john", "12345678", "MYDOMAIN");
Service.AutodiscoverUrl("[email protected]");
Folder inbox = Folder.Bind(Service, WellKnownFolderName.Inbox);
Console.WriteLine("The folder name is " + inbox.DisplayName.ToString());

//Console output follows (IT localized environment, 'Posta in arrivo' = 'Inbox')
> The folder name is Posta in arrivo

Impotence

Thanks for u reply Alex.I tried as u told above.But to same error comes. – Guadalupeguadeloupe

I don't know what to say, I copy-pasted your code in a new console app and it works after matching server's version (ours is 2007SP1) and changing the credentials, as I point out above. Server's version difference might be relevant but I have no way of verifying it. – Impotence

i tried by changing the version to Exchange2007_SP1,Exchange2010,Exchange2010_SP1,Exchange2010_SP2...Thento same error comes. – Guadalupeguadeloupe

updated answer with all info i have. I'd suggest getting in touch with IT and make them ensure EWS is enabled in the first place, and/or check server logs (do your requests reach the server ?) – Impotence

if i use like this i am getting all the info about the mailbox i mentioned ` ExchangeService Service = new ExchangeService(ExchangeVersion.Exchange2010); Service.Credentials = new WebCredentials("adminuser1","1234567", "mydomain"); Service.Url = new Uri("HTTPS://ServerName/EWS/Exchange.asmx");` here i have Hardcoded the servername.If i use Autodiscoverurl i can give all input dynamically at run time.so i used autodiscoverurl instead of that Service.Url,` Service.AutodiscoverUrl("[email protected]", delegate { return true; });'....Same error comes – Guadalupeguadeloupe

I wonder if https might break something. I'm afraid I have no means of testing it. – Impotence

I cant get what were u saying – Guadalupeguadeloupe

why 'new WebCredentials("[email protected]", "Password");' is wrong ? It is 3rd overloading option. – Pizor

Answer 2

Let me point out that if you are trying to access Office 365 then the web credentials really are of the form WebCredentials(strUsername, strPassword); with strUsername being the email address of the account you are trying to access.

I was getting this error and it turned out someone had changed the password on the account without informing me! What an odd error to get when it's just a bad password!

Pontormo

thanks @Pontormo tested it works. Just in case other people read MSDN document - Microsoft gave the option where strUsername is not an email but only Username and that confused me because it DOES NOT work here is the link msdn.microsoft.com/en-us/library/dn467891(v=exchg.150).aspx – Sylph

Thanks for pointing out that this error can also occur on incorrect credentials. Saved me a good bit of time! – Grimmett

Answer 3

I will recommend to you to enable Traces,to achieve this follow :

     Service.TraceEnabled = true;

I was facing the same issue then when I enabled traces these traces will guide you what exactly is happening.In my case SSL certificate issue is there to solve it i followed following post

There can be many issue such as:

• User can be blocked.
• The DNS can't find autodiscover.domain.com.

Basting

Thanks. This helped me pinpoint the issue in my case. DNS was unable to resolve autodiscover.domain.com on the server, whereas this worked on my local machine. Added an entry in the hosts file to point autodiscover.domain.com to the proper IP address and everything worked as expected. – Aguilar

To configure where output of trace goes, follow instructions here msdn.microsoft.com/en-us/library/office/… – Nikolaus

Answer 4

For the record of completeness:

We encountered a service suddenly stopping with this particular error. As the service had been running unattended for months, using EWS to monitor a mailbox, it turned out that the password was expired. This caused the AutoDiscovery to fail with the very same exception:

The Autodiscover service couldn't be located

Updating the Exchange user's password in the AD and checking its Password Never Expires property solved the problem for us.

Maniple

Well written and complete. Mine had expired too. – Reitareiter

Answer 5

I have used direct:

Url = new Uri("https://outlook.office365.com/EWS/Exchange.asmx")

and it worked for me. You may try use Fiddler and eM Client to see how they use EWS Managed API to get things done and replicate calls.

Chantilly

Worked instantly. Good for hybrid environments. – Palinode

This is the solution for me as well – Jura

Answer 6

try to use this:

Service.Credentials = new WebCredentials("john", "12345678", "MYDOMAIN");

NOT this one

Service.Credentials = new WebCredentials("[email protected]", "12345678", "MYDOMAIN");

notice the username is 'john' NOT '[email protected]',It blocked me for quite a few hours for using the second one....

Kelsi

Answer 7

Check if the password for this email has expired.

If the password has expired you receive this error from AutoDiscover.

Ultimately

Actually @StephenMuecke this answer was helpful - it turned out to be my issue! – Meddlesome

Answer 8

I'd recommend that you verify that autodiscover is actually setup in DNS. The following article explains how to set it up in more detail and it also gives you information on how to test it with the Microsoft Remote Connectivity Analyzer.http://www.petri.co.il/autodiscover-configuration-exchange-2010.htm

Fraser

Answer 9

Faced this issue for specific user. After checking I found that user has enabled two factor authentication and using his primary password for connection. Solved by generating app specific password and connecting with it. Disabling two factor also worked, but it will take some time to reflect. Not sure why exchange gave "The Autodiscover service couldn't be located." instead of "Unauthorised".

Tramontane

To add to this, it seem that IT can set O365 accounts routed to company domain. And this may not work. A simple account with email/password will work. And this is exactly what we have. Real user accounts are routed to domain and I can't logon. For apps we have special accounts that are not routed to domain – Euchology

Answer 10

I experienced the same problem with Exchange 2013. In my case the cause was a Default Proxy declaration in my config file, which probably prevented the Autodiscover service to work correctly.

<system.net>
    <defaultProxy enabled="true">
      <proxy proxyaddress="http://localhost:8888" bypassonlocal="False"/>
    </defaultProxy>
</system.net>

After commenting the <defaultProxy> tag, autodiscover was able to find the service Url.

Marron

Answer 11

I have hit this and a trace shows that after using the proxy to access 365 it starts a DNS lookup for an SVC record. This lookup goes to internal DNS and not the proxy, our internal DNS does not resolve external DNS entries, that is why we have proxy servers. Not yet found out why it is doing a DNS lookup rather than using the proxy servers, but that is what is causing our version of this problem

Sunil

Answer 12

The 'Autodiscover service couldn't be located' error message could potentially be related to an authentication issue and not Autodiscover not working properly.

When I was getting started with the EWS Managed API, I was following Microsoft's documentation and realized that their examples are still using Basic Authentication. However, as you can see in this blog post, Basic Auth should be turned off by end of 2022. So, instead of following exactly Microsoft's code examples, you will have to modify the auth section to use OAuth 2.0. This article helped me get things to work.

Hypochondrium

Answer 13

Late to the party... But we had a similar problem. We received the same Autodiscover service couldn't be located message and in checking the System Event Log, there was an error message stating that:

The password stored in Credential Manager is invalid.....

The error message also had instructions on how to correct. Namely, to go to Control Panel > Credential Manager and re-enter the password for the account in question. That solved it for us.

Uncaredfor