'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?

Solution 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

Solution 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!

Solution 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.

Solution 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.

Solution 5

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....

View more solutions

Comments

[user1891567]

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

[Alex]

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.

[user1891567]

i tried by changing the version to Exchange2007_SP1,Exchange2010,Exchange2010_SP1,Exchange2010_‌​SP2...Thento same error comes.

[Alex]

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 ?)

[user1891567]

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

[Alex]

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

[user1891567]

I cant get what were u saying

[user2260040]

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.

[kaveman]

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

[wruckie]

Well written and complete. Mine had expired too.

[Muflix]

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

[Dung]

thanks @user3531993 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

[confusedandamused]

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

[mike nelson]

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

[Will]

Worked instantly. Good for hybrid environments.

[Roberto Borges]

This is the solution for me as well

[T.S.]

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