SBS 2011:无法通过控制台、shell 或 Web 界面管理 Exchange 2010。“WinRM 无法确定 HTTP 响应的内容类型。”

SBS 2011:无法通过控制台、shell 或 Web 界面管理 Exchange 2010。“WinRM 无法确定 HTTP 响应的内容类型。”

当前设置:

  • SBS 2011(Windows 2008 R2)
  • Exchange 2010 SP3,v14.03.0399.000
  • TLS 1.1 之前的所有内容均已禁用,基于IIS Crypto 2.0 的 PCI3.1(是的,我更新了 RDP 以确保持续连接)。

说实话,我不知道这个问题是从哪里来的,但在证书更新/安装后不久,我们发现,虽然我们无法通过任何正常方式访问我们的电子邮件帐户,我们无法管理 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要求我想要连接的 FQDN 时,我都会收到相同的错误消息。

打开网络界面时,我们看到了许多错误。

为了能够访问任何内容,我必须使用管理员帐户“登录”OWA,然后在选项下拉菜单中“查看所有选项”,然后“管理此组织”。进入后,当我尝试访问任何管理功能时,我只收到以下弹出消息:

抱歉!我们现在无法处理您的请求。请过几分钟再试。

当我尝试使用此 URL 直接转到 EWS: 时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 

诊断问题的第一步是使用适用于 Exchange 2010 的 EMTShooter。以管理员权限运行时,它提供以下输出:

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。更正后没有任何变化,除了管理控制台超时时间大约增加了一倍。

在检查该路径的 Web 访问时/EWS/Exchange.asmx,我仔细查看了 IIS 错误消息,然后找到了这个例子。不幸的是,在 SBS2011 中,Windows 功能只是将我转移到服务器管理器,角色本身和添加角色服务都无法为我提供任何.NET Framework 4.5 Advanced Services功能访问权限,以便按照该帖子的建议启用所有内容。唯一可访问的是 DotNet 3.x,并且那里的所有内容都已安装并处于活动状态。我无法使用后续帖子中的 PowerShell 建议,因为系统声称’Install-WindowsFeature’ is not recognized

我还阅读了有关 ServerFault 的其他帖子:

并且一直无法找到解决方案。

现在,我完全没有主意了。任何帮助我重新获得访问权限的帮助都将不胜感激。

答案1

您是否尝试了以下文章中描述的所有步骤?

尝试启动 Exchange 命令行管理程序 (EMS) 或 Exchange 管理控制台 (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/

相关内容