"Не удалось найти службу автообнаружения" при попытке доступа к учетной записи Exchange 2010 с API-интерфейсом EWS MANAGED
Я использую Auto find service Url для указанного адреса электронной почты.
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());
Если мне это нравится, я получаю ошибку:
Не удалось найти службу автообнаружения
Что мне нужно сделать, чтобы избежать этой ошибки?
Ответы
Ответ 1
У вас неправильный код Service.Credentials
, используйте его следующим образом:
Service.Credentials = new WebCredentials(username, password, domainname);
Использование учетных данных домена, а не адрес электронной почты.
Также дважды отметьте следующее:
- Версия, указанная в
new ExchangeService()
, соответствует серверу
- параметр, переданный в
Service.AutodiscoverUrl();
, является правильным (адрес электронной почты, данные которого должны быть извлечены)
Следующие работы для меня (в новом консольном приложении):
// 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
Ответ 2
Позвольте мне отметить, что если вы пытаетесь получить доступ к Office 365, то веб-учетные данные действительно имеют форму WebCredentials (strUsername, strPassword); с именем strUsername, являющимся адресом электронной почты учетной записи, к которой вы пытаетесь получить доступ.
Я получал эту ошибку, и оказалось, что кто-то изменил пароль на учетной записи, не сообщив мне! Какая нечетная ошибка, когда это будет плохим паролем!
Ответ 3
Я рекомендую вам включить Traces, для достижения этого следуйте:
Service.TraceEnabled = true;
Я столкнулся с той же самой проблемой, тогда, когда я включил трассировки, эти трассировки будут направлять вас, что именно происходит. В моем случае проблема с сертификатом SSL существует, я следовал за следующим постом
Там может быть много вопросов, таких как:
- Пользователь может быть заблокирован.
- DNS не может найти
autodiscover.domain.com
.
Ответ 4
Для записи полноты:
Мы столкнулись с внезапной остановкой службы с этой конкретной ошибкой.
Поскольку служба работала без присмотра в течение нескольких месяцев, используя EWS для мониторинга почтового ящика, выяснилось, что пароль истек. Это вызвало отказ AutoDiscovery с тем же самым исключением:
Не удалось найти службу автообнаружения
Обновление пароля пользователя Exchange в AD и проверка его свойства Password Never Expires
решили проблему для нас.
Ответ 5
попробуйте использовать это:
Service.Credentials = new WebCredentials("john", "12345678", "MYDOMAIN");
НЕ этот
Service.Credentials = new WebCredentials("[email protected]", "12345678", "MYDOMAIN");
Обратите внимание, что имя пользователя 'john'
NOT '[email protected]'
, оно заблокировало меня в течение нескольких часов для использования второго...
Ответ 6
Проверьте, не истек ли пароль для этого письма.
Если срок действия пароля истек, вы получаете эту ошибку от автообнаружения.
Ответ 7
Я бы рекомендовал вам убедиться, что автообнаружение действительно настроено в DNS. Следующая статья объясняет, как ее настроить более подробно, а также дает информацию о том, как ее проверить с помощью Microsoft Remote Connectivity Analyzer. http://www.petri.co.il/autodiscover-configuration-exchange-2010.htm
Ответ 8
Я использовал прямой Url = new Uri("https://outlook.office365.com/EWS/Exchange.asmx")
и он работал для меня. Вы можете попробовать использовать Fiddler и eM Client, чтобы увидеть, как они используют EWS Manged API
для выполнения EWS Manged API
и репликации вызовов.
Ответ 9
У меня возникла та же проблема с Exchange 2013. В моем случае причиной было объявление прокси-сервера по умолчанию в моем файле конфигурации, что, вероятно, помешало службе автообнаружения работать правильно.
<system.net>
<defaultProxy enabled="true">
<proxy proxyaddress="http://localhost:8888" bypassonlocal="False"/>
</defaultProxy>
</system.net>
После комментирования тега <defaultProxy>
автообнаружение удалось найти служебный адрес Url.
Ответ 10
Я ударил это, и трассировка показывает, что после использования прокси для доступа к 365 он запускает поиск DNS для записи SVC.
Этот поиск относится к внутреннему DNS, а не к прокси, наш внутренний DNS не разрешает внешние записи DNS, поэтому у нас есть прокси-серверы.
Пока не выяснено, почему он выполняет поиск DNS, а не использует прокси-серверы, но именно это вызывает нашу версию этой проблемы.
Ответ 11
Столкнулся с этой проблемой для конкретного пользователя. После проверки я обнаружил, что пользователь включил двухфакторную аутентификацию и использует свой основной пароль для подключения. Решается путем генерации конкретного пароля приложения и соединения с ним. Отключение двух факторов также сработало, но для размышления потребуется некоторое время. Не уверен, почему обмен дал "Служба автообнаружения не может быть найдена". вместо "Несанкционированный".