Блог

После того, как наша компания обновилась с Exchange 2010 до Exchange 2013, я обнаружил действительно странную особенность. Я использую управляемый EWS API для создания подписки на потоковую передачу в некоторые общедоступные папки. У меня все еще работают некоторые старые службы Windows, которые с радостью подписаны, читают новую почту и тому подобное. У меня есть мой новый проект, который в конечном итоге заменит эти старые службы Windows, и, пока мы были на Exchange 2010, он мог создавать те же подписки на потоковую передачу в те же общие папки, в то время как устаревшие службы Windows все еще работали. После обновления я теперь получаю исключение ServerBusyException при попытке открыть StreamingSubscriptionConnection. Если я отключу все устаревшие службы Windows, я смогу нормально открыть соединение в своем новом проекте.

Вот как я подписываюсь, ничего особенного:

     private StreamingSubscriptionConnection CreateStreamingSubscription(ExchangeService service, StreamingSubscription subscription)
    {
        var connection = new StreamingSubscriptionConnection(service, 30);
        connection.AddSubscription(subscription);
        connection.OnNotificationEvent  = connection_OnNotificationEvent;
        connection.OnSubscriptionError  = connection_OnSubscriptionError;
        connection.OnDisconnect  = connection_OnDisconnect;

        try
        {
            connection.Open(); // <-- boom!
        }
        catch (ServerBusyException ex)
        {
            Log.Error("Connection to Exchange refused. Server is too busy.", ex);
            throw; // <-- this is the exception, it is specific
        }
        catch (Exception ex)
        {
            Log.Error("Unknown error connection to Exchange.", ex);
            throw;
        }


        return connection;
    }
  

После просмотра этого MSDN есть свойство с именем BackOffMilliseconds, но оно возвращается как 0, указывая, что Exchange на самом деле не говорит мне повторить попытку позже. Я вошел в Exchange Server, чтобы проверить политики регулирования, и применяется глобальная политика по умолчанию. Каждый параметр, в котором есть слово «параллелизм», превышает 10, поэтому я не думаю, что это проблема политики регулирования. Как бы то ни было, мои устаревшие службы Windows и этот новый проект используют одну и ту же учетную запись службы для выполнения своих задач.

Я также посмотрел, как выполняется подключение к службе, и нет никаких изменений, установлено ли для него значение Exchange2013 или Exchange2010_SP1:

     private ExchangeService CreateExchangeService()
    {
        ServicePointManager.ServerCertificateValidationCallback = CertificateValidationCallBack;
        var service = new ExchangeService(ExchangeVersion.Exchange2013);
        service.Credentials = new WebCredentials(ExchangeUser, ExchangePassword, ExchangeDomain);
        service.AutodiscoverUrl(ExchangeEmail, RedirectionUrlValidationCallback);
        return service;
    }
  

В последний раз я проверял Fiddler, чтобы узнать, что происходило во время этих неудачных подписок, и я вижу бесполезный HTTP 500 с тем же сообщением о занятости сервера, попробуйте позже.

Есть идеи о том, что изменилось в EWS API в Exchange 2013 по сравнению с 2010SP2?

Похоже, вы достигли предела зависания соединения по умолчанию, который равен 3 для локального сервера Exchange 2013. Вы можете переопределить его в web.config, как указано здесь. В основном добавьте следующий узел в AppSettings xml node в web.config (он устанавливает его равным 10) и перезапустите MSExchangeServicesApppool:

добавить ключ =»HangingConnectionLimit» значение =»10″ (добавить теги xml)

web.config для пула приложений EWS можно найти по адресу: C:Program Файлы Microsoft Exchange Server V15 ClientAccess exchweb ews. Это может отличаться в зависимости от каталога установки Exchange.

Также обратите внимание, что это изменение необходимо внести на серверах почтовых ящиков, где существует активная база данных пользователей.

Хотя в EWS API нет изменений с точки зрения подписок — сам Exchange изменился, где поддерживаются подписки.

В Exchange 2010 подписки хранились в центрах сертификации, в 2013 они хранятся на сервере почтовых ящиков.

Основываясь на исключении, я думаю, что вы действительно получаете ограничение. В этом разделе содержится ряд рекомендаций по поддержанию связи с сервером почтовых ящиков в 2013 году и предотвращению регулирования: Как: поддерживать связь между группой подписок и сервером почтовых ящиков в Exchange. По сути, вы группируете подписки и используете заголовок X-AnchorMailbox для маршрутизации запросов.

И есть подробности о том, почему вы можете видеть исключение ERRORSERVERBUS в этом разделе: Обработка ошибок, связанных с уведомлением, в EWS в Exchange.

Мэтт Стил также написал об этом в блоге здесь: Изменения в управлении привязкой к подпискам EWS ….