SBS 2011: Não é possível gerenciar o Exchange 2010 por meio de console, shell ou interface da web. “O WinRM não pode determinar o tipo de contet de resposta HTTP.”

Question

Configuração atual:

• SBS 2011 (Windows 2008 R2)
• Exchange 2010 SP3, v14.03.0399.000
• Tudo até o TLS 1.1 está desativado, com base em PCI3.1 do IIS Crypto 2.0 (sim, atualizei o RDP para garantir a conectividade contínua).

Não saibam honestamente onde esse problema se instalou, mas logo após a renovação / instalação de um certificado, descobrimos que, enquanto <<> podemos alcançar nossas contas de e-mail por meio de qualquer método normal, não podemos administrar Servidor do Exchange em si.

Detalhes primeiro, etapas tentadas depois.

Ao usar o Console de gerenciamento, obtemos o seguinte erro:

[Server] Connecting to remote server failed with the following error message: The WinRM client cannot 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 more information, see the about_Remote_Troubleshooting help topic. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true -CurrentVersion 'Version 14.3 (Build 123.4)''

Ao abrir o Shell de gerenciamento, obtemos o seguinte:

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

Além disso, qualquer tentativa de usar um endereço de loopback ou localhost em que ele solicita o FQDN em que desejo se conectar, recebo a mesma mensagem de erro.

Ao abrir a interface da web, nos foi apresentado um número de erros.

Para chegar a qualquer lugar, tive que fazer o "login" no próprio OWA usando a conta de administrador, depois "ver todas as opções" na lista suspensa de opções e depois em "Gerenciar esta organização". Uma vez dentro, recebi apenas a seguinte mensagem pop-up quando tentei acessar qualquer recurso de gerenciamento:

Sorry! We're having trouble processing your request right now. Please try again in a few minutes.

Quando tentei ir diretamente para o EWS usando este URL: https://[localhost]/EWS/Exchange.asmx , recebi a seguinte mensagem de erro do 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 

O primeiro passo usado para diagnosticar o problema foi usar EMTShooter for Exchange 2010 . Quando executado com privilégios de administrador, ele forneceu a seguinte saída:

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>

Ok, até aí tudo bem! Exceto… nem todos esses problemas existiam e nenhuma alteração corrigiu o problema.

1. O <globalModules> teve a entrada correta.
2. A autenticação do Kerberos foi feita por meio de um módulo nativo, que estava apontando para a dll correta. Além disso, quando entrei no IIS, expandi o Site Padrão, cliquei na subseção do PowerShell e abri a Autenticação, e os Provedores para Autenticação do Windows incluíram Negotiate:Kerberos . Eu acho que eu posso ter habilitado essa entrada de autenticação do Windows em um ponto, como tenho certeza que foi desativado no início (e proteção estendida foi e ainda está desativado). Ativado ou desativado não muda nada.
3. A subseção PowerShell-Proxy do site da Web padrão tinha a configuração básica um pouco errada para começar: em vez de apontar para C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell , ela apontou para ...\PowerShell-Proxy . Não houve alteração quando foi corrigido, além do tempo limite do console de gerenciamento que levou aproximadamente o dobro do tempo.

Ao examinar o acesso à web para o caminho /EWS/Exchange.asmx em particular, dei uma olhada na mensagem de erro do IIS e encontrei este exemplo . Infelizmente, com o SBS2011, os Recursos do Windows simplesmente me desviavam para o Gerenciador de Servidores, e nem os próprios Papéis nem os Serviços de Funções Adicionais poderiam me fornecer acesso a .NET Framework 4.5 Advanced Services features, para habilitar tudo como esse post sugeria. A única coisa acessível era DotNet 3.x, e tudo o que estava instalado e ativo. Não foi possível usar as sugestões do PowerShell na postagem subsequente porque o sistema afirmou que ’Install-WindowsFeature’ is not recognized .

Eu também passei por outros posts no ServerFault:

• Não é possível efetuar login no Console de Gerenciamento do Exchange, a autenticação Kerberos falhou, não é possível determinar o tipo de conteúdo da resposta HTTP do computador de destino
• A sessão do PS remoto falha no servidor que não é do domínio - sim, winrm quickconfig diz que já está configurado
• link - aspnet_regiis.exe foi executado com sucesso, mas sem alteração para / EWS / website.

E não conseguimos encontrar uma solução.

Neste momento, estou sem ideias. Qualquer ajuda na recuperação do acesso seria muito apreciada.

    

Answer 1

Você tentou todas as etapas descritas nos artigos a seguir?

Mensagem de erro ao tentar iniciar o Shell de Gerenciamento do Exchange (EMS) ou o Console de Gerenciamento do Exchange (EMC): "O cliente WinRM ... não pode determinar o tipo de conteúdo da resposta HTTP do computador de destino" link

Solução para erro de remoting do powershell "Não é possível determinar o tipo de conteúdo da resposta HTTP do computador de destino ..." link