Exchange server ошибка

  • Remove From My Forums
  • Question

  • Добрый день! Развернул Exchange 2019, вроде бы без ошибок прошло, но не могу зайти в ECP — выдается ошибка 500. Причем авторизацию при этом проходит. Запускал последовательно .UpdateConfigFiles.ps1 и .UpdateCAS.ps1, после
    чего перезагрузил сервер — не помогло. Что еще нужно проверить? Спасибо за помощь.

Answers

  • Помогло после выполнения

    C:Windowssystem32lodctr.exe /R

    И затем

    iisreset /noforce

    Точнее, я сделал iisreset /stop и потом iisreset /start

    Это проблема всех свежих CU, я так понимаю?

    • Proposed as answer by

      Tuesday, September 27, 2022 12:44 PM

    • Marked as answer by
      Иван ПродановMicrosoft contingent staff, Moderator
      Friday, October 7, 2022 11:13 AM

Перейти к концу метаданных


  • Created by , last modified by Valentin Popov on апр 13, 2021

Переход к началу метаданных

Решение обычных проблем

Если вы ещё этого не сделали, проверьте, может ли быть установлено соединение с Exchange, нажмите на кнопку «Проверить соединение» во вкладке Настройка -> Соединения -> Exchange клиент.

Способы решения обычных ошибок, выдаваемых при создании тестового соединения с Exchange Connection Tests, вы можете увидеть ниже:

Ошибка#1: failed to connect to mailbox daisy@company.local:Unable to access mailbox daisy@company.local:Unauthorized
Решение: Проверьте, что авторизация Windows включена в IIS -> Веб-страница (по умолчанию) (англ. Default Web Site) -> EWS -> Метод авторизации (англ. Authentication Method) на сервере Exchange. Проверьте, что в поле Соединение Exchange введено полное доменное имя пользователя, а не просто почтовый адрес. Убедитесь, что соответствующий аккаунту пользователя пароль, введенный для Exchange Connection, верен. 

Ошибка#2: failed to connect to mailbox daisy@company.local:Unable to access mailbox daisy@company.local:Unexpected EOF in prolog at [row,col {unknown-source}]: [1,0]
Решение: Отключите ASP.Net имперсонализацию в IIS->Default Web Site->EWS->Authentication Method на сервере Exchange. 

Ошибка#3: test exchange connection using mailbox daisy@company.local.. failed to connect to mailbox daisy@company.local:Unable to access mailbox daisy@company.local:Forbidden
Решение: Поменяйте настройки SSL, так чтобы они совпадали с настройками SSL (IIS->Default Web Site->EWS-> SSL Settings) того типа соединения, которое указано в соединении Exchange. Также, установите в EWS SSL настройках игнорировать клиентские сертификаты (англ. Ignore Client Certificates).

Ошибка#4: could not retrieve list of users from server 192.168.0.250:failed to locate users in the directory:Failed to locate authority for name: company.local.company.local

Решение: Или DNS настроен неверно на сервере Архива или нет связи между сервером Exchange и сервером Архива.

Ошибка#5: failed to connect to mailbox extest_1ea06f331e634@company.local:Unable to access mailboxextest_1ea06f331e634@company.local:The account does not have permission to impersonate the requested user.
Решение: Права имперсонализации не предоставлены пользователю, указанному в соединении Exchange. Как предоставить права на имперсонализацию, читайте в разделе Exchange. 

Ошибка #6: При обращении к почтовому ящику должен быть указан основной SMTP адрес
Решение: Обновитесь до самой последней версии. Эта проблема была исправлена путем введения имени и поля атрибута основного почтового ящика во вкладке Настройка -> Авторизация. 

Icon

Замечание: Обычно для того, чтобы команды имперсонализации возымели эффект, требуется 5-10 минут. Поэтому, после выделения прав исперсонации в Exchange, лучше всего подождать несколько минут перед новой проверкой соединения Exchange.

Ошибка#7: Внутренняя ошибка сервера (англ. Internal server error)

Решение: Ошибка, возвращенная Microsoft Exchange. Попробуйте переименовать C:Inetpubwwwrootweb.config в  C:Inetpubwwwrootweb.config.bak на сервере Windows и запустить команду iisreset из командной строки. Также проверьте, что url-адрес https://[exchange_ip_address]/ews/Exchange.asmx доступен из веб-браузера на компьютере, где запущена Архива.

Подробные инструкции

  1.  Проверьте, что авторизация Windows включена на сайте EWS в IIS
    a) Откройте Microsoft IIS на сервере Exchange
    б) Разверните Sites->EWS в просмотре в виде дерева слева. 
    в) Двойной клик по Авторизации. 
    г) Проверьте, что ASP.NET Имперсонализации отключена, а авторизация Windows включена

  2. Проверьте, что в настройках  EWS SSL указано не требовать сертификат. 
    a) Откройте Microsoft IIS на сервере Exchange. 
    б) Раскройте Sites->EWS в просмотре в виде дерева слева. 
    в) Дважды кликните по Настройкам SSL. 
    г) Проверьте вкладку «Require SSL» (рус. Требования SSL) и установите игнорировать клиентские сертификаты. 
  3. Настройте коннектор Exchange на сервер Архива.
    a) Проверьте, что выбрана правильная версия Microsoft Exchange
    б) Учетная запись имперсонализации должна иметь форму journal@archiva.ru (введите основное имя пользователя учетной записи, не почтовый адрес)
    в) Тип соединения должен соответствовать типу, выбранному раньше в настройках  EWS Site SSL.

  4. Нажмите на кнопку «Протестировать соединение». Если все прошло успешно, то вам будет вывод будет следующим: 

Решение остальных проблем

  1. Запустите Test-WebServicesConnectivity Cmdlet из оболочки Exchange

    Icon

    Команде Test-WebServicesConnectivity может потребоваться запустить сперва скрипт подготовки: C:Program FilesMicrosoftExchange ServerV15Scriptsnew-TestCasConnectivityUser.ps1.

    Вывод команды будет таким:

  2. Если EWS:GetFolder возвращает ошибку, попробуйте переименовать C:Inetpubwwwrootweb.config в C:Inetpubwwwrootweb.config.bak, а после из командной строки сервера Windows напечатать iisreset. 

  3. Проверьте, что интерфейс веб-сервисов сервера Exchange доступен компьютеру, на котором запущена Архива. 
    a) На сервер Архива откройте веб-браузер
    б) Введите url-адрес https://[exchange_ip_address]/ews/Exchange.asmx.
    в) Авторизуйтесь под тем пользователем и с тем паролем,указанными в соединении Exchange.
    г) Вы должны получить положительный ответ (т.е. не 500 или 404 ошибки). В Exchange 2013, вам будет выведено «Вы создали сервис…» (англ. «You have created a service…»). В Exchange 2010 будет показано значение WSDL для интерфейса веб-сервисов Exchange.

Внутренняя ошибка сервера

Это общая ошибка, возвращаемая Microsoft Exchange. Часто она вызвана ошибкой соединения между Microsoft Exchange и IIS. Обычные причины также включают неправильные/отсутсвующие права в MS Exchange, проблемные обновления Exchange с более ранних версий и поврежденные объекты Exchange. Чтобы решить эти проблемы, пожалуйста, следуйте инструкциям, приведенным выше, в пункте «Решение остальных проблем». Если у вас что-то не получается исправить, полезно просмотреть логи событий обоих IIS и Exchange сервера. Более подробно здесь: http://msexchangeguru.com/2013/09/24/e2013remote-server500internalservererror/. IIS логи обычно находятся в C:WindowsSystem32LogFilesW3SVC1. Более подробную информацию о детальных логах ошибки HTTP 500 можно получить здесь: http://learn.iis.net/page.aspx/772/troubleshoot-with-failed-request-tracing/. 

Сервис недоступен

Если вы получаете ошибку «Сервис недоступен» (англ. «service unavailable»), возможно, у вас установлены ограничения на IIS соединения, которые не позволяют Архива завершить импортt. Чтобы убрать эти ограничения, сделайте следующее: 

  • Ни одной

Summary:
HTTP ERROR 500 in Exchange is displayed when the server rejects the request to establish a connection with the Exchange Server. The error prevents Exchange administrators and users from accessing the Exchange Admin Center and managing the Exchange Server. In this blog, we have discussed reasons and solutions to fix the HTTP ERROR 500 in Exchange and get access to the EAC/ECP.

Free Download for Windows

Contents

  • Reason for HTTP ERROR 500 in Exchange ECP/EAC
  • Solutions to Fix HTTP ERROR 500 in Exchange Server
  • Conclusion

Exchange Management Console (EMC) and Exchange Control Panel (ECP) were two different interfaces used in Exchange 2010 and earlier versions to manage the Exchange Servers. With Exchange 2013, Exchange Administrative Center (EAC) — a web-based management console optimized for on-premises, hybrid, and online Exchange Server deployments—replaced EMC and ECP.

And since EAC is web-based, you need to use a web browser and require the OWA/ECP virtual directory URL to access the management console. By default, you can access the ECP/EAC console using the following URLs,

Internal URLhttps://<CASServerName>/ecp

It allows users to access the EAC within the organization’s firewall.

External URLhttps://mail.abc.com/ecp

It provides access to users from outside of your organization’s firewall.

Administrators and users with permission can access the EAC/ECP panel by signing in using valid credentials.

However, many users have reported an HTTP ERROR 500 after they sign in to EAC/ECP.

Stellar

Reason for HTTP ERROR 500 in Exchange ECP/EAC

The HTTP ERROR 500 is usually reported after upgrading or updating the Exchange Server without an elevated command prompt.

However, it may also occur due to many other reasons, such as,

  • Exchange Services stopped or not working
  • Damaged OWA virtual directories
  • Damaged Exchange Server
  • Improper configuration
  • Low Resource allocation
  • Corrupt or incomplete .NET framework installation

Solutions to Fix HTTP ERROR 500 in Exchange Server

Follow these solutions in the given sequence to troubleshoot and fix the HTTP 500 error in Exchange Server EAC/ECP after login.

Solution 1: Use a Different Browser

Sometimes browser cache and cookies can cause issues while accessing the Exchange Admin Center. You can reset either the web browser or use a different browser to fix the error and access the EAC/ECP.

If you still encounter the HTTP ERROR 500, proceed to the next solution.

Solution 2: Install Pending Server Updates

On your Windows Server, open the Windows Updates section and install any pending updates as they may stop certain Exchange Services resulting in HTTP ERROR 500 after EAC login.

pending updates windows server exchnage http 500

After the update, restart the server and then try to log in to the EAC. You may disable automatic Windows Updates to prevent HTTP ERROR 500. However, it is highly recommended to install the updates to stay protected.

If there are no pending updates but the error persists, follow the next solution.

Solution 3: Reinstall Updates

If the HTTP ERROR 500 occurred after installing the Exchange Server security updates, reinstall those using the elevated command prompt. The steps are as follows,

  • Open Command Prompt as administrator
  • Navigate to the location where Security updates are downloaded (.msp files) using ‘cd’ command. For instance,
cd “C:UsersUserNameDownloadsUpdates”
  • Then execute the following command in the Command Prompt window,
.UpdateName.msp
  • Follow the update wizard and complete the installation process.
  • Restart the server and check if you can now access the EAC/ECP.

Solution 4: Check Resource Allocation

Some users have reported that the HTTP ERROR 500 occurred simply because their Exchange VM doesn’t allocate enough CPU cores. To fix this, shut down the server VM and review the allocated resources.

Stellar

Add or allocate more CPU cores and RAM, if available. Restart the server and check if EAC is accessible.

Similarly, for physical servers, upgrading the hardware may fix the error. However, we recommend you follow all the troubleshooting solutions discussed in this blog before upgrading the hardware to resolve the HTTP 500 error.

Solution 5: Update Server Configurations

Improper or outdated server configuration after the server upgrade or update can also render EAC or ECP inaccessible, causing HTTP ERROR 500 after login.

In such a case, you can run UpdateConfigFiles.ps1 and UpdateCAS.ps1 PowerShell scripts located in the Exchange Server ‘Bin’ directory (C:Program FilesMicrosoftExchange ServerV15Bin) to resolve the error.

run powershell scripts Exchange http 500 fix

To execute these PowerShell scripts, follow these steps,

  • Open PowerShell as administrator and use the ‘cd’ command to navigate the Exchange ‘Bin’ directory. For instance,
cd “C:Program FilesMicrosoftExchange ServerV15Bin.”

Stellar

Then execute the following commands to run the PowerShell scripts to fix the configuration issues.

.UpdateConfigFiles.ps1
.UpdateCAS.ps1
updatecase ecp eac error 500

This may take a while to finish. Once done, restart the server and check if the HTTP 500 error is resolved and ECP/EAC is accessible.

Solution 6: Recreate Virtual Directories

As a last resort, you can remove the existing OWA and ECP virtual directories and create new ones to fix the HTTP 500 error in Exchange. The steps are as follows,

  • Open Exchange Management Shell (EMS) as administrator and run the following commands to remove the current OWA and ECP virtual directory
Remove-OwaVirtualDirectory –Identity “ExchangeServerNameowa (Default Web Site)”
  • Press ‘a’ or ‘y’ and then press the ‘Enter’ key.
reset owa ecp virtual directories exchange
  • Now execute the following command in the same EMS window to rebuild OWA virtual directory,
New-OwaVirtualDirectory –WebsiteName “Default Web Site”

The commands are case-sensitive.

This will rebuild the virtual directories and possibly fix the issue. It will also change the way you log in. Instead of the login page, you will see the following pop-up for login.

login to exchnage eac http 500 fixed

Enter username and password to log into ECP/EAC web console.

Solution 7: Repair Exchange Server

If none of the solutions worked for you, try repairing your Exchange Server. For this, you need to mount the same Cumulative Update ISO as installed on the server. Then use the following command in EMS to repair the server.

Setup /Mode:upgrade /IAcceptExchangeServerLicenseTerms
repair exchange server

Use ‘/IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF’ if your server is running on September 2021 or later Cumulative Update.

After the repair, restart the server and check if the HTTP ERROR 500 is resolved.

You may also set up a new Exchange Server if server repair fails and move your mailboxes and mail items from the old server to the new server. For this, you can use an EDB converter tool, such as Stellar Converter for EDB. The software can extract mailbox data from your faulty Exchange server with an online or offline database and export them to PST. You may also export the mailboxes from offline EDB to your new Exchange Server database to PST. The software auto-maps the source mailboxes with destination mailboxes and exports up to four mailboxes simultaneously to the target server database in a few simple steps.

Conclusion

HTTP ERROR 500 is common, especially after improper server update installation. However, it may also occur due to several other reasons, as discussed in this blog. We also discussed all possible solutions to resolve the HTTP ERROR 500 in Exchange Server 2013 and later versions. However, if the error isn’t resolved, it’s recommended to set up a new server and move your data from the faulty server to a new server using an EDB converter tool, such as Stellar Converter for EDB. The software helps you extract and move mailbox data from offline or online databases hosted on your faulty server and exports them to PST, Office 365 tenant, or Live Exchange Server. It automates the entire mailbox data migration process, saving tons of time required to manually export and import mailboxes via EMS or EAC. Moreover, the cmdlets do not work if the database is offline.

About The Author

Ravi Singh

Ravi Singh is a Senior Writer at Stellar®. He is an expert Tech Explainer, IoT enthusiast, and a passionate nerd with over 7 years of experience in technical writing. He writes about Microsoft Exchange, Microsoft 365, Email Migration, Linux, Windows, Mac, DIY Tech, and Smart Home. Ravi spends most of his weekends working with IoT (DIY Smart Home) devices and playing Overwatch. He is also a solo traveler who loves hiking and exploring new trails.

MapiExceptionNetworkError: Unable to mount database
www.microsoft.com

Ошибки 4999, 1007, 7031 Microsoft Exchange Diagnostics стали появляться синхронно на одном из серверов Exchange 2013 в продакшене, являющимся ещё и членом DAG. Описания ошибок недвусмысленно сигнализировали о проблемах со службой диагностики Exchange. Хоть она и не является критически важным компонентом и без неё почта будет бегать в обе стороны совершенно спокойно, без внимания все же такую ситуацию оставлять не хотелось.


Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.


Для начала небольшая диагностическая информация. Полный текст ошибки 4009:

Будет отправлен отчет программы «Доктор Ватсон» для идентификатора процесса 32268 с параметрами E12IIS, c-RTL-AMD64, 15.00.1044.025, M.E.Diagnostics.Service, M.E.Diagnostics.PerformanceLogger, M.E.D.P.PerformanceLogSet.StartLog, System.ArgumentException, 95c6, 15.00.1044.021.

ErrorReportingEnabled: True

Скрин:

4999, 1007, 7031 Microsoft Exchange Diagnostics 04

Полный текст ошибки 1007:

Не удалось создать или запустить журналы производительности, ошибка: System.ArgumentException: Значение не попадает в ожидаемый диапазон.

в PlaLibrary.DataCollectorSetClass.start(Boolean Synchronous)

в Microsoft.Exchange.Diagnostics.PerformanceLogger.PerformanceLogSet.StartLog(Boolean synchronous)

в Microsoft.Exchange.Diagnostics.PerformanceLogger.PerformanceLogMonitor.CheckPerflogStatus(). Журнал производительности: ExchangeDiagnosticsPerformanceLog.

Скриншот:

4999, 1007, 7031 Microsoft Exchange Diagnostics 03

Полный текст ошибки 7031:

Служба Microsoft Exchange Diagnostics была неожиданно завершена. Это произошло 784 раз(а). Следующее корректирующее действие будет предпринято через 60000 мсек: Перезапуск службы.

Ну и последний скрин:

4999, 1007, 7031 Microsoft Exchange Diagnostics 05

Аварийное завершение службы в 784 раз не радовало глаз.

Ошибка 1007 указывала на проблемы с журналом производительности ExchangeDiagnosticsPerformanceLog. Отлично, идем в Монитор производительности (через оснастку MMC) и смотрим что у нас там создано. На мое удивление там была всего лишь одна группа сборщиков данных Exchange (с чем сравнивать было — на втором сервере-партнере по DAG картина была совершенно другая), которая периодически пропадала и появлялась снова. Вот так это выглядело вживую:

4999, 1007, 7031 Microsoft Exchange Diagnostics 02

4999, 1007, 7031 Microsoft Exchange Diagnostics 01

Обратите внимание на статус сборщика (на скрине вверху справа — статус пустой). Если нажать F5, сборщик пропадал, через некоторое время появлялся снова. Удалить его не получалось. Решение 1 проблемы нашел на официальных ресурсах — блоге Technet. Заключается оно в следующем — через реестр удалить сбойные сборщики данных. После перезагрузки они пересоздадутся автоматически.

Открываем regedit, проходим в ветку реестра:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionScheduleTaskCacheTreeMicrosoftWindowsPLAExchangeDiagnosticsDailyPerformanceLog

Удаляем проблемный сборщик данных Exchange (префикс ExchangeDiagnostics…, другие не трогать). У меня это был ExchangeDiagnosticsPerformanceLog, как я упоминал выше (ничего страшного, если удалите оба):

4999, 1007, 7031 Microsoft Exchange Diagnostics 06

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

4999, 1007, 7031 Microsoft Exchange Diagnostics 07

Проблема на этом была решена.

comments powered by HyperComments

  • #1

Доброго времени суток! Несколько месяцев назад с приключениями переехал на Exchange 2016, были косяки и грабли разного рода но в целом миграция завершилась удачно; я заводил тут ранее тему по этому — кому интересно прочтите.
Напомню на всякий случай — у меня сейчас 2 сервера в DAG. Это типа предыстория.

После этого приехал новый firewall который надо было обновить на более старшую версию. Наверное об этом стоит запилить отдельный пост но как-нибудь потом. После того как я переехал на новый FW народ начал жаловаться типа :eek: в OWA зайти не можем и activesync на смартфонах не работает. Первое что подумал — проблема с сертификатом и расшифровкой https.А вот фигу. Все там нормально переехало и дело оказалось в одном из Exchange — тот который опубликован и выставлен голой Ж🤬 в интернет и держит owa и activesync соединения.
В общем захожу я в Exchange а там в журналах — пруд пруди ошибок всех мастей и цветов. Первое что я подумал — наверное это после замены firewall (который держит все сети и маршруты) у этого почтаря «сорвало флягу» ибо он меня не пускал даже в shell и коннектился к более живучему соседу по DAG. Решил перезагрузить его. После перезагрузки Exchange ошибок стало меньше и видимо у него крыша на место встала, но часть ошибок осталась Решил собрать тут ошибки которые там возникали и разобраться с какого ляду они там появились. Вот про них я и напишу.
Буду дополнять по ходу развития событий, а пока просто перечислю ошибки которые нарыл.

Event id 12035 MSExchangeTransport

Exchange was unable to load certificate mail.reverend.ru. More information: Is FrontEnd Proxy enabled: false. Original backend Server: mail.reverend.ru. Send Connector Name from the original request: inet.

Event id 2 KernelEventTracing

Не удалось начать сеанс «RemoteCommandExecutionLog» из-за следующей ошибки: 0xC0000035

Event id 3025 MSExchangeApplicationLogic

Scenario: GetKillBit. Failed to download killbit list from OMEX server. Exception: System.Net.WebException: Базовое соединение закрыто: Непредвиденная ошибка при передаче. —> System.IO.IOException: Не удается прочитать данные из транспортного соединения: Удаленный хост принудительно разорвал существующее подключение. —> System.Net.Sockets.SocketException: Удаленный хост принудительно разорвал существующее подключение

Event id 4999 MSExchange Common

Watson report about to be sent for process id: 7860, with parameters: E12IIS, c-RTL-AMD64, 15.01.1913.005, M.Exchange.Pop3, unknown, M.E.P.C.R.<ProxyConnect>d__404.MoveNext, System.NullReferenceException, 7748-dumptidset, unknown.
ErrorReportingEnabled: False

Event id 36874 Schannel

Получен запрос на подключение TLS 1.2 от удаленного клиентского приложения, но ни один из поддерживаемых этим приложением комплектов шифров не поддерживается сервером. Запрос на подключение TLS завершился с ошибкой.

Event id 1013 MSExchangeDiagnostics

Potential data loss warning in RetentionAgent: RetentionAgent: Warning: Potential data loss. The size of this folder C:Program FilesMicrosoftExchange ServerV15LoggingDiagnosticsDailyPerformanceLogs has reached 70% of max size allowed — 5120 MB. Some data will be purged once it reaches the max limit.

Пока все но еще буду дополнять

Последнее редактирование модератором: 22.10.2020

  • #2

По event id 12035 — Exchange ищет сертификат для имени mail.reverend.ru , которое является интеллектуальным хостом в SendConnector. Проверьте, установлен ли сертификат для mail.reverend.ru в личном хранилище сертификатов на сервере Exchange. Если да, проверьте правильность, а если нет, установите его.
Посмотреть сертификаты можно с помощью Get-ExchangeCertificate
Можно включить сертификат для службы SMTP, используя следующую команду
Enable-ExchangeCertificate -Thumbprint <String> -Services SMTP
Скорее всего у вас не назначен сертификат для SMTP

  • #3

Сейчас у меня служба SMTP висит на Microsoft Exchange Server Auth Certificate
Как я понимаю это самоподписный сертификат который не содержит в альтернативных именах субъектов: mail.rerverend.ru
Интересно если я переназначу на другой сертификат службу SMTP я ничего не обвалю ?:unsure:

  • #4

Нашел решение ошибки Event ID 3025 — попробую поменять интервал

Change the interval for the Office Store access checks

  1. Open the following Web.config files in the Exchange Server 2013 Client Access Server or Exchange Server 2016 Mailbox Server:
    • %ExchangeInstallPath%ClientAccessexchwebewsweb.config
    • %ExchangeInstallPath%ClientAccessOwaweb.config
    • In Microsoft Exchange Server 2016, you must also change the REST Web.config file: %ExchangeInstallPath%ClientAccessrestweb.config
  2. Example:
    • C:Program Files MicrosoftExchange Server V15ClientAccessexchwebewsweb.config
    • C:Program Files MicrosoftExchange Server V15ClientAccessOwaweb.config
    • C:Program Files MicrosoftExchange Server V15ClientAccessrestweb.config
  3. In each Web.config file, add the following line between the «<appSettings>» line and the </appSettings> line.<add key = «KillBitRefreshTimeInSeconds» value = «<seconds>» />

    For example, the following line sets the interval for Office Store access checks to 86,400 seconds (1 day):<add key = «KillBitRefreshTimeInSeconds» value = «86400» />

  4. From the administrative tools, start Internet Information Services (IIS) Manager.
  5. Select Application Pools, right-click each of the following pools, and then click Recycle:
    • MSExchangeServicesAppPool
    • MSexchangeOWAAppPool
    • MSExchangeRestAppPool

  • #5

Еще ошибка Event ID 1008

Ошибка в процедуре открытия службы «BITS» из библиотеки «C:WindowsSystem32bitsperf.dll». Данные производительности не будут доступны для этой службы. Первые четыре байта (DWORD) в разделе данных содержат код ошибки.

DOC

DOC

Активный участник


  • #6

View counters in Performance Monitor
To view counters in Performance Monitor:

  1. On the computer where you want to view counters, click Start. In the Start Search text box, type perfmon.exe, and then press ENTER.
  2. In the navigation pane, expand Monitoring Tools, and then click Performance Monitor.
  3. Click the Add button to open a list of available performance counters.
  4. In the Add Counters dialog box, you can click Help for more information on adding counters. When you have finished adding counters to the list, click OK.
  5. Verify that the performance counters you selected are displayed in the Performance Monitor graph.

View a list of counters using the typeperf command

To view a list of counters at the command prompt:

  1. Click Start, click All Programs, and click Accessories. Right-click Command Prompt, and click Run as administrator.
  2. At the command prompt, type typeperf -qx and press ENTER.
  3. Verify that the performance counter list contains expected values.

  • #7

View counters in Performance Monitor
To view counters in Performance Monitor:

  1. On the computer where you want to view counters, click Start. In the Start Search text box, type perfmon.exe, and then press ENTER.
  2. In the navigation pane, expand Monitoring Tools, and then click Performance Monitor.
  3. Click the Add button to open a list of available performance counters.
  4. In the Add Counters dialog box, you can click Help for more information on adding counters. When you have finished adding counters to the list, click OK.
  5. Verify that the performance counters you selected are displayed in the Performance Monitor graph.

View a list of counters using the typeperf command

To view a list of counters at the command prompt:

  1. Click Start, click All Programs, and click Accessories. Right-click Command Prompt, and click Run as administrator.
  2. At the command prompt, type typeperf -qx and press ENTER.
  3. Verify that the performance counter list contains expected values.

это не совсем понял — это проблемы с производительностью Exchange ? Как узнать какие счетчики производительности выбирать ?:unsure:

  • #8

Удалось ли понять и устранить эту проблему ? У меня тоже такое есть

Event id 4999 MSExchange Common

Watson report about to be sent for process id: 7860, with parameters: E12IIS, c-RTL-AMD64, 15.01.1913.005, M.Exchange.Pop3, unknown, M.E.P.C.R.<ProxyConnect>d__404.MoveNext, System.NullReferenceException, 7748-dumptidset, unknown.
ErrorReportingEnabled: False

  • #9

Пишут что нужно установить CU на Exchange 2016 но у меня пока нет времени — не проверял

  • #10

Когда то была ошибка Event id 1013 MSExchangeDiagnostics
Решил ее так :

To relocate the logs to another location, or a larger partition/disk, do the following;
First double check the log location;

logman query ExchangeDiagnosticsDailyPerformanceLog | more

Код:

Then to move the logs, stop the logging, relocate the log location, and finally start the logging again;

logman -stop ExchangeDiagnosticsDailyPerformanceLog
logman -update ExchangeDiagnosticsDailyPerformanceLog -o “H:ExchangePerformanceLogs”
logman -start ExchangeDiagnosticsDailyPerformanceLog

move exchange performanace logs

  • #11

Potential data loss warning in RetentionAgent: RetentionAgent: Warning: Potential data loss. The size of this folder C:Program FilesMicrosoftExchange ServerV15LoggingDiagnosticsDailyPerformanceLogs has reached 70% of max size allowed — 5120 MB. Some data will be purged once it reaches the max limit.

Не удалось ли выяснить природу этой ошибки ? 🧐

  • #12

Не удалось ли выяснить природу этой ошибки ? 🧐

Proper Solution
To relocate the logs to another location, or a larger partition/disk, do the following;
First double check the log location;
logman query ExchangeDiagnosticsDailyPerformanceLog | more

Then to move the logs, stop the logging, relocate the log location, and finally start the logging again;

Код:

logman -stop ExchangeDiagnosticsDailyPerformanceLog
logman -update ExchangeDiagnosticsDailyPerformanceLog -o “H:ExchangePerformanceLogs”
logman -start ExchangeDiagnosticsDailyPerformanceLog

move exchange performanace logs

Понравилась статья? Поделить с друзьями:
  • Exception ошибка раст
  • Exception как вывести ошибку
  • Exception while verifying signature ошибка
  • Exception reading response ошибка
  • Exception python все ошибки