可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

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

ExchangeService Service = new ExchangeService(ExchangeVersion.Exchange2010);
Service.Credentials = new WebCredentials("username@domainname.com", "Password");
Service.AutodiscoverUrl("username@domainname.com");
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?

回答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:

The version you specify in new ExchangeService() matches server's
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("john.smith@mydomain.it");
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

回答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!

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

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

回答5:

try to use this:

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

NOT this one

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

notice the username is 'john' NOT 'john@mail.com',It blocked me for quite a few hours for using the second one....

回答6:

Check if the password for this email has expired.

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

回答7:

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

回答8:

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 Manged API to get things done and replicate calls.

回答9:

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.

回答10:

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