Назад | Перейти на главную страницу

SBS 2011: невозможно управлять Exchange 2010 через консоль, оболочку или веб-интерфейс. «WinRM не может определить тип контекста HTTP-ответа».

Текущая настройка:

Честно говоря, не знаю, откуда взялась эта проблема, но вскоре после обновления / установки сертификата мы обнаружили, что жестяная банка получить доступ к нашим учетным записям электронной почты обычным способом, мы не можем управлять самим сервером Exchange.

Сначала подробности, затем предпринимаемые шаги.

При использовании Консоли управления мы получаем следующую ошибку:

[Сервер] Не удалось подключиться к удаленному серверу, появляется следующее сообщение об ошибке: Клиент WinRM не может обработать запрос. Он не может определить тип содержимого ответа HTTP от конечного компьютера. Тип содержимого отсутствует или недействителен. Для получения дополнительной информации см. Раздел справки about_Remote_Troubleshooting. Выполнялась команда 'Discover-ExchangeServer -UseWIA $true -SuppressError $true -CurrentVersion 'Version 14.3 (Build 123.4)''

При открытии Management Shell мы получаем следующее:

VERBOSE: Connecting to [Server]
[Server] Connecting to remote server failed with the following error message : The WinRM client ca
nnot process the request. It cannot determine the content type of the HTTP response from the destination computer. The
content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic.
  + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc
eption
  + FullyQualifiedErrorId : PSSessionOpenFailed

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

При открытии веб-интерфейса мы столкнулись с рядом ошибок.

Чтобы хоть что-нибудь получить, мне пришлось «войти» в сам OWA, используя учетную запись администратора, затем «увидеть все параметры» в раскрывающемся списке параметров, а затем «Управление этой организацией». Оказавшись внутри, я получил только следующее всплывающее сообщение, когда попытался получить доступ к какой-либо функции управления:

Сожалею! У нас возникли проблемы с обработкой вашего запроса прямо сейчас. Пожалуйста, повторите попытку через несколько минут.

Когда я попытался напрямую перейти на EWS, используя этот URL: https://[localhost]/EWS/Exchange.asmx, Я получил следующее сообщение об ошибке IIS:

Server Error in '/EWS' Application.
Could not load type 'System.ServiceModel.Activation.ServiceHttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.TypeLoadException: Could not load type 'System.ServiceModel.Activation.ServiceHttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:


[TypeLoadException: Could not load type 'System.ServiceModel.Activation.ServiceHttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.]
   System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMarkHandle stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName, ObjectHandleOnStack type) +0
   System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName) +95
   System.Type.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase) +64
   System.Web.Compilation.BuildManager.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase) +59
   System.Web.Configuration.ConfigUtil.GetType(String typeName, String propertyName, ConfigurationElement configElement, XmlNode node, Boolean checkAptcaBit, Boolean ignoreCase) +49

[ConfigurationErrorsException: Could not load type 'System.ServiceModel.Activation.ServiceHttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.]
   System.Web.Configuration.ConfigUtil.GetType(String typeName, String propertyName, ConfigurationElement configElement, XmlNode node, Boolean checkAptcaBit, Boolean ignoreCase) +550
   System.Web.Configuration.ConfigUtil.GetType(String typeName, String propertyName, ConfigurationElement configElement, Boolean checkAptcaBit) +30
   System.Web.Configuration.Common.ModulesEntry.SecureGetType(String typeName, String propertyName, ConfigurationElement configElement) +57
   System.Web.Configuration.Common.ModulesEntry..ctor(String name, String typeName, String propertyName, ConfigurationElement configElement) +57
   System.Web.HttpApplication.BuildIntegratedModuleCollection(List`1 moduleList) +173
   System.Web.HttpApplication.GetModuleCollection(IntPtr appContext) +1069
   System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +130
   System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +165
   System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +353
   System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +341

[HttpException (0x80004005): Could not load type 'System.ServiceModel.Activation.ServiceHttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +523
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +107
   System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +688


Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.7.3130.0

Первым шагом для диагностики проблемы было использование EMTShooter для Exchange 2010. При запуске с правами администратора он выдал следующий вывод:

Welcome to the Exchange Management Troubleshooter!

We recommend that you run the troubleshooter after making changes to
IIS to ensure that connectivity to Exchange Powershell is unaffected.

Checking IIS Service...

Checking the Exchange Install Path variable...

Checking the Powershell Virtual Directory...

Checking the Powershell vdir SSL setting...

Checking the Powershell vdir path setting...

Checking HTTP Port 80...

Checking HTTP Port 80 Host Name...

Testing for errors...

VERBOSE: Connecting to ECLIPSESERVER.eclipse.local


[Server] Connecting to remote server failed with the following error message : The WinRM client can
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExcep
    + FullyQualifiedErrorId : PSSessionOpenFailed
The Exchange Management Troubleshooter successfully completed connecting to:

[Server]

Failed to connect to any Exchange Server in the current site.

Problem found:

Looking for error...

These are the possible causes for this error:

1. If the WSMan module entry is missing from the global modules section of the
C:\Windows\System32\Inetsrv\config\ApplicationHost.config file, as follows:

<globalModules>
           <add name="WSMan" image="C:\Windows\system32\wsmsvc.dll" />

This will result in the WSMan module displaying as a Managed module on the PowerShell virtual directory.

To correct this, make sure that the WSMan module has been registered (but not enabled) at the Server level, and has been
 enabled on the PowerShell virtual directory.  Confirm that the WSMan entry exists in the Global Section of the Applicat
ionHost.config file as shown above.


2. Remote PowerShell uses Kerberos to authenticate the user connecting.  IIS implements this Kerberos authentication met
hod via a native module. In IIS Manager, if you go to the PowerShell Virtual Directory and then look at the Modules, you
 should see Kerbauth listed as a Native Module, with the dll location pointing to \Program Files\Microsoft\Exchange Serv
er\v14\Bin\kerbauth.dll. If the Kerbauth module shows up as a Managed module instead of Native, or if the Kerbauth modul
e has been loaded on the Default Web Site level (instead of, or in addition to, the PowerShell virtual directory), you c
an experience this issue. To correct this, make sure that the Kerbauth module is not enabled on the Default Web Site, bu
t is only enabled on the PowerShell virtual directory.  The entry type of "Local" indicates that the Kerbauth module was
 enabled directly on this level, and not inherited from a parent.

3.  The Path of the Powershell virtual directory has been modified.  The PowerShell virtual directory must point to the

"\Exchange Server\v14\ClientAccess\PowerShell"

directory or you will encounter problems.

After each error is resolved, close this window and re-run the tool to check for additional problems.

[EMTS] C:\Windows\system32>

Ладно, пока все хорошо! За исключением… не все эти проблемы существовали, и никакие изменения не помогли устранить проблему.

  1. В <globalModules> была правильная запись.
  2. Проверка подлинности Kerberos выполнялась через собственный модуль, который указывал на правильную dll. Кроме того, когда я вошел в IIS, развернул веб-сайт по умолчанию, щелкнул подраздел PowerShell и открыл аутентификацию, включая поставщиков для аутентификации Windows. Negotiate:Kerberos. я считать Возможно, я включил эту запись проверки подлинности Windows в какой-то момент, так как я почти уверен, что она была отключена вначале (а расширенная защита была и остается отключенной). Либо включено, либо отключено ничего не меняет.
  3. Подраздел PowerShell-Proxy веб-сайта по умолчанию имел базовую настройку слегка неправильно начать с: вместо того, чтобы указывать на C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell, он указывал на ...\PowerShell-Proxy вместо. Когда это было исправлено, изменений не было, за исключением того, что время ожидания консоли управления увеличилось примерно в два раза.

При проверке доступа в Интернет для /EWS/Exchange.asmx path, в частности, я внимательно изучил сообщение об ошибке IIS и нашел этот пример. К сожалению, с SBS2011 функции Windows просто перенаправили меня в диспетчер сервера, и ни сами роли, ни службы добавления ролей не могли предоставить мне никакого доступа к .NET Framework 4.5 Advanced Services функции, чтобы включить все, как предлагалось в этом сообщении. Единственное, что было доступно, это DotNet 3.x, и все там было установлено и активно. Мне не удалось использовать предложения PowerShell в следующем посте, поскольку система утверждала, что ’Install-WindowsFeature’ is not recognized.

Я также просмотрел другие сообщения на ServerFault:

И не смогли найти решения.

Прямо сейчас у меня совсем нет идей. Любая помощь в восстановлении доступа будет принята с благодарностью.

Вы пробовали все шаги, описанные в следующих статьях?

Сообщение об ошибке при попытке запустить Exchange Management Shell (EMS) или Exchange Management Console (EMC): «Клиент WinRM ... не может определить тип содержимого HTTP-ответа с конечного компьютера» https://support.microsoft.com/en-sg/help/2028305/error-message-when-you-try-to-start-exchange-management-shell-ems-or-e

Решение для ошибки удаленного взаимодействия PowerShell «Не удается определить тип содержимого HTTP-ответа от конечного компьютера…» https://oyvindnilsen.com/solution-for-powershell-remoting-error-it-cannot-determine-the-content-type-of-the-http-response-from-the-destination-computer/