web-dev-qa-db-ja.com

SBS 2011：コンソール、シェル、またはWebインターフェイスを介してExchange2010を管理できません。 「WinRMはHTTP応答の競合タイプを判別できません。」

現在の設定：

  • SBS 2011（Windows 2008 R2）
  • Exchange 2010 SP3、v14.03.0399.000
  • PCI3.1 of IIS Crypto 2. （はい、継続的な接続を確保するためにRDPを更新しました）に基づいて、TLS1.1までのすべてが無効になっています。

この問題がどこに潜んでいるのか正直にわかりませんが、証明書の更新/インストールの直後に、can通常の方法でメールアカウントにアクセスしているときに、 Exchangeサーバー自体を管理できません。

最初に詳細、その後に試行された手順。

管理コンソールを使用すると、次のエラーが発生します。

[サーバー]リモートサーバーへの接続が次のエラーメッセージで失敗しました：WinRMクライアントは要求を処理できません。宛先コンピューターからのHTTP応答のコンテンツタイプを判別できません。コンテンツタイプが存在しないか無効です。詳細については、about_Remote_Troubleshootingヘルプトピックを参照してください。コマンド'Discover-ExchangeServer -UseWIA $true -SuppressError $true -CurrentVersion 'Version 14.3 (Build 123.4)''を実行していました

管理シェルを開くと、次のようになります。

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

さらに、接続したいFQDNを要求するループバックアドレスまたはlocalhostを使用しようとすると、同じエラーメッセージが表示されます。

Webインターフェースを開くと、いくつかのエラーが発生しました。

どこにでも行くには、管理者アカウントを使用して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

問題の診断に使用された最初のステップは、 EMTShooter for Exchange 201 を使用することでした。管理者権限で実行すると、次の出力が提供されました。

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にアクセスし、[既定のWebサイト]を展開し、[PowerShell]サブセクションをクリックして[認証]を開くと、Windows認証のプロバイダーにNegotiate:Kerberosが含まれていました。 Ithink最初は無効になっていると確信しているので、ある時点でそのWindows認証エントリを有効にした可能性があります（拡張保護はオフのままでした）。有効または無効のどちらでも何も変更されません。
  3. デフォルトのWebサイトのPowerShell-Proxyサブセクションには、基本設定smalllyが間違っていました。C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShellを指す代わりに、...\PowerShell-Proxyを指していました。管理コンソールのタイムアウトに約2倍の時間がかかることを除けば、修正されても変更はありませんでした。

特に/EWS/Exchange.asmxパスのWebアクセスを調べるとき、IISエラーメッセージ、および この例が見つかりました ）をよく調べました。残念ながら、SBS2011ではWindows機能は私をサーバーマネージャーに迂回させただけで、その投稿が示唆するようにすべてを有効にするために、役割自体も役割の追加サービスも.NET Framework 4.5 Advanced Services機能へのアクセスを提供できませんでした。アクセスできるのはDotNet3.xとそこにあるすべてのものだけでしたシステムが’Install-WindowsFeature’ is not recognizedと主張したため、次の投稿でPowerShellの提案を使用できませんでした。

ServerFaultに関する他の投稿も確認しました。

そして、解決策を見つけることができませんでした。

今、私はアイデアが新鮮です。アクセスを取り戻すための助けをいただければ幸いです。

windows-server-2008-r2exchangeexchange-2010windows-sbs-2011winrm
1
René Kåbis

次の記事で説明されているすべての手順を試しましたか？

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 /

1
Gavin Gao