Что то пошло не так owa

OWA или ECP перестают работать после установки обновления безопасности

Симптомы

После установки обновления безопасности на сервере, который работает Microsoft Exchange Server, либо Outlook в Интернете (OWA) или Exchange Панели управления (ECP), либо оба приложения перестанут работать на сервере.

OWA отображает следующее сообщение об ошибке:

Что-то пошло не так Ваш запрос не удалось завершить. КОД состояния HTTP: 500

ECP отображает следующее сообщение об ошибке:

Причина

Эти ошибки возникают, если обновление безопасности было установлено вручную на сервере с включенной поддержкой управления учетной записью пользователей, но без использования повышенных разрешений.

Решение

Используйте повышенные разрешения, чтобы переустановить обновление безопасности на сервере.

Проверьте, можно ли теперь получить доступ к OWA и ECP на сервере без получения сообщения об ошибке.

Если сообщение об ошибке ECP продолжает отображаться, сделайте следующее:

Запустите IIS Manager на сервере.

Перейдите Exchange веб-сайт > ECP Virtual directory.

Выберите параметры > приложения BinsearchFolder.

Проверьте пути к указанным Exchange каталогам. Вы можете увидеть пути каталога, похожие на следующие:

%ExchangeInstallDir%bin;
%ExchangeInstallDir%bin\CmdletExtensionAgents;
%ExchangeInstallDir%ClientAccess\Owa\bin

Замените пути следующими путями:

C:\Program Files\Microsoft\Exchange Server\V15\bin;
C:\Program Files\Microsoft\Exchange Server\V15\bin\CmdletExtensionAgents;
C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\bin

Примечание Пути должны указать, где Exchange Server установлен. В следующих примерах предполагается, что программа установлена на диске C и что версия Microsoft Exchange Server 2013. Если он установлен на другом диске на сервере или используется другая версия, например Microsoft Exchange Server 2010 г., используйте подходящие для установки сведения о пути и версии.

Перейдите к папке, которая включает Exchange Server скрипты. По умолчанию скрипты находятся в следующем пути для Exchange Server 2013 г.:

Примечание В Exchange Server 2010 г. скрипты будут в V14 папке.

Выход Exchange командной оболочки и откройте окно Командная подсказка в качестве администратора.

Перезапустите сервер и убедитесь, что сообщение об ошибке больше не будет получаться при доступе к ECP.

Источник

«Что-то пошло не так» сообщение об ошибке в Outlook Web App и ECP в Exchange Server 2013

Симптомы

При попытке войти в Outlook Web App или панели управления Exchange (ECP), появляется следующее сообщение об ошибке:

К сожалению что-то пошло не так
На сервере произошла ошибка.
ТЕХНИЧЕСКИЕ ПОДРОБНОСТИ

Если щелкнуть ссылку технические ПОДРОБНОСТИ, отображается следующий текст:

Произошла непредвиденная ошибка и не удалось обработать ваш запрос.
X-OWA-ошибка: System.NullReferenceException
X-OWA-версия: версия OWA
X-FEServer: Сервер клиентского доступа Exchange 2013
X-BEServer: Сервер почтовых ящиков Exchange 2013
Дата: Дата и время
Примечание. Эта проблема возникает, несмотря на то, что по-прежнему можно использовать Microsoft Outlook для отправки и получения сообщений электронной почты.

Причина

Значение идентификатора GUID хранится в коллекции cookie обозревателя и включается в запрос Outlook Web App или ECP. Если значение идентификатора GUID, который хранится в доменных службах Active Directory (AD DS) не соответствует, сервер блокирует запрос.

Решение

Примечание. Это обновление позволяет периодического перезапуска Outlook Web App или ECP пулов приложений (каждые 14 дней). Если отключить корзины или значение периода более 28 дней, проблема может возникнуть повторно.

Статус

Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».

Дополнительные сведения

При возникновении этой проблемы в журнал приложений в средстве просмотра событий могут отображаться следующие события:

Источник

Что то пошло не так owa

Вопрос

Речь идёт о Windows Server 2012 r2 и Exchange Server 2013 CU 23

Сегодня OWA начала вести себя следующий образом: с любого компьютера после открытия внутреннего или внешнего почтовых адресов браузер пишет

Страница недоступна
Сайт contoso.local выполнил переадресацию слишком много раз.
Удалите файлы cookie.
ERR_TOO_MANY_REDIRECTS

Если открыть в режиме инкогнито, видна форма ввода логина и пароля. Если ввести неправильные данные, выдаётся ошибка соответствующая ошибка о неверности введённых данных. Если ввести правильные данные, происходит переадресация на адрес contoso.local/owa/auth/errorFE.aspx?httpCode=500 Со следующим текстом:

что-то пошло не так
К сожалению, мы не можем получить эту информацию прямо сейчас. Пожалуйста, повторите попытку позже. Если проблема повторится, обратитесь в службу поддержки.
В подробностях только

Аналогичная история с внешним адресом, mail.contoso/owa.

При этом в журнале событий в разделе «Приложение» на почтовом сервере видно событие от «MSExchange Front End HTTP Proxy» с кодом 1003:

[Owa] An internal server error occurred. The unhandled exception was: Microsoft.Exchange.Diagnostics.ExAssertException: ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length c__DisplayClass3f. b__3e()
в Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(TryDelegate tryDelegate, FilterDelegate filterDelegate, CatchDelegate catchDelegate)

При этом, если попробовать открыть этот же адрес с самого сервера, где установлен Exchange, после ввода логина и пароля уже не отображается стандартная страница эксча с 🙁 и «что-то пошло не так», а видна ошибка IIS

Ошибка сервера в приложении ‘/owa’.
ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length c__DisplayClass3f. b__3e() +311
Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(TryDelegate tryDelegate, FilterDelegate filterDelegate, CatchDelegate catchDelegate) +35
Microsoft.Exchange.HttpProxy.Diagnostics.SendWatsonReportOnUnhandledException(MethodDelegate methodDelegate, LastChanceExceptionHandler exceptionHandler) +120
Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CallThreadEntranceMethod(MethodDelegate method) +69

[AggregateException: Произошла одна или несколько ошибок.]
Microsoft.Exchange.HttpProxy.ProxyRequestHandler.EndProcessRequest(IAsyncResult result) +416
System.Web.CallHandlerExecutionStep.InvokeEndHandler(IAsyncResult ar) +231
System.Web.CallHandlerExecutionStep.OnAsyncHandlerCompletion(IAsyncResult ar) +172

В этом случае в журнал событий записывается следующее событие от ASP.NET 4.0.30319.0 с кодом 1309

Event code: 3005
Event message: Возникло необработанное исключение.
Event time: 14.07.2021 16:12:24
Event time (UTC): 14.07.2021 13:12:24
Event ID: f617e5d236a742a9b72961b3146369f2
Event sequence: 373
Event occurrence: 293
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1/ROOT/owa-2-132707410127023554
Trust level: Full
Application Virtual Path: /owa
Application Path: D:\EXCH\FrontEnd\HttpProxy\owa\
Machine name: contoso

Process information:
Process ID: 13152
Process name: w3wp.exe
Account name: NT AUTHORITY\СИСТЕМА

Exception information:
Exception type: ExAssertException
Exception message: ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length c__DisplayClass3f. b__3e()
в Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(TryDelegate tryDelegate, FilterDelegate filterDelegate, CatchDelegate catchDelegate)
в Microsoft.Exchange.HttpProxy.Diagnostics.SendWatsonReportOnUnhandledException(MethodDelegate methodDelegate, LastChanceExceptionHandler exceptionHandler)
в Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CallThreadEntranceMethod(MethodDelegate method)

Request information:
Request URL: localhost:443/owa/auth.owa
Request path: /owa/auth.owa
User host address: 127.0.0.1
User: domain\HealthMailbox81fb5aa
Is authenticated: True
Authentication Type: Basic
Thread account name: NT AUTHORITY\СИСТЕМА

Thread information:
Thread ID: 32
Thread account name: NT AUTHORITY\СИСТЕМА
Is impersonating: False
Stack trace: в Microsoft.Exchange.Diagnostics.ExAssert.AssertInternal(String formatString, Object[] parameters)
в Microsoft.Exchange.Clients.Common.HmacProvider.GetCertificates()
в Microsoft.Exchange.Clients.Common.HmacProvider.GetHmacProvider()
в Microsoft.Exchange.Clients.Common.HmacProvider.ComputeHmac(Byte[][] messageArrays)
в Microsoft.Exchange.HttpProxy.FbaModule.SetCadataCookies(HttpApplication httpApplication)
в Microsoft.Exchange.HttpProxy.FbaFormPostProxyRequestHandler.HandleFbaFormPost(BackEndServer backEndServer)
в Microsoft.Exchange.HttpProxy.FbaFormPostProxyRequestHandler.ShouldContinueProxy()
в Microsoft.Exchange.HttpProxy.ProxyRequestHandler.BeginProxyRequestOrRecalculate()
в Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalOnCalculateTargetBackEndCompleted(TargetCalculationCallbackBeacon beacon)
в Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass3f. b__3e()
в Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(TryDelegate tryDelegate, FilterDelegate filterDelegate, CatchDelegate catchDelegate)
в Microsoft.Exchange.HttpProxy.Diagnostics.SendWatsonReportOnUnhandledException(MethodDelegate methodDelegate, LastChanceExceptionHandler exceptionHandler)
в Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CallThreadEntranceMethod(MethodDelegate method)

Custom event details:

Удалял msExchCanaryData0 и перезапускал пуллы приложений.

Источник

Перенаправление OWA не работает после установки обновлений для системы безопасности за ноябрь 2021 г. Exchange Server 2019, 2016 или 2013 г.

Проблемы

После установки обновлений для системы безопасности за ноябрь 2021 г. (KB5007409) для Microsoft Exchange Server 2019, 2016 или 2013 г., перенаправление Outlook в Интернете (OWA) в гибридной среде не работает.

При локальном развертывании перенаправление OWA между сайтами также может перестать работать в средах, в которой не используется протокол FBA.

Ожидаемое поведение

Для гибридных сред

Когда пользователь с почтовым Exchange Online входит в локальное веб-Exchange Online OWA, он получает URL-адрес перенаправления, который указывает на https://outlook.office.com.

Для локальной среды

В развертывании Exchange, которое охватывает несколько сайтов Active Directory (AD), на которых используются разные URL-адреса для доступа к OWA (например, сайт 1 = https://site1.contoso.com/owa, а сайт 2 = https://site2.contoso.com/owa), пользователь, у которого есть почтовый ящик на сайте site1 и который входит в OWA с помощью URL-адреса site2, автоматически перенаправляется на URL-адрес «site1».

Фактическое поведение

В обоих ожидаемых случаях пользователь не может войти в систему и получает следующее сообщение об ошибке в Exchange Server 2019 или 2016:

Что-то пошло не так.

В Exchange Server 2013 пользователь получает следующее сообщение об ошибке:

Внешний компонент стал исключением.

Обходное решение

В случае сбоя перенаправления локального перекрестного сайта

Обходной путь 1

Настройте виртуальный каталог OWA и ECP на всех затронутых переднем серверах для использования FBA.

Обходной путь 2

Попросите пользователей с каждого сайта использовать соответствующий URL-адрес OWA для входа.

Пользователи, у которых есть почтовый ящик на сайте 2, должны использовать https://site2.contoso.com/owa.

Для гибридного сценария

Обходной путь 1

Пользователи могут использовать прямой URL-адрес Exchange Online OWA в браузере на сайте https://outlook.office.com/owa.

Обходной путь 2

Примечание. Это решение применимо только к Exchange Server 2019 и Exchange Server 2016.

Exchange Server администраторы могут изменить URL-адрес перенаправления с помощью правила перенаправления, чтобы ошибка не появлялись у пользователей. Действия для этого обходного решения необходимо настроить на всех серверах, которые обрабатывают трафик OWA.

Действия по переописи URL-адреса

Примечание На этом шаге замените Имя Сервера> именем сервера.

В области Функции (в центре) вы увидите функцию «Переписать URL-адрес» в области IIS. Если вы не видите ее, возможно, эта функция не установлена. В этом случае вы можете скачать пакет установки с сайта URL-адреса Rewrite: Официальный сайт Microsoft IIS. Для установки не требуется перезапуск. Однако пулы приложений IIS будут перезапущены.

Примечание Убедитесь, что вы установили версию X64.

Если модуль переописи URL-адреса уже установлен на серверах и серверы настроены аналогично с помощью пути, после внести изменения вы можете скопировать файл Web.config из папки Wwwroot на первом сервере на другие серверы. Обратите внимание, что для того чтобы изменения вступили в силу на первом сервере, может потребоваться некоторое время.

Дважды щелкните ссылку «Переписать URL-адрес».

В области Действия выберите Добавить правила.

Оставьте запросимый URL-адрес в качестве совпадения с шаблоном.

Измените значение в окте Using (Поддеревные знаки).

Оставьте выбранным игнорировать дело.

Выберите список Условия, чтобы развернуть его, а затем выберите Добавить.

В диалоговом окне Изменение условия в поле Ввода условия введите .

Оставьте строку ввода Проверить, соответствует ли вводимая строка шаблону.

В диалоговом окне Действие выберите переписать в списке Тип действия.

В поле Свойства действия в текстовом поле Переписать URL-адрес введите следующий код:

С помощью этой строки можно будет отобирать строку запроса на передачу.

Выберите поле Перезаписанный URL-адрес.

В области Действия выберите применить.

Выберите Применить, а затем вернуться к правилам.

В окне Переписать URL-адрес выберите созданное правило, а затем проверьте, включено ли правило, в области Действия в области Правила для входящие.

Это новое правило не должно требовать сброса IIS и вступает в силу сразу же после того, как вы в него вступаете. Теперь вы можете проверить это с помощью OWA (с помощью учетной записи, которая воспроизведла проблему), чтобы убедиться, что вы получаете ожидаемое перенаправление URL-адреса.

Включение ведения журнала для проверки действия правила

Для проверки ожидаемого перенаправления можно использовать трассировку сбойного запроса. Для этого выполните следующие действия:

Откройте диспетчер IIS. В области Подключения выберите веб-сайт по умолчанию.

В области Действия в области Настройкавыберите Не удалось трассировка запросов.

В диалоговом окне Изменение параметра трасситуры запроса веб-сайта выберите Включить.

Оставьте значения для файлов трассировки (Directory) и Maximum Number (Максимальное количество файлов трассировки) без изменений.

В области Действия выберите Добавить.

С очистки ярлыковв окне расширения ASP, ASPNETи ISAPI.

Выберите WWW Server. В области, отоберем все параметры, кроме последнего (который нужно переписать).

Попробуйте еще раз войти в Exchange Online почтового ящика в локальном OWA.

В Windows проводнике на затронутом сервере перейдите к C:\inetpub\logs\FailedReqLogFiles.

Выберите последнюю строку, которая должна быть Просмотр всех событий запроса.

Наймем URL_REWRITE_START и URL_REWRITE_END. Проверьте содержимое между этими событиями. Вы увидите следующие записи:

ULE_EVALUATION_START
PATTERN_MATCH
CONDITION_EVALUATION
REWRITE_ACTION RULE EVALUATION_END

Проверьте значение REWRITE_ACTION. Теперь все шаблоны \0026 должны быть изменены на амперанд (&).

Развертывание на нескольких серверах

После выполнения этих процедур на одном сервере его можно легко развернуть на нескольких серверах, если ранее упомянутый модуль переописи URL-адреса уже установлен на всех серверах Exchange клиентского доступа.

Источник

Невозможно подключиться к почтовому Exchange Server 2010 из Outlook Web App

Исходный номер КБ: 980049

Симптомы

Вы не можете использовать POP3 или IMAP4 для подключения к почтовому ящику 2010 Exchange Server 2010 Microsoft Office OWA. При попытке подключения вы получаете следующее сообщение об ошибке:

Проблема возникла при попытке использования почтового ящика.

Если вы выбираете сведения Показать, вы увидите, что следующее исключение вызывает ошибку:

Microsoft. Exchange. Данные. служба хранилища. TooManyObjectsOpenedException

Если вы пытаетесь использовать подключение Telnet для подключения к почтовому ящику с помощью POP или IMAP, вы получите сообщение об ошибке:

Сервер, работающий Exchange Server 2010 г., регистрит ошибку в журнале приложения, которая напоминает следующее:

Имя журнала: приложение
Источник: MSExchangeIS
Дата: dd/mm/yyyyhh:mm:ss
Идентификатор события: 9646
Категория задач: общие
Уровень: ошибка
Ключевые слова: Классический
Пользователь: N/A
Компьютер: Servername.contoso.com
Описание:
Сеанс Mapi «/o=Первая организация /ou=Exchange Административная группа (FYDIBOHF23SPDLT)/cn=Recipients/cn=E-mailUser» превысил максимум 16 объектов типа «session».

Следующие изменения не устраняют эту проблему:

Причина

Эта проблема возникает из-за того, что Exchange 2010 Store ограничивает количество сеансов, не внося в mapi, которые создают другие службы, такие как IMAP, POP, OWA, Microsoft Exchange ActiveSync (EAS) или Exchange Веб-службы (EWS). По умолчанию количество сеансов на одного пользователя ограничено 32 сеансами, а сеансов служб на одного пользователя — 16.

Решение

В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о том, как создать и восстановить реестр, см. в этой информации, как создать и восстановить реестр в Windows.

Чтобы устранить эту проблему, сначала определите, вызвана ли эта ситуация другой проблемой. Если нет, то убавьте ограничение, которое требуется вашей организации для сеансов, не внося в MAPI. Для этого выполните следующие действия:

На сервере, на Exchange Server 2010 роль почтового ящика, выберите Начните, выберите Выполнить, введите regedit, а затем выберите ОК.

Найдите и выберите следующий ключ в реестре:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

В меню Редактирование указать значение New, а затем выберите значение DWORD.

Введите максимально допустимые сеансы службы для каждого пользователя и нажмите кнопку ENTER.

В меню Изменить выберите Изменение.

Введите десятичной значение, которое указывает количество сеансов, которые вы хотите использовать, а затем выберите ОК.

Закройте редактор реестра.

Значение реестра Максимально допустимые сеансы обслуживания на каждого пользователя влияет на все базы данных почтовых ящиков на сервере и не применяется на основе каждого пользователя. При увеличении этого значения производительность сервера может отрицательно сказаться на производительности. Например, удвоение количества сеансов службы с 16 до 32 может замедлить производительность сервера.

Ссылки

Дополнительные сведения о том, как установить ограничения для сеансов, см.:

Источник