none
Error de conexión con Consola de Administración Exchange (EMC) y Exchange Management Shell RRS feed

  • Pregunta

  • Buenas tardes,

    Entorno:

    Windows Server 2008 r2

    Exchange 2010

    -------------

    El problema y las consecuencias:

    Ya llevo tiempo arrastrando este problema. El servidor funciona y por lo tanto tengo el correo y los calendarios de los usuarios funcionando, pero tres de los buzones ya han superado su capacidad y ahora no se puede hacer anotaciones en calendarios porque no se sincronizan y tampoco pueden hacer uso del correo.

    Los errores:

    No tengo acceso a la Consola de Administración de Exchange y tampoco puedo conectar con Exchange Management Shell para aumentar la capacidad de los buzones.

    Errores en la Consola de Administración Exchange:

    Error al iniciar

    Error al buscar el servidor de Exchange local:

    [nombreservidor.net] Error de conexión al servidor remoto. Mensaje de error: El servicio Winrm recibió un mensaje de redirección HTTP que redirige al cliente pero la dirección URL de la ubicación no es válida. Para obtener más información, consulte el tema de la Ayuda about_Remote:Troubleshooting, estaba ejecutando comando 'Discover-ExchangeServer -UseWIA$true -SuppressError $true'.

    Error en Exchange Management Shell:

    [nombreservidor.net] Error de conexión al servidor remoto. Mensaje de error: El servicio WinRM recibió un mensaje de redirección HTTP que redirige al cliente per la dirección URL de la ubicación no es válida. Para obtener más información bla bla bla......

    Posible causa:

    Eliminé la conexión de IIS y luego ya no ha vuelto a funcionar. He vuelto a crear la conexión pero creco que alguna ruta o alguna recirección o método de identificación no está bien configurado.

    Pregunta:

    Si vuelvo a reinstalar Exchange me volverá a crear las conexiones y directorios de IIS sin perder los usuarios actuales?

    Muchas gracias por vuestra ayuda


    Francesc Ramírez / Administrador Exchange 2010


    miércoles, 8 de junio de 2016 13:34

Todas las respuestas

  • Hola, no puedes reinstalar Exchange solo para hacer eso y ten por seguro que eso te traería muchísimo mas trabajo y problemas. Pero si puedes revisar la configuración de cada elemento. 

    Configuraciones por defecto SSL
    https://technet.microsoft.com/en-us/library/gg247612(v=exchg.141).aspx

    Eliminar la redirección IIS -->  HTTPRedirect -->  Redirect requests to this destination.

    aspnet_client
    Autodiscover
    Ecp
    EWS
    Microsoft-Server-ActiveSync
    OAB
    Owa
    PowerShell
    PowerShell-Proxy
    Rpc

    https://support.microsoft.com/en-us/kb/975341

    Seguramente tu problema es relacionado a uno de esos items (SSL o re dirección), sino hay otros cmdlets que permitirían re-crear los sitios, pero prueba primero con eso primero.


    jueves, 9 de junio de 2016 7:12
  • Hola Nicolás, muchas gracias por tu respuesta. 

    He seguido las directivas de configuración por defecto referentes a HTTPRedirect i a SSL por defecto en IIS y no se han producido cambios. Sigue sin conectar con el servidor remoto. Es cierto que algunas carpetas no aparecen en mi sitio IIS :

    aspnet_client

    PowerShell-Proxy

    Rpc

    Veo algunas contradicciones en cuanto a la configuración de SSL por defecto en Default Web Site, pero tanto si activo como si desactiva requerir SSL el resultado es el mismo.


    Francesc Ramírez / Administrador Exchange 2010

    jueves, 9 de junio de 2016 8:04
  • Ok, entonces vamos al segundo paso, utilizar EMTShooter http://exchangeserverpro.com/fixing-exchange-2010-management-tools-winrm-errors/

    jueves, 9 de junio de 2016 8:38
  • HOla Nicolás,

    Hice los cambios en IIS y reinicié el servidor. Se descargó unas actualizaciones y ha estado horas en el proceso.

    Tras ponerse en marcha he ejecutado la utilidad EMTShooter que parece haber añadido :

    HTTP Port 80 successfully added to the Default Web Site

    Ejecuto : iisreset /noforce

    Pero sigue el mismo error de conexión con servidor remoto. No hay cambios

    Copio y pego el informe de EMTShooter :

    #################################################################################

    # The sample scripts are not supported under any Microsoft standard support 
    # program or service. The sample scripts are provided AS IS without warranty 
    # of any kind. Microsoft further disclaims all implied warranties including, without 
    # limitation, any implied warranties of merchantability or of fitness for a particular 
    # purpose. The entire risk arising out of the use or performance of the sample scripts 
    # and documentation remains with you. In no event shall Microsoft, its authors, or 
    # anyone else involved in the creation, production, or delivery of the scripts be liable 
    # for any damages whatsoever (including, without limitation, damages for loss of business 
    # profits, business interruption, loss of business information, or other pecuniary loss) 
    # arising out of the use of or inability to use the sample scripts or documentation, 
    # even if Microsoft has been advised of the possibility of such damages
    #
    #################################################################################

    # Copyright (c) Microsoft Corporation. All rights reserved.
    # Written by Steve Bryant
    # Version .08

    ConvertFrom-StringData @'
    ###PSLOC
    emts_eh_000 = \nProblem found:\n
    emts_eh_001 = Looking for error...\n
    emts_eh_002 = Connecting to remote server failed with the following error message :
    emts_eh_003 = The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service:
    emts_eh_004 = The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol.
    emts_eh_005 = The WinRM client received an HTTP server error status \(500\), but the remote service did not include any other information about the cause of the failure
    emts_eh_006 = 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.
    emts_eh_007 = The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer
    emts_eh_008 = The WS-Management service does not support the request.
    emts_eh_009 = The WinRM client received an HTTP status code of 403 from the remote WS-Management service.
    emts_eh_010 = Unknown Error\n
    emts_eh_011 = These are the possible causes for this error:\n
    emts_eventlog_00 = The Exchange Management Troubleshooter is starting.
    emts_eventlog_01 = The Exchange Management Troubleshooter indentified a problem that can be caused by several issues:\n\n
    emts_eventlog_02 = 1. If the WSMan module entry is missing from the global modules section of the\nC:\\Windows\\System32\\Inetsrv\\config\\ApplicationHost.config file, as follows:\n\n<globalModules>\n           <add name="WSMan" image="C:\\Windows\\system32\\wsmsvc.dll" />\n\nThis will result in the WSMan module displaying as a Managed module on the PowerShell virtual directory.\n\nTo 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 ApplicationHost.config file as shown above.\n
    emts_eventlog_03 = \n2. Remote PowerShell uses Kerberos to authenticate the user connecting.  IIS implements this Kerberos authentication method 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 Server\\v14\\Bin\\kerbauth.dll. If the Kerbauth module shows up as a Managed module instead of Native, or if the Kerbauth module has been loaded on the Default Web Site level (instead of, or in addition to, the PowerShell virtual directory), you can experience this issue. To correct this, make sure that the Kerbauth module is not enabled on the Default Web Site, but 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.\n
    emts_eventlog_04 = The http binding has been removed from the Default Web Site. Exchange Powershell needs http to be configured so that the IP Address is "All Unassigned", the Port is "80", and the Host Name is "". A common scenario for changing this is if you are running multiple web sites, and attempting to set up a redirect to https://mail.company.com/owa by requiring SSL on the Default Web Site, and creating another web site to do the redirect back to the SSL-enabled website.
    emts_eventlog_05 = \nRemote PowerShell requires port 80 to be available on the Default Web Site. If you want to set up an automatic redirect to /owa and redirect http requests to https, you should follow the instructions located at http://technet.microsoft.com/en-us/library/aa998359(EXCHG.80).aspx and follow the directions under the section For a Configuration in Which SSL is Required on the Default Web Site or on the OWA Virtual Directory in IIS 7.0.\n
    emts_eventlog_06 = The "Require SSL" option has possibly been enabled on the PowerShell Virtual Directory. To resolve this, remove the "Require SSL" option from this Virtual Directory. The Exchange Management Tools connect over port 80, not 443.  So if Require SSL is set, when a connection is attempted on port 80, IIS will return a 403 error indicating SSL is required.\n
    emts_eventlog_07 = The Path of the Powershell virtual directory has been modified.  The PowerShell virtual directory must point to the\n\n"\\Exchange Server\\v14\\ClientAccess\\PowerShell"\n\ndirectory or you will encounter problems.\n
    emts_eventlog_08 = The default http binding has been removed from the Default Web Site. Exchange Powershell needs http to be configured so that the IP Address is "All Unassigned", the Port is "80", and the Host Name is "".  A common scenario for changing this is if you are running multiple web sites, and attempting to set up a redirect to https://mail.company.com/owa by requiring SSL on the Default Web Site, and creating another web site to do the redirect back to the SSL-enabled website. Remote PowerShell requires port 80 to be available on the Default Web Site for all Internet Addresses. If you want to set up an automatic redirect to /owa and redirect http requests to https, you should follow the instructions located at:\n\nhttp://technet.microsoft.com/en-us/library/aa998359(EXCHG.80).aspx\n\nand follow the directions under the section:\n"For a Configuration in Which SSL is required on the Default Web Site or on the OWA Virtual Directory in IIS 7.0."\n
    emts_eventlog_09 = The http binding on the Default Web Site has been modified, and the Hostname field configured. To correct this issue, you need to clear out the Hostname field under the port 80 bindings on the Default Web Site.\n
    emts_eventlog_10 = The ExchangeInstallPath Environment Variable is missing. To make sure that the ExchangeInstallPath value is set correctly, open the System item in Control Panel, click Advanced system settings, and then click Environment variables on the Advanced tab. In the System variables box, locate the ExchangeInstallPath variable. \n\nThe corresponding value for this variable should be similar to:\nC:\\Program Files\\Microsoft\\Exchange Server\\V14\\\n
    emts_eventlog_11 = The ExchangeInstallPath Environment Variable does not match the Exchange Install Path found in the registry.\n\nRegistry Entry:\n{0}\n\nvs\n\nExchangeInstallPath Environment Variable:\n{1}\n\nPlease ensure that both reflect the proper path to the Exchange binary files.\n\nThe MsinstallPath registry key can be found at:\nHKLM:\\SOFTWARE\\Microsoft\\ExchangeServer\\v14\\Setup\\MsiInstallPath
    emts_eventlog_12 = You are receiving an invalid ExchangeInstallPath error, even though the ExchangeInstallPath pretest passed.  This is usually caused when you correct an ExchangeInstallPath problem and then need to restart the computer before re-running the test.\n
    emts_eventlog_13 = The ExchangeInstallPath Environment Variable does not match the Exchange Install Path found in the registry.\n\nRegistry Entry:
    emts_eventlog_14 = \nvs\n
    emts_eventlog_15 = ExchangeInstallPath Environment Variable:
    emts_eventlog_16 = \nPlease ensure that both reflect the proper path to the Exchange binary files.\n\nThe MsinstallPath registry key can be found at\nHKLM:\\SOFTWARE\\Microsoft\\ExchangeServer\\v14\\Setup\\MsiInstallPath\n
    emts_eventlog_17 = The Exchange Management Troubleshooter successfully completed connecting to:\n
    emts_000 = Checking IIS Service...\n
    emts_001 = Checking HTTP Port 80...\n
    emts_002 = Checking HTTP Port 80 Host Name...\n
    emts_003 = Checking the Exchange Install Path variable...\n
    emts_004 = Checking the Powershell vdir SSL setting...\n
    emts_005 = Checking the Powershell vdir path setting...\n
    emts_006 = Testing for errors...\n
    emts_007 = HTTP Port 80 successfully added to the Default Web Site.\n
    emts_008 = Cannot run without HTTP Port 80 binding on the Default Web Site, exiting program...\n
    emts_009 = The service $ServiceNameFull is not running.\nConnecting to Powershell requires this service to be running.\n
    emts_010 = Cannot run without IIS, exiting program...\n
    emts_011 = Microsoft-Exchange-Troubleshooters/Operational
    emts_012 = Exchange Management Troubleshooter
    emts_013 = IIS is not running.
    emts_014 = Do you want to start the IIS service?
    emts_015 = RESOLVED:\n\n
    emts_016 = UNRESOLVED:\n\n
    emts_017 = After each error is resolved, close this window and re-run the tool to check for additional problems.\n
    emts_018 = \nWelcome to the Exchange Management Troubleshooter!\n
    emts_019 = We recommend that you run the troubleshooter after making changes to\nIIS to ensure that connectivity to Exchange Powershell is unaffected.\n
    emts_020 = True
    emts_021 = False
    emts_022 = Checking the Powershell Virtual Directory...\n
    ###PSLOC
    '@


    Francesc Ramírez / Administrador Exchange 2010

    jueves, 9 de junio de 2016 14:24
  • emts_008 = Cannot run without HTTP Port 80 binding on the Default Web Site, exiting program...\n

    ¿El segundo sitio que tienes en el IIS esta usando la misma ip por el puerto 80 sin un header?.

    jueves, 9 de junio de 2016 16:21
  • Buenas,

    Ahora tengo un sitio. Estos son los enlaces. Sigue el error de conexión.


    Francesc Ramírez / Administrador Exchange 2010

    El nuevo informe de EMTShooter :

    # Copyright (c) Microsoft Corporation. All rights reserved.
    # Written by Steve Bryant
    # Version .08

    ConvertFrom-StringData @'
    ###PSLOC
    emts_eh_000 = \nProblem found:\n
    emts_eh_001 = Looking for error...\n
    emts_eh_002 = Connecting to remote server failed with the following error message :
    emts_eh_003 = The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service:
    emts_eh_004 = The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol.
    emts_eh_005 = The WinRM client received an HTTP server error status \(500\), but the remote service did not include any other information about the cause of the failure
    emts_eh_006 = 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.
    emts_eh_007 = The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer
    emts_eh_008 = The WS-Management service does not support the request.
    emts_eh_009 = The WinRM client received an HTTP status code of 403 from the remote WS-Management service.
    emts_eh_010 = Unknown Error\n
    emts_eh_011 = These are the possible causes for this error:\n
    emts_eventlog_00 = The Exchange Management Troubleshooter is starting.
    emts_eventlog_01 = The Exchange Management Troubleshooter indentified a problem that can be caused by several issues:\n\n
    emts_eventlog_02 = 1. If the WSMan module entry is missing from the global modules section of the\nC:\\Windows\\System32\\Inetsrv\\config\\ApplicationHost.config file, as follows:\n\n<globalModules>\n           <add name="WSMan" image="C:\\Windows\\system32\\wsmsvc.dll" />\n\nThis will result in the WSMan module displaying as a Managed module on the PowerShell virtual directory.\n\nTo 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 ApplicationHost.config file as shown above.\n
    emts_eventlog_03 = \n2. Remote PowerShell uses Kerberos to authenticate the user connecting.  IIS implements this Kerberos authentication method 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 Server\\v14\\Bin\\kerbauth.dll. If the Kerbauth module shows up as a Managed module instead of Native, or if the Kerbauth module has been loaded on the Default Web Site level (instead of, or in addition to, the PowerShell virtual directory), you can experience this issue. To correct this, make sure that the Kerbauth module is not enabled on the Default Web Site, but 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.\n
    emts_eventlog_04 = The http binding has been removed from the Default Web Site. Exchange Powershell needs http to be configured so that the IP Address is "All Unassigned", the Port is "80", and the Host Name is "". A common scenario for changing this is if you are running multiple web sites, and attempting to set up a redirect to https://mail.company.com/owa by requiring SSL on the Default Web Site, and creating another web site to do the redirect back to the SSL-enabled website.
    emts_eventlog_05 = \nRemote PowerShell requires port 80 to be available on the Default Web Site. If you want to set up an automatic redirect to /owa and redirect http requests to https, you should follow the instructions located at http://technet.microsoft.com/en-us/library/aa998359(EXCHG.80).aspx and follow the directions under the section For a Configuration in Which SSL is Required on the Default Web Site or on the OWA Virtual Directory in IIS 7.0.\n
    emts_eventlog_06 = The "Require SSL" option has possibly been enabled on the PowerShell Virtual Directory. To resolve this, remove the "Require SSL" option from this Virtual Directory. The Exchange Management Tools connect over port 80, not 443.  So if Require SSL is set, when a connection is attempted on port 80, IIS will return a 403 error indicating SSL is required.\n
    emts_eventlog_07 = The Path of the Powershell virtual directory has been modified.  The PowerShell virtual directory must point to the\n\n"\\Exchange Server\\v14\\ClientAccess\\PowerShell"\n\ndirectory or you will encounter problems.\n
    emts_eventlog_08 = The default http binding has been removed from the Default Web Site. Exchange Powershell needs http to be configured so that the IP Address is "All Unassigned", the Port is "80", and the Host Name is "".  A common scenario for changing this is if you are running multiple web sites, and attempting to set up a redirect to https://mail.company.com/owa by requiring SSL on the Default Web Site, and creating another web site to do the redirect back to the SSL-enabled website. Remote PowerShell requires port 80 to be available on the Default Web Site for all Internet Addresses. If you want to set up an automatic redirect to /owa and redirect http requests to https, you should follow the instructions located at:\n\nhttp://technet.microsoft.com/en-us/library/aa998359(EXCHG.80).aspx\n\nand follow the directions under the section:\n"For a Configuration in Which SSL is required on the Default Web Site or on the OWA Virtual Directory in IIS 7.0."\n
    emts_eventlog_09 = The http binding on the Default Web Site has been modified, and the Hostname field configured. To correct this issue, you need to clear out the Hostname field under the port 80 bindings on the Default Web Site.\n
    emts_eventlog_10 = The ExchangeInstallPath Environment Variable is missing. To make sure that the ExchangeInstallPath value is set correctly, open the System item in Control Panel, click Advanced system settings, and then click Environment variables on the Advanced tab. In the System variables box, locate the ExchangeInstallPath variable. \n\nThe corresponding value for this variable should be similar to:\nC:\\Program Files\\Microsoft\\Exchange Server\\V14\\\n
    emts_eventlog_11 = The ExchangeInstallPath Environment Variable does not match the Exchange Install Path found in the registry.\n\nRegistry Entry:\n{0}\n\nvs\n\nExchangeInstallPath Environment Variable:\n{1}\n\nPlease ensure that both reflect the proper path to the Exchange binary files.\n\nThe MsinstallPath registry key can be found at:\nHKLM:\\SOFTWARE\\Microsoft\\ExchangeServer\\v14\\Setup\\MsiInstallPath
    emts_eventlog_12 = You are receiving an invalid ExchangeInstallPath error, even though the ExchangeInstallPath pretest passed.  This is usually caused when you correct an ExchangeInstallPath problem and then need to restart the computer before re-running the test.\n
    emts_eventlog_13 = The ExchangeInstallPath Environment Variable does not match the Exchange Install Path found in the registry.\n\nRegistry Entry:
    emts_eventlog_14 = \nvs\n
    emts_eventlog_15 = ExchangeInstallPath Environment Variable:
    emts_eventlog_16 = \nPlease ensure that both reflect the proper path to the Exchange binary files.\n\nThe MsinstallPath registry key can be found at\nHKLM:\\SOFTWARE\\Microsoft\\ExchangeServer\\v14\\Setup\\MsiInstallPath\n
    emts_eventlog_17 = The Exchange Management Troubleshooter successfully completed connecting to:\n
    emts_000 = Checking IIS Service...\n
    emts_001 = Checking HTTP Port 80...\n
    emts_002 = Checking HTTP Port 80 Host Name...\n
    emts_003 = Checking the Exchange Install Path variable...\n
    emts_004 = Checking the Powershell vdir SSL setting...\n
    emts_005 = Checking the Powershell vdir path setting...\n
    emts_006 = Testing for errors...\n
    emts_007 = HTTP Port 80 successfully added to the Default Web Site.\n
    emts_008 = Cannot run without HTTP Port 80 binding on the Default Web Site, exiting program...\n
    emts_009 = The service $ServiceNameFull is not running.\nConnecting to Powershell requires this service to be running.\n
    emts_010 = Cannot run without IIS, exiting program...\n
    emts_011 = Microsoft-Exchange-Troubleshooters/Operational
    emts_012 = Exchange Management Troubleshooter
    emts_013 = IIS is not running.
    emts_014 = Do you want to start the IIS service?
    emts_015 = RESOLVED:\n\n
    emts_016 = UNRESOLVED:\n\n
    emts_017 = After each error is resolved, close this window and re-run the tool to check for additional problems.\n
    emts_018 = \nWelcome to the Exchange Management Troubleshooter!\n
    emts_019 = We recommend that you run the troubleshooter after making changes to\nIIS to ensure that connectivity to Exchange Powershell is unaffected.\n
    emts_020 = True
    emts_021 = False
    emts_022 = Checking the Powershell Virtual Directory...\n
    ###PSLOC

    Por cierto, tengo una duda sobre las rutas a las que tiene que apuntar IIS. ¿Hay algún sitio donde pueda verlas para copiar la configuración?

    Creo qeu tengo algo de conflicto en esa configuración. Pongo las dos posibilidades ante la duda de cuál es la correcta

    viernes, 10 de junio de 2016 7:58