Resolución de errores de disponibilidad

Para solucionar un error relacionado con la información de disponibilidad, seleccione el mensaje de error aplicable de la tabla de contenido (TOC) en la parte superior de este artículo.

Si los pasos de solución de problemas no le ayudan a resolver el problema, póngase en contacto con el soporte técnico de Microsoft.

Error al comprobar la seguridad del mensaje

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error de detección automática de la dirección> de correo electrónico <smtp con el error System.Web.Services.Protocols.SoapHeaderException: error al comprobar la seguridad del mensaje en System.Web. Services.Protocols. SoapHttpClientProtocol. ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) en System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

Este error puede producirse si la autenticación WSSecurity no está habilitada o tiene que restablecerse, o después de renovar los certificados de federación en Exchange Server.

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Para actualizar los metadatos en la puerta de enlace de federación de Microsoft, ejecute el siguiente comando dos veces en el Shell de administración de Exchange (EMS) local:

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Para obtener más información, consulte Búsquedas de disponibilidad que dejan de funcionar en un entorno entre locales o en una implementación híbrida de Exchange Server.

2. Siga estos pasos para alternar la autenticación de WSSecurity:

   1. Siga el procedimiento de Los usuarios de una organización federada no pueden ver la información de disponibilidad de otra organización de Exchange para habilitar o restablecer, si ya está habilitada, la autenticación WSSecurity en los directorios virtuales Detección automática y EWS en todos los servidores de Exchange locales.

      Notas

      • Realice este paso incluso si la salida de los cmdlets Get-AutodiscoverVirtualDirectory de PowerShell e Get-WebServicesVirtualDirectory indique que la autenticación de WSSecurity ya está habilitada.

      • El procedimiento solo afecta a la disponibilidad entre locales y no afectará a otras conexiones cliente-servidor.

   2. Ejecute el iisreset /noforce comando en una ventana de PowerShell o símbolo del sistema en cada servidor exchange local para reiniciar IIS.

   3. Reinicie todos los servidores de Exchange locales.

3. Compruebe y resuelva cualquier advertencia o error de sesgo de tiempo en el registro de eventos del sistema.

4. Establezca el valor de TargetSharingEpr parámetro en la relación de la organización con la dirección URL de Servicios web de Exchange (EWS) externos locales mediante la ejecución del siguiente cmdlet en Exchange Online PowerShell:

   Set-OrganizationRelationship "O365 to On-premises*" -TargetSharingEpr <on-premises EWS external URL>
   

   Después de establecer el valor del TargetSharingEpr parámetro, el buzón de nube omite la detección automática y se conecta directamente al punto de conexión de EWS del buzón local.

   Nota: El valor predeterminado del TargetSharingEpr parámetro está en blanco. Los parámetros TargetAutodiscoverEpr de detección automática o DiscoveryEndpoint normalmente contienen la dirección URL externa de EWS local (punto de conexión de detección automática). Para obtener los TargetAutodiscoverEpr valores de parámetro y DiscoveryEndpoint , ejecute los siguientes cmdlets de PowerShell:

   Get-OrganizationRelationship | FL TargetAutodiscoverEpr
   Get-IntraOrganizationConnector | FL DiscoveryEndpoint
   

5. Asegúrese de que el valor del TargetApplicationUri parámetro de la relación de la organización coincide con el valor del AccountNamespace parámetro en el identificador de la organización federada. Para buscar el valor del TargetApplicationUri parámetro, ejecute el cmdlet de PowerShell Test-OrganizationRelationship . Para encontrar el valor del AccountNamespace parámetro, consulte Desmitificación de la disponibilidad híbrida.

Volver al principio

Error en la solicitud web de proxy: no se puede conectar al servidor remoto

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local o viceversa. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error en la solicitud web de proxy. , excepción interna: System.Net.WebException: No se puede conectar al servidor remoto ; System.Net.Sockets.SocketException: error en un intento de conexión porque la parte conectada no respondió correctamente después de un período de tiempo o se produjo un error en la conexión establecida porque el host conectado no ha podido responder CUSTOMER_IP:443 / MICROSOFT_IP:443 en System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)

Este error puede producirse si los problemas de conectividad de red impiden las conexiones entrantes o salientes entre las direcciones IP de Exchange Online y los puntos de conexión de Exchange Server.

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Compruebe que el firewall de cada servidor de Exchange local permite conexiones entrantes o salientes entre los puntos de conexión de Exchange Server y las direcciones IP de Exchange Online. Para identificar problemas de firewall, realice una solicitud de disponibilidad de Exchange Online y, a continuación, compruebe el firewall local, el proxy inverso y los registros de red. Para obtener más información sobre cómo configurar un firewall, consulte Consideraciones de firewall para la delegación federada y las direcciones URL y los intervalos de direcciones IP de Microsoft 365.

2. Compruebe que las solicitudes de Exchange Online lleguen a los servidores de acceso de cliente locales. Siga estos pasos en todos los servidores de acceso de cliente locales:

   1. Realice una solicitud de disponibilidad de Exchange Online.

   2. Compruebe los registros de IIS en la carpeta W3SVC1 del sitio web predeterminado para comprobar que la solicitud de disponibilidad está registrada. La ruta de acceso de la carpeta W3SVC1 es %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

   3. Compruebe los registros de proxy HTTP en las carpetas siguientes para comprobar que se ha registrado la solicitud de disponibilidad:

      • %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover

      • %ExchangeInstallPath%\Logging\HttpProxy\Ews

3. Pruebe la conectividad de Exchange Online con el punto de conexión local de Exchange Web Services (EWS) mediante la ejecución del siguiente cmdlet en Exchange Online PowerShell:

   Test-MigrationServerAvailability -RemoteServer <on-premises mail server FQDN> -ExchangeRemoteMove -Credentials (Get-Credential)
   

   Notas

   • Esta prueba es útil si restringe las conexiones entrantes desde Internet para permitir que solo las direcciones IP de Exchange Online se conecten al punto de conexión de EWS local.

   • Si solo algunos usuarios en la nube se ven afectados por este problema y sus buzones se hospedan en el mismo servidor de correo de Exchange Online, compruebe si ese servidor de correo puede conectarse a puntos de conexión locales. Es posible que un punto de conexión local bloquee las conexiones desde la dirección IP externa saliente de ese servidor de correo.

   • Cuando se le pidan credenciales, escriba las credenciales de administrador de dominio en formato "dominio\administrador".

Volver al principio

Error de detección automática de la dirección de correo electrónico: estado HTTP 404

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error de detección automática de la dirección <de correo electrónico dirección> SMTP del usuario con el error System.Net.WebException: Error en la solicitud con código 404 Not Foundde estado HTTP .

Este error puede producirse si los puntos de conexión de detección automática no son funcionales o están mal configurados.

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Compruebe si el punto de conexión de detección automática es válido:

   1. Ejecute los siguientes comandos para obtener la dirección URL del punto de conexión de detección automática desde el DiscoveryEndpoint parámetro o TargetAutodiscoverEpr :

      Get-IntraOrganizationConnector | FL DiscoveryEndpoint
      Get-OrganizationRelationship | FL TargetAutodiscoverEpr
      

   2. Vaya a la dirección URL del punto de conexión de detección automática en un explorador web. Un punto de conexión de detección automática válido no devolverá código 404 Not Foundde estado HTTP.

2. Asegúrese de que el dominio del usuario local se especifica en la configuración de la organización (conector dentro de la organización o relación de organización) del usuario en la nube:

   1. Ejecute los siguientes cmdlets de PowerShell en Exchange Online PowerShell:

      Get-IntraOrganizationConnector | FL TargetAddressDomains
      Get-OrganizationRelationship -Identity <cloud to on-premises ID> | FL DomainNames
      

      Compruebe que el dominio del usuario local aparece en la salida de cualquiera de los comandos. Por ejemplo, si el usuario user1@contoso.com en la nube busca la disponibilidad del usuario user2@contoso.rolocal, compruebe que aparece el dominio contoso.ro local.

   2. Si el dominio del usuario local no existe en la configuración de la organización del usuario en la nube, agregue el dominio ejecutando el siguiente cmdlet de PowerShell:

      Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<on-premises domain>"}
      

3. Asegúrese de que la asignación del controlador SVC existe en los directorios virtuales Detección automática y EWS en Sitio web predeterminado en el Administrador de IIS. Para obtener más información, vea FederationInformation couldn't be received and Exception has been thrown by the target.

   Nota: La AutodiscoverDiscoveryHander asignación (*.svc) no se usa para la búsqueda de disponibilidad de federación.

Volver al principio

Error en la solicitud web del proxy de excepción

LID: 43532

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error en la solicitud web del proxy de excepción. , excepción interna: error en la solicitud con el estado HTTP 401: Diagnósticos no autorizados: 2000005; reason= "El usuario especificado por el contexto de usuario en el token es ambiguo." ; error_category="invalid_user"

Este error puede producirse si otro buzón local usa el UPN, la dirección SMTP o la dirección SIP del usuario local.

Solución

Para resolver el problema, siga estos pasos:

1. Busque objetos de usuario locales que tengan un UPN duplicado, una dirección SMTP o una dirección SIP mediante consultas LDAP personalizadas. Puede ejecutar consultas LDAP mediante LDP.exe o el complemento MMC Usuarios y equipos de Active Directory.

   Por ejemplo, para mostrar todos los usuarios que tienen user@corp.contoso.com como UPN, user@contoso.com como la dirección SMTP o user@contoso.com como la dirección SIP, use la siguiente consulta LDAP:

   (|(userPrincipalName=user@corp.contoso.com)(proxyAddresses=SMTP:user@contoso.com)(proxyAddresses=sip:user@contoso.com))
   

   Para obtener más información sobre cómo usar LDP.exe o Usuarios y equipos de Active Directory para buscar objetos de Active Directory, vea Ejemplos de LDP.

2. Cambie la dirección duplicada o elimine el objeto de usuario duplicado.

Volver al principio

Se ha forzado la interrupción de una conexión existente por el host remoto

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error en la solicitud web de proxy. , excepción interna: System.Net.WebException: se cerró la conexión subyacente: Error inesperado en una recepción. System.IO.IOException: No se pueden leer datos de la conexión de transporte: el host remoto cerró forzadamente una conexión existente. System.Net.Sockets.SocketException: el host remoto cerró por la fuerza una conexión existente.

Este error puede producirse si un firewall local bloquea una conexión entrante desde una dirección IP de salida externa en Exchange Online.

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Compruebe si las solicitudes de disponibilidad de Exchange Online llegan a IIS en un servidor exchange. Realice una solicitud de disponibilidad de Exchange Online y busque las siguientes entradas de registro de IIS que se realizaron en el momento de la solicitud de disponibilidad:

   • Una entrada de detección automática en la carpeta %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover que contiene "ASAutoDiscover/CrossForest/EmailDomain".

     Nota: Si establece manualmente el TargetSharingEpr parámetro en la relación de la organización con la dirección URL de Exchange Web Services (EWS) externa local, se omite la detección automática y esta entrada no existirá.

   • Una entrada de EWS en la carpeta %ExchangeInstallPath%\Logging\HttpProxy\Ews que contiene "ASProxy/CrossForest/EmailDomain".

   Nota: Las marcas de tiempo de los registros de IIS usan la hora UTC.

2. Compruebe que el firewall de cada servidor de Exchange local permite conexiones entrantes o salientes entre los puntos de conexión de Exchange Server y las direcciones IP de Exchange Online. Para identificar problemas de firewall, realice solicitudes de disponibilidad de Exchange Online y, a continuación, compruebe el firewall local, el proxy inverso y los registros de red. Para obtener más información sobre cómo configurar un firewall, consulte Consideraciones de firewall para la delegación federada y las direcciones URL y los intervalos de direcciones IP de Microsoft 365.

3. Si su organización usa relaciones de organización para implementar la disponibilidad, asegúrese de que se instala un certificado de federación en cada servidor de Exchange. Ejecute los siguientes comandos en el Shell de administración de Exchange (EMS):

   Test-FederationTrustCertificate
   Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo | FL
   

   Si el certificado de federación está instalado, la salida del comando no debe contener errores ni advertencias.

4. Siga estos pasos para alternar la autenticación de WSSecurity:

   1. Siga el procedimiento de Los usuarios de una organización federada no pueden ver la información de disponibilidad de otra organización de Exchange para habilitar o restablecer, si ya está habilitada, la autenticación WSSecurity en los directorios virtuales Detección automática y EWS en todos los servidores de Exchange locales. Realice este paso incluso si la autenticación de WSSecurity ya está habilitada.

   2. Recicle los grupos de aplicaciones Detección automática y EWS en el Administrador de IIS.

   3. Ejecute el iisreset /noforce comando en una ventana de PowerShell o símbolo del sistema en cada servidor exchange local para reiniciar IIS.

5. Si solo algunos usuarios en la nube se ven afectados por este problema y sus buzones se hospedan en el mismo servidor de correo de Exchange Online, compruebe si ese servidor de correo puede conectarse a puntos de conexión locales. Es posible que un punto de conexión local bloquee las conexiones desde la dirección IP de salida de ese servidor de correo.

Volver al principio

No se encontró información de configuración del bosque o dominio en Active Directory

LID: 47932

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local o viceversa. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

No se encontró información de configuración para el dominio> de bosque o dominio <en Active Directory.

Este error puede producirse si la configuración de la organización está mal configurada.

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Compruebe que el dominio de un usuario cuya información de disponibilidad se solicita existe en la configuración de la organización del usuario que intenta ver la información de disponibilidad. Seleccione uno de los procedimientos siguientes en función de la dirección de disponibilidad.

   • De nube a local

     Para un usuario en la nube que intenta ver la información de disponibilidad de un usuario local, siga estos pasos:

     1. Conéctese a Exchange Online PowerShell y, a continuación, ejecute los siguientes cmdlets de PowerShell para obtener los dominios federados:

        Get-IntraOrganizationConnector | FL TargetAddressDomains
        Get-OrganizationRelationship -Identity <cloud to on-premises ID> | FL DomainNames
        

        Compruebe que el dominio del usuario local aparece en la salida de cualquiera de los comandos. Por ejemplo, si el usuario user1@contoso.com en la nube busca la disponibilidad del usuario user2@contoso.rolocal, compruebe que aparece el dominio contoso.ro local.

        Nota:

        También puede encontrar los nombres de dominio si se ejecutan (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses en PowerShell de Exchange Online o se ejecutan (Get-FederatedOrganizationIdentifier).Domains en el Shell de administración de Exchange (EMS) local.

     2. Si el dominio del usuario local no existe en la configuración de la organización del usuario en la nube, agregue el dominio ejecutando el siguiente cmdlet de PowerShell:

        Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<on-premises domain>"}​
        

   • Local a nube

     Para un usuario local que intenta ver la información de disponibilidad de un usuario en la nube, siga estos pasos:

     1. En EMS, ejecute los siguientes cmdlets de PowerShell:

        Get-IntraOrganizationConnector | FL TargetAddressDomains
        Get-OrganizationRelationship -Identity <on-premises to cloud ID> | FL DomainNames
        

        Compruebe si el dominio del usuario en la nube coincide con uno de los dominios enumerados en la salida del comando. Por ejemplo, si el usuario user1@contoso.ro local busca información de disponibilidad para el usuario user2@contoso.comen la nube, compruebe que el dominio contoso.com en la nube está presente en la salida de cualquiera de los comandos.

     2. Si el dominio del usuario en la nube no existe en la configuración de la organización del usuario local, agregue el dominio. Ejecute el siguiente comando:

        Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<cloud domain>"}​
        

2. Asegúrese de que la implementación híbrida de Exchange tiene una configuración híbrida completa. Si es necesario, vuelva a ejecutar el Asistente para configuración híbrida (HCW) y seleccione Configuración híbrida completa en lugar de Configuración híbrida mínima. Una configuración híbrida mínima no crea una relación de organización (confianza de federación) ni conectores dentro de la organización.

Volver al principio

Error en la solicitud web de proxy: estado HTTP 401

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará cualquiera de los siguientes mensajes de error.

Mensaje de error 1

Error en la solicitud web de proxy. ,inner exception: error de la solicitud con el estado HTTP 401: Unauthorized.

Mensaje de error 2

Error en la detección automática de la dirección de correo electrónico. ,inner exception: error de la solicitud con el estado HTTP 401: Unauthorized.

Este error puede producirse si un dispositivo perimetral delante de Exchange Server está configurado para autenticar previamente (requerir nombre de usuario y contraseña) en lugar de pasar solicitudes de Exchange Online directamente a Exchange Server. Los directorios virtuales Detección automática y EWS en implementaciones híbridas de Exchange no admiten la autenticación previa.

Algunos ejemplos de dispositivos perimetrales son servidores proxy inversos, firewalls y Microsoft Threat Management Gateway (TMG).

El mensaje de error 1 indica que se produjo un error en una solicitud de EWS.

El mensaje de error 2 indica que se produjo un error en una solicitud de detección automática.

Pasos para la solución de problemas

Para solucionar el problema de disponibilidad independientemente del mensaje de error que haya recibido, siga estos pasos. Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Compruebe si la autenticación previa está habilitada. Siga estos pasos:

   1. Ejecute la prueba de disponibilidad en el Analizador de conectividad remota para comprobar si la autenticación previa está habilitada. El buzón en la nube es el buzón de origen y el buzón local es el buzón de destino. Una vez completada la prueba, compruebe el estado de autenticación de paso a través en el punto de conexión. Si ve una marca de verificación roja, deshabilite la autenticación previa y vuelva a probar. Si ve una marca de verificación verde, continúe con el paso siguiente porque podría ser un falso positivo.

   2. Compruebe si una solicitud de disponibilidad de Exchange Online llega a IIS. Realice una consulta de disponibilidad y, a continuación, busque cualquiera de las siguientes entradas en los registros de IIS en Exchange Server en el momento de la consulta:

      • En la carpeta %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover , busque una entrada de detección automática que tenga el código 401 Unauthorized de estado HTTP y contenga el texto "ASAutoDiscover/CrossForest/EmailDomain".

        Nota: Si el TargetSharingEpr parámetro de la relación de la organización especifica una dirección URL externa de EWS local, se omite la detección automática y esta entrada no aparecerá.

      • En la carpeta %ExchangeInstallPath%\Logging\HttpProxy\Ews , busque una entrada de EWS que tenga el código 401 Unauthorized de estado HTTP y contenga el texto "ASProxy/CrossForest/EmailDomain".

      Nota: Las marcas de tiempo de los registros de IIS usan la hora UTC. Algunas entradas que tienen el código 401 Unauthorized de estado HTTP son normales.

      Las entradas especificadas indican que la solicitud de disponibilidad alcanzó IIS y normalmente descarta problemas de autenticación previa. Si no encuentra las entradas especificadas, compruebe los registros de proxy inverso y firewall para comprender dónde se ha bloqueado la solicitud de disponibilidad.

2. Asegúrese de que ha habilitado WSSecurity (Exchange Server 2010) o la autenticación de OAuth (Exchange Server 2013 y versiones posteriores) en los directorios virtuales EWS y Detección automática. Además, compruebe que ha habilitado la configuración de autenticación predeterminada en IIS para los directorios virtuales Detección automática y EWS. Para obtener más información, vea Configuración de autenticación predeterminada para directorios virtuales de Exchange y Configuración predeterminada para directorios virtuales de Exchange.

3. Siga los pasos de resolución de Un error al comprobar la seguridad del mensaje. Si WSSecurity está configurado, asegúrese de realizar el paso que alterna WSSecurity. Si la autenticación de OAuth está configurada en lugar de WSSecurity, alterne la autenticación de OAuth en los directorios virtuales Detección automática y EWS mediante la ejecución de los siguientes comandos:

   Set-WebServicesVirtualDirectory "<ServerName>\ews (Exchange Back End)" -OAuthAuthentication:$False
   Set-WebServicesVirtualDirectory "<ServerName>\ews (Exchange Back End)" -OAuthAuthentication:$True 
   Set-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Exchange Back End)" -OAuthAuthentication:$False 
   Set-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Exchange Back End)" -OAuthAuthentication:$True 
   

4. Compruebe que tiene una confianza de federación actualizada. Ejecute el siguiente comando en Exchange Online PowerShell para recuperar la información de confianza de federación de su organización de Exchange:

   Get-FederationTrust
   

   La salida del comando debe contener la siguiente información:

   Nombre	ApplicationIdentifier	ApplicationUri
   WindowsLiveId	260563	outlook.com
   MicrosoftOnline	260563	outlook.com

   Nota: La WindowsLiveId confianza es una instancia de consumidor de La puerta de enlace de federación de Microsoft. La MicrosoftOnline confianza es una instancia empresarial de la puerta de enlace de federación de Microsoft.

   Para obtener una confianza de federación actualizada, asegúrese de que ApplicationIdentifier es y no 292841, y de que ApplicationUri es outlook.com y no outlook.live.com260563 . Si tiene una confianza de federación obsoleta, póngase en contacto con el soporte técnico de Microsoft.

Volver al principio

Error de detección automática de la dirección de correo electrónico: InvalidUser

LID: 33676

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error en la respuesta del servicio de detección automática en "https://Autodiscover/Autodiscover.svc/WSSecurity" debido a un error en la configuración del usuario "ExternalEwsUrl". Mensaje de error: InvalidUser.

El mensaje de error podría aparecer al ejecutar la prueba de disponibilidad en el Analizador de conectividad remota.

Este error puede producirse si el buzón de nube o el punto de conexión de detección automática están mal configurados.

Pasos para la solución de problemas

1. Compruebe que el usuario en la nube tiene una dirección SMTP secundaria que incluye el onmicrosoft.com dominio mediante la ejecución del siguiente comando:

   Get-Mailbox -Identity <mailbox ID> | FL EmailAddresses
   

   Por ejemplo, un usuario que tenga la dirección user1@contoso.com SMTP principal debe tener una dirección SMTP secundaria similar a user1@contoso.mail.onmicrosoft.com.

   Si el usuario en la nube se administra desde Exchange Server, agregue la dirección SMTP secundaria a Exchange Server y, a continuación, sincronice los datos de identidad entre el entorno local y el identificador de Microsoft Entra.

2. Ejecute los comandos siguientes para establecer el valor del TargetSharingEpr parámetro en la relación de la organización con la dirección URL de Exchange Web Services (EWS) externa local:

   Connect-ExchangeOnline
   Set-OrganizationRelationship "O365 to On-premises*" -TargetSharingEpr <on-premises EWS external URL>
   

   Después de establecer el valor del TargetSharingEpr parámetro, el buzón de nube omite la detección automática y se conecta directamente al punto de conexión de EWS del buzón local.

Volver al principio

El autor de la llamada no tiene acceso a los datos de disponibilidad

LID: 47652, 44348, 40764

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local o viceversa. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException: el autor de la llamada no tiene acceso a los datos de disponibilidad.

Este error puede producirse si el buzón del usuario cuya información de disponibilidad se solicita está mal configurado.

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Compruebe los permisos de calendario del usuario cuya información de disponibilidad se solicita mediante la ejecución del siguiente comando:

   Get-MailboxFolderPermission -Identity <mailbox ID>:\Calendar
   

   El AccessRights valor del Default usuario en la salida del comando debe ser AvailabilityOnly o LimitedDetails. Si el AccessRights valor es None, ejecute el siguiente cmdlet de PowerShell para establecer ese valor en AvailabilityOnly o LimitedDetails:

   Set-MailboxFolderPermission -Identity <mailbox ID>:\Calendar -AccessRights <access rights value>
   

2. Use el método aplicable para comprobar la relación de la organización:

   • Si un usuario en la nube no puede ver la información de disponibilidad de un usuario local:

     Compruebe que la relación de organización local especifica el dominio en la nube que puede acceder a la información de disponibilidad local. Un dominio en la nube de ejemplo es contoso.mail.onmicrosoft.com. Para obtener información sobre cómo modificar la relación de la organización en Exchange Server, consulte Uso de PowerShell para modificar la relación de la organización. Compruebe también que la dirección de correo electrónico desde del usuario en la nube tiene el mismo dominio en la nube, por ejemplo lucine.homsi@contoso.mail.onmicrosoft.com.

   • Si un usuario local no puede ver la información de disponibilidad de un usuario en la nube:

     Compruebe que la relación de la organización en la nube especifica el dominio local que puede acceder a la información de disponibilidad en la nube. Un dominio local de ejemplo es contoso.com. Para obtener información sobre cómo modificar la relación de la organización en Exchange Online, consulte Uso de Exchange Online PowerShell para modificar la relación de la organización. Compruebe también que la dirección de correo electrónico desde del usuario local tiene el mismo dominio local, por ejemplo lucine.homsi@contoso.com.

Volver al principio

Error al procesar los tokens de seguridad en el mensaje

LID: 59916

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error De ProxyWebRequestProcessingExceptionProxyRequestProcessingFailed
Error en la solicitud web de proxy. , excepción interna: error al procesar los tokens de seguridad en el mensaje.

Este error puede producirse si los certificados o metadatos de la puerta de enlace de federación de Microsoft no son válidos.

Pasos para la solución de problemas

1. Compruebe la fecha de expiración y las huellas digitales de los certificados de confianza de federación locales mediante la ejecución de los siguientes cmdlets de PowerShell:

   Get-FederationTrust | FL
   Test-FederationTrust
   Test-FederationTrustCertificate
   

2. Para actualizar los metadatos en la puerta de enlace de federación de Microsoft, ejecute el siguiente comando dos veces en el Shell de administración de Exchange (EMS) local:

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Para obtener más información, consulte Búsquedas de disponibilidad que dejan de funcionar.

Volver al principio

No se permite la solicitud entre organizaciones porque el solicitante es de una organización diferente.

LID: 39660

Incidencia

Tiene un escenario de malla híbrida en el que un usuario en la nube de un inquilino de Exchange Online no híbrido no puede ver la información de disponibilidad de un usuario en la nube en otro inquilino de Exchange Online que pasa a ser híbrido. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

No se permite la solicitud entre organizaciones para la dirección> SMTP del buzón <porque el solicitante es de otra organización.
Destinatario: <dirección SMTP>
Tipo de excepción: CrossOrganizationProxyNotAllowedForExternalOrganization
Mensaje de excepción: no se permite la solicitud entre organizaciones para <la dirección> SMTP porque el solicitante es de una organización diferente.

Por ejemplo, un usuario lucine@adatum.com de un inquilino de Exchange Online no híbrido no puede ver la disponibilidad de un usuario chanok@contoso.com en la nube en un inquilino híbrido. El usuario en chanok@contoso.com la nube tiene una dirección chanok@contoso.mail.onmicrosoft.comde correo electrónico proxy. El inquilino no híbrido tiene dos relaciones de organización: contoso.com (local) y contoso.mail.onmicrosoft.com (nube). Detección automática de contoso.com puntos a Exchange Server y Detección automática de contoso.mail.onmicrosoft.com puntos en Exchange Online. El usuario del inquilino no híbrido recibe el mensaje de error al consultar la información de disponibilidad de chanok@contoso.com, porque la detección automática de contoso.com puntos no apunta a Exchange Online.

Nota:

Para ver el escenario de malla híbrida local equivalente, consulte Malla híbrida.

Solución alternativa

Para solucionar este problema, su organización puede usar uno de los métodos siguientes:

• Los usuarios del inquilino de Exchange Online no híbrido deben consultar la disponibilidad de un usuario en la nube en un inquilino híbrido mediante la dirección de correo electrónico para la que detección automática apunta a Exchange Online. Por ejemplo, lucine@adatum.com consulta la información de disponibilidad para chanok@contoso.mail.onmicrosoft.com. Para consultar correctamente la información de disponibilidad, los usuarios del inquilino de Exchange Online no híbrido deben saber qué usuarios del inquilino híbrido se hospedan en la nube y, para cada uno de esos usuarios, la dirección de correo electrónico para la que detección automática apunta a Exchange Online.

• Un administrador del inquilino de Exchange Online no híbrido debe establecer la dirección de correo electrónico externa de cada usuario en la nube del inquilino híbrido en la dirección de correo electrónico para la que La detección automática apunta a Exchange Online. Por ejemplo, un administrador del inquilino de Exchange Online no híbrido establece la dirección de correo electrónico de destino del chanok@contoso.com inquilino chanok@contoso.mail.onmicrosoft.comhíbrido en . Para realizar este cambio, el administrador debe saber qué usuarios del inquilino híbrido están hospedados en la nube y, para cada uno de ellos, la dirección de correo electrónico para la que detección automática apunta a Exchange Online. Para obtener más información sobre la sincronización entre inquilinos de direcciones de correo electrónico de usuario, consulte ¿Qué es la sincronización entre inquilinos?

Más información

Un usuario podría encontrar un problema similar en el escenario siguiente:

• El usuario está en un inquilino de Exchange Server no híbrido.
• El usuario intenta ver la disponibilidad de un usuario local en un inquilino híbrido.
• La detección automática del inquilino híbrido apunta a Exchange Online.

Por ejemplo, un usuario de un inquilino de Exchange Server no híbrido no puede ver la información de disponibilidad del usuario chanok@contoso.com local en un inquilino híbrido porque detección automática de contoso.com puntos a Exchange Online (autodiscover-s.outlook.com).

Volver al principio

Error en la solicitud con el estado HTTP 401: No autorizado (falta el certificado de firma)

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

System.Net.WebException: se produjo un error en la solicitud con el estado HTTP 401: No autorizado.

Si ejecuta el cmdlet Test-OAuthConnectivity , verá el siguiente mensaje de error en la salida del comando:

Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException: falta el certificado de firma.

Por ejemplo, ejecute el comando siguiente:

Test-OAuthConnectivity -Service AutoD -TargetUri <on-premises Autodiscover URL> -Mailbox <mailbox ID> -Verbose | FL

El TargetUri valor del parámetro es la dirección URL del servicio de detección automática local. Un ejemplo de esa dirección URL es https://mail.contoso.com/Autodiscover/Autodiscover.svc.

Este error puede producirse si la configuración de autenticación tiene un certificado OAuth no válido.

Solución

Para resolver el problema, siga estos pasos:

1. Ejecute el siguiente cmdlet de PowerShell en el Shell de administración de Exchange (EMS) para obtener la huella digital del certificado de OAuth que usa la configuración de autenticación:

   Get-AuthConfig | FL CurrentCertificateThumbprint
   

   Si la salida del comando no devuelve una huella digital del certificado, vaya al paso 3. De lo contrario, continúe con el paso siguiente.

2. Ejecute el siguiente cmdlet de PowerShell para comprobar si el certificado identificado en el paso 1 existe en Exchange Server:

   Get-ExchangeCertificate -Thumbprint (Get-AuthConfig).CurrentCertificateThumbprint | FL
   

   Si Exchange Server no devuelve ningún certificado, vaya al paso 3 para crear un nuevo certificado.

   Si Exchange Server devuelve un certificado, pero su huella digital difiere de la huella digital que obtuvo en el paso 1, vaya al paso 4. En el paso 4, especifique la huella digital del certificado devuelto por Exchange Server.

3. Ejecute el siguiente cmdlet de PowerShell para crear un nuevo certificado de OAuth:

   New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "CN=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName <Domain> -Services SMTP
   

   Nota:

   Si se le pide que reemplace el certificado SMTP, no acepte el mensaje.

   En el paso 4, especifique la huella digital del nuevo certificado que creó en este paso.

4. Ejecute los siguientes cmdlets de PowerShell para actualizar la configuración de autenticación para usar el certificado especificado:

   $date=Get-Date 
   Set-AuthConfig -NewCertificateThumbprint <certificate thumbprint> -NewCertificateEffectiveDate $date
   Set-AuthConfig -PublishCertificate
   

   Nota:

   Si se le advierte de que la fecha de vigencia es inferior a 48 horas a partir de ahora, elija continuar.

5. Ejecute el siguiente cmdlet de PowerShell para quitar las referencias al certificado anterior:

   Set-AuthConfig -ClearPreviousCertificate
   

Volver al principio

A la aplicación le falta una cuenta vinculada para los roles de RBAC, o la cuenta vinculada no tiene asignaciones de roles de RBAC o la cuenta de usuarios que realiza la llamada está deshabilitada.

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

System.Web.Services.Protocols.SoapException: a la aplicación le falta una cuenta vinculada para los roles RBAC, o la cuenta vinculada no tiene asignaciones de roles de RBAC o la cuenta de usuarios que realiza la llamada está deshabilitada.

Pasos para la solución de problemas

Para solucionar los problemas que se mencionan en el mensaje de error, siga estos pasos. Después de completar los pasos 1 y 2, compruebe si se ha corregido el problema de disponibilidad.

1. Asegúrese de que la entrada "Exchange Online-ApplicationAccount" existe en la lista de aplicaciones asociadas de Exchange Server. Para comprobarlo, ejecute el siguiente cmdlet de PowerShell en la Consola de administración de Exchange (EMS):

   Get-PartnerApplication | FL LinkedAccount
   

   La entrada de cuenta debe aparecer como <root domain FQDN>/Users/Exchange Online-ApplicationAccount. Si la entrada aparece en la lista, vaya al paso 2.

   Si la entrada de cuenta no aparece en la lista, agregue la cuenta siguiendo estos pasos:

   1. Ejecute los siguientes cmdlets de PowerShell para buscar la cuenta en Active Directory local:

      Set-ADServerSettings -ViewEntireForest $true 
      Get-User "Exchange Online-ApplicationAccount" 
      

      Si la cuenta aparece en Active Directory, vaya al paso 1b.

      Si la cuenta no aparece en Active Directory, es posible que se haya eliminado. Use ADRestore para comprobar el estado de la cuenta y restaurarlo, si se elimina. Si ha restaurado la cuenta mediante ADRestore, vaya al paso 1b.

      Si no puede restaurar la cuenta mediante ADRestore, siga el procedimiento que se describe en Active Directory y dominios para Exchange Server. Si ese procedimiento no restaura la cuenta, cree manualmente la cuenta en Active Directory y, a continuación, continúe con el paso 1b.

   2. Ejecute el siguiente cmdlet de PowerShell para agregar la cuenta de Active Directory a la lista de aplicaciones asociadas de Exchange Server:

      Set-PartnerApplication "Exchange Online" -LinkedAccount "<root domain FQDN>/Users/Exchange Online-ApplicationAccount"
      

   3. Reinicie todos los servidores de Exchange locales o reinicie IIS ejecutando el iisreset /noforce comando en una ventana de PowerShell o símbolo del sistema en cada servidor.

2. Ejecute el siguiente cmdlet de PowerShell en EMS para comprobar las asignaciones de control de acceso basado en rol (RBAC):

   Get-ManagementRoleAssignment -RoleAssignee "Exchange Online-ApplicationAccount" | FL Name,Role
   

   Por ejemplo, la salida del comando podría enumerar las siguientes asignaciones de roles:

   

3. Busque en los registros siguientes los problemas que se indican en el mensaje de error:

   • Registros de Exchange Web Services (EWS) que se encuentran en la carpeta %ExchangeInstallPath%\Logging\Ews
   • Registros de eventos de la aplicación
   • Registros de eventos del sistema

4. Busque en los registros que aparecen en el paso 3 un mensaje de error que haga referencia a AuthzInitializeContextFromSid. Si encuentra ese mensaje de error, consulte los siguientes recursos:

   • Algunas aplicaciones y API requieren acceso a la información de autorización en objetos de cuenta

   • Error en las comprobaciones de acceso debido a AuthZ

Volver al principio

Las contraseñas especificadas y almacenadas no coinciden

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Excepción de error soap recibida. Las contraseñas especificadas y almacenadas no coinciden.

Verá el mismo mensaje de error al ejecutar el siguiente cmdlet para comprobar si el usuario en la nube puede recuperar un token de delegación para el buzón de usuario local:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

Causa

Existe una incoherencia en las credenciales de Azure para usuarios en la nube específicos.

Solución

Para resolver el problema, siga estos pasos:

1. Restablezca la contraseña del usuario en la nube. Elija la misma contraseña o una contraseña diferente.

2. Actualice el nombre principal de usuario (UPN) del usuario en la nube para usar el onmicrosoft.com dominio y, a continuación, revierta el UPN a su valor anterior. Por ejemplo, si el UPN del usuario en la nube es user@contoso.com, cámbielo al UPN temporal y, a continuación, user@contoso.mail.onmicrosoft.comrevierta el UPN a user@contoso.com. Para ello, use PowerShell de Azure AD o el servicio MSOL.

   • Usar Azure AD PowerShell

     Ejecute los siguientes cmdlets de PowerShell:

     Connect-AzureAD
     Set-AzureADUser -ObjectID <original UPN> -UserPrincipalName <temporary UPN>
     Set-AzureADUser -ObjectID <temporary UPN> -UserPrincipalName <original UPN>
     

   • Uso del servicio MSOL

     Ejecute los siguientes cmdlets de PowerShell:

     Connect-MsolService
     Set-MsolUserPrincipalName -UserPrincipalName <original UPN> -NewUserPrincipalName <temporary UPN>
     Set-MsolUserPrincipalName -UserPrincipalName <temporary UPN> -NewUserPrincipalName <original UPN>
     

3. Asegúrese de que el ImmutableId valor del objeto de usuario local sea NULL. Compruebe el ImmutableId valor del objeto de usuario local ejecutando el siguiente comando en el Shell de administración de Exchange (EMS):

   Get-RemoteMailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
   

   Use uno de los métodos siguientes, en función del ImmutableId valor.

   • El valor de ImmutableId es null

     Si el ImmutableId valor es null, cambie su valor:

     1. Establezca el ImmutableId objeto de buzón remoto en el UPN del usuario en la nube mediante la ejecución del siguiente cmdlet de PowerShell en EMS:

        Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId <UPN>
        

        Por ejemplo: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

     2. Sincronice el cambio en la nube mediante la ejecución de los siguientes cmdlets de PowerShell en EMS:

        Import-Module ADSync
        Start-ADSyncSyncCycle -PolicyType Delta
        

        Para comprobar que el ImmutableId valor se ha actualizado, ejecute el siguiente cmdlet de PowerShell en Exchange Online PowerShell:

        Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
        

     3. Revierta el ImmutableId objeto de buzón remoto a null mediante la ejecución del siguiente cmdlet de PowerShell en EMS:

        Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId $null
        

     4. Sincronice el cambio en la nube mediante la ejecución del siguiente cmdlet de PowerShell en EMS:

        Start-ADSyncSyncCycle -PolicyType Delta
        

        Para comprobar que el ImmutableId valor se ha actualizado, ejecute el siguiente cmdlet de PowerShell en Exchange Online PowerShell:

        Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
        

   • El valor de ImmutableId no es NULL

     Si el ImmutableId valor no es NULL, ejecute el siguiente comando en EMS para establecer el ImmutableId valor en null:

     Set-RemoteMailbox -Identity <user> -ImmutableId $null
     

     Para comprobar que el ImmutableId valor se ha actualizado, ejecute el siguiente cmdlet de PowerShell en Exchange Online PowerShell:

     Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
     

Volver al principio

La contraseña debe cambiarse o la contraseña de la cuenta ha expirado.

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará uno de los siguientes mensajes de error.

Mensaje de error 1

La contraseña de la cuenta ha expirado

Mensaje de error 2

La contraseña tiene que cambiarse

Verá el mismo mensaje de error al ejecutar el siguiente cmdlet para comprobar si el usuario en la nube puede recuperar un token de delegación para el buzón de usuario local:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

Este error puede producirse si existe una incoherencia en las credenciales de Azure para usuarios en la nube específicos.

Solución

Seleccione la resolución que coincida con el mensaje de error.

Resolución del mensaje de error 1

Para solucionar el problema, use PowerShell de Azure AD o el servicio MSOL.

• Usar Azure AD PowerShell

  Ejecute los siguientes cmdlets de PowerShell:

  Connect-AzureAD
  Set-AzureADUser -ObjectId <account UPN> -PasswordPolicies DisablePasswordExpiration
  

• Uso del servicio MSOL

  Ejecute los siguientes cmdlets de PowerShell:

  Connect-MsolService
  Set-MsolUser -UserPrincipalName <account UPN> -PasswordNeverExpires $true
  

Resolución del mensaje de error 2

Para solucionar el problema, ejecute los siguientes cmdlets de PowerShell:

Connect-MsolService
Set-MsolUserPassword -UserPrincipalName <UPN> -ForceChangePassword $false

Para obtener más información, consulte No se puede ver la información de disponibilidad después de migrar desde Exchange local.

Volver al principio

El aprovisionamiento es necesario para poder iniciar sesión en la cuenta federada

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

El aprovisionamiento es necesario para poder iniciar sesión en la cuenta federada. ErrorWin32InteropError

También recibirá el mismo mensaje de error al ejecutar el siguiente cmdlet para comprobar si el usuario en la nube puede recuperar un token de delegación para el buzón de usuario local:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

Este error puede producirse si hay una incoherencia en la configuración de los usuarios federados en Microsoft Entra ID.

Solución

Nota:

Si el problema afecta a la mayoría o a todos los usuarios en la nube de su organización, póngase en contacto con el soporte técnico de Microsoft.

Para corregir el problema, actualice el nombre principal de usuario (UPN) del usuario en la nube para que use el onmicrosoft.com dominio y vuelva a cambiarlo a su valor anterior (dominio federado). Por ejemplo, si el UPN del usuario en la nube es user@contoso.com, cambie al UPN user@contoso.mail.onmicrosoft.com temporal y vuelva a user@contoso.com. Para ello, use cualquiera de los siguientes enfoques (Azure AD PowerShell o el servicio MSOL):

• Usar Azure AD PowerShell

  Ejecute los siguientes cmdlets de PowerShell:

  Connect-AzureAD
  Set-AzureADUser -ObjectID <original UPN> -UserPrincipalName <temporary UPN>
  Set-AzureADUser -ObjectID <temporary UPN> -UserPrincipalName <original UPN>
  

• Uso del servicio MSOL

  Ejecute los siguientes cmdlets de PowerShell:

  Connect-MsolService
  Set-MsolUserPrincipalName -UserPrincipalName <original UPN> -NewUserPrincipalName <temporary UPN>
  Set-MsolUserPrincipalName -UserPrincipalName <temporary UPN> -NewUserPrincipalName <original UPN>
  

Volver al principio

Tiempo de espera de la solicitud

LID: 43404

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Tiempo de espera de la solicitud
No se pudo procesar la solicitud a tiempo. El tiempo de espera se produjo durante "Waiting-For-Request-Completion".
Microsoft.Exchange.InfoWorker.Common.Availability.TimeoutExpiredException: La solicitud no se pudo procesar a tiempo. El tiempo de espera se produjo durante "Waiting-For-Request-Completion".
Nombre del servidor donde se originó la excepción: <nombre> del servidor.

También recibirá el mismo mensaje de error si ejecuta el siguiente cmdlet para comprobar si el usuario en la nube puede recuperar un token de delegación para el buzón de usuario local:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

Este error puede producirse si hay problemas de red o transitorios. El mensaje de error es genérico.

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Para descartar problemas transitorios, compruebe que el usuario en la nube obtiene de forma coherente el mismo mensaje de error durante los intentos repetidos de obtener la información de disponibilidad del usuario local.

2. Compruebe si puede recuperar un token de delegación al ejecutar cada uno de los siguientes cmdlets:

   Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose
   Test-FederationTrust -UserIdentity <on-premises mailbox ID> -Verbose
   Test-FederationTrustCertificate
   

   Nota: Ejecute el cmdlet Test-FederationTrust en todos los servidores de Exchange locales.

3. Compruebe que Exchange Server tiene acceso saliente a Internet a los dos recursos siguientes:

   • Puerta de enlace de federación de Microsoft (o un servidor de autorización, si usa OAuth)

   • Dirección URL de disponibilidad de Microsoft 365: https://outlook.office365.com/ews/exchange.asmx

   Para obtener más información, consulte Direcciones URL y intervalos de direcciones IP de Microsoft 365 y Consideraciones de firewall para la delegación federada.

4. Asegúrese de que la cuenta del sistema de Exchange Server tiene acceso a Internet a las siguientes direcciones URL. Siga estos pasos en cada servidor exchange:

   1. Ejecute el siguiente comando psexec para iniciar una sesión de PowerShell que inicie un explorador web desde la cuenta del sistema:

      PsExec.exe -i -s "C:\Program Files\Internet Explorer\iexplore.exe"
      

   2. Pruebe el acceso al explorador (sin OAuth) desde la cuenta del sistema a las siguientes direcciones URL de Puerta de enlace de federación de Microsoft:

      • https://nexus.microsoftonline-p.com/federationmetadata/2006-12/federationmetadata.xml

        El explorador debe mostrar una página xml.

      • https://login.microsoftonline.com/extSTS.srf

        El explorador debe solicitarle que descargue el archivo.

      • https://domains.live.com/service/managedelegation2.asmx

        El explorador debe mostrar una lista de operaciones compatibles con ManageDelegation2.

   3. Pruebe el acceso al explorador (OAuth) desde la cuenta del sistema a las siguientes direcciones URL del servidor de autorización de Microsoft:

      • https://outlook.office365.com/ews/exchange.asmx

        El explorador debe mostrar un símbolo del sistema de inicio de sesión.

      • https://login.windows.net/common/oauth2/authorize

        El explorador debe mostrar el error de inicio de sesión, "Lo sentimos, pero tenemos problemas para iniciar sesión".

      • https://accounts.accesscontrol.windows.net/<tenant guid>/tokens/OAuth/2

        El explorador debe mostrar el código 400 Bad Requestde estado HTTP o el mensaje de error de inicio de sesión, "Lo sentimos, pero tenemos problemas para iniciar sesión".

5. Obtenga los detalles de una solicitud de disponibilidad comprobando los registros de Servicios web de Exchange (EWS):

   1. Realice una solicitud de disponibilidad de Exchange Online.

   2. Busque la entrada en los registros de EWS y compruebe el valor de la time-taken columna. Los registros de EWS se encuentran en la carpeta %ExchangeInstallPath%\Logging\Ews .

   3. Compruebe los registros de IIS en la carpeta W3SVC1 del sitio web predeterminado para comprobar que se ha registrado la solicitud de disponibilidad. La ruta de acceso de la carpeta W3SVC1 es %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

Volver al principio

El nombre de miembro especificado no es válido o está vacío.

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

S:Fault xmlns:S="http://www.w3.org/2003/05/soap-envelope"><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value>wst:FailedAuthentication</S:Value></S:Subcode></S:Code><S:Reason><S:Text xml:lang="en-US">Authentication Failure</S:Text></S:Reason><S:Detail><psf:error xmlns:psf="http://schemas.microsoft.com/Passport/SoapServices/SOAPFault"><psf:value>0x80048821</psf:value><psf:internalerror><psf:code>0x80041034</psf:code><psf:text>El nombre de miembro especificado no es válido o está vacío. </psf:text></psf:internalerror></psf:error></S:Detail></S:Fault> Microsoft.Exchange.Net.WSTrust.SoapFaultException: excepción de error soap recibida. at Microsoft.Exchange.Net.WSTrust.SecurityTokenService.EndIssueToken(IAsyncResult asyncResult) at Microsoft.Exchange.InfoWorker.Common.Availability.ExternalAuthenticationRequest.Complete(IAsyncResult asyncResult)

El error puede producirse por cualquiera de los siguientes motivos:

• Incoherencia en el identificador de Microsoft Entra para los usuarios que solicitan un token de delegación
• Incoherencia en la configuración de usuarios federados en Servicios de federación de Active Directory (AD FS)

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Actualice el nombre principal de usuario (UPN) del usuario en la nube para usar el onmicrosoft.com dominio y, a continuación, revierta el UPN a su valor anterior. Por ejemplo, si el UPN del usuario en la nube es user@contoso.com, cámbielo al UPN temporal y, a continuación, user@contoso.mail.onmicrosoft.comrevierta el UPN a user@contoso.com. Para ello, use cualquiera de los métodos siguientes (Azure AD PowerShell o el servicio MSOL):

   • Usar Azure AD PowerShell

     Ejecute los siguientes cmdlets de PowerShell:

     Connect-AzureAD
     Set-AzureADUser -ObjectID <original UPN> -UserPrincipalName <temporary UPN>
     Set-AzureADUser -ObjectID <temporary UPN> -UserPrincipalName <original UPN>
     

   • Uso del servicio MSOL

     Ejecute los siguientes cmdlets de PowerShell:

     Connect-MsolService
     Set-MsolUserPrincipalName -UserPrincipalName <original UPN> -NewUserPrincipalName <temporary UPN>
     Set-MsolUserPrincipalName -UserPrincipalName <temporary UPN> -NewUserPrincipalName <original UPN>
     

2. Compruebe las reglas, los puntos de conexión y los registros de AD FS.

3. Busque un error relacionado con el ImmutableID del usuario en la nube en la salida del comando del siguiente cmdlet de PowerShell:

   Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud user ID> -Verbose
   

   Por ejemplo, la salida del comando podría contener el siguiente mensaje de error:

   "La dirección de correo electrónico "XGuNpVunD0afQeVNfyoUIQ==" no es correcta. Use este formato: nombre de usuario, signo @ seguido del nombre de dominio. Por ejemplo, tonysmith@contoso.com o tony.smith@contoso.com.
   + CategoryInfo : NotSpecified: (:) [Test-OrganizationRelationship], FormatException"

   Si recibe un mensaje de error similar, use uno de los métodos siguientes para asegurarse de que el ImmutableId valor es null (valor vacío):

   • Si el usuario en la nube no está sincronizado desde el entorno local, compruebe el ImmutableId valor ejecutando el siguiente cmdlet de PowerShell en Exchange Online PowerShell:

     Get-Mailbox -Identity <cloud mailbox> | FL ImmutableId
     

     Si el ImmutableId valor no es NULL, ejecute el siguiente cmdlet de PowerShell en Exchange Online PowerShell:

     Set-Mailbox -Identity <cloud mailbox> -ImmutableId $null
     

   • Si el usuario en la nube se sincroniza desde el entorno local, compruebe el ImmutableId valor del objeto de usuario local mediante la ejecución del siguiente comando en el Shell de administración de Exchange (EMS):

     Get-RemoteMailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
     

     Use cualquiera de los métodos siguientes, en función del ImmutableId valor:

     • El valor de ImmutableId es null

       Si el ImmutableId valor es null, cambie su valor:

       1. Establezca el ImmutableId objeto de buzón remoto en el UPN del usuario en la nube mediante la ejecución del siguiente cmdlet de PowerShell en EMS:

          Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId <UPN>
          

          Por ejemplo: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

       2. Sincronice el cambio en la nube mediante la ejecución de los siguientes cmdlets de PowerShell en EMS:

          Import-Module ADSync
          Start-ADSyncSyncCycle -PolicyType Delta
          

          Para comprobar que el ImmutableId valor se actualizó, ejecute el siguiente cmdlet de PowerShell en Exchange Online PowerShell:

          Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
          

       3. Revierta el ImmutableId objeto de buzón remoto a null mediante la ejecución del siguiente cmdlet de PowerShell en EMS:

          Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId $null
          

       4. Sincronice el cambio en la nube mediante la ejecución del siguiente cmdlet de PowerShell en EMS:

          Start-ADSyncSyncCycle -PolicyType Delta
          

          Compruebe que el ImmutableId valor se actualizó. Para ello, ejecute el siguiente cmdlet de PowerShell en Exchange Online PowerShell:

          Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
          

     • El valor de ImmutableId no es NULL

       Si el ImmutableId valor no es NULL, ejecute el siguiente comando en EMS para establecer el ImmutableId valor en null:

       Set-RemoteMailbox -Identity <user> -ImmutableId $null
       

       Para comprobar que el ImmutableId valor se actualizó, ejecute el siguiente cmdlet de PowerShell en Exchange Online PowerShell:

       Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
       

4. Compruebe la configuración de la relación de la organización. Para obtener más información, vea Desmitificar la disponibilidad híbrida.

5. Si el mensaje de error se genera para un usuario en la nube que no puede ver la información de disponibilidad de un usuario local, siga estos pasos:

   1. Ejecute el siguiente cmdlet de PowerShell:

      Test-FederationTrust -UserIdentity <on-premises user> -Verbose -Debug
      

   2. Vuelva a crear la confianza de federación. Para obtener más información, vea Quitar una confianza de federación y Configurar una confianza de federación.

Volver al principio

El conjunto de resultados contiene demasiadas entradas de calendario

LID: 54796

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de otro usuario en la nube. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Excepción: el conjunto de resultados contiene demasiadas entradas de calendario. Tamaño permitido = 1000; tamaño real = 5009.

Este error se produce si el número de entradas de calendario en un único intervalo de tiempo supera los 1000 elementos. Una única solicitud de disponibilidad no puede recuperar más de 1000 elementos.

Solución

Quite algunos de los elementos de calendario del intervalo de tiempo para no superar el límite de 1000 elementos que se pueden recuperar en una única solicitud de disponibilidad.

Para obtener más información, consulte No se puede ver información de disponibilidad en el calendario de otro usuario en Exchange Online.

Volver al principio

La hora de inicio de las horas de trabajo debe ser menor o igual que la hora de finalización

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de una lista de salas. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Excepción: Microsoft.Exchange.InfoWorker.Common.InvalidParameterException: La hora de inicio del horario laboral debe ser menor o igual que la hora de finalización.
Microsoft.Exchange.InfoWorker.Common.MeetingSuggestions.AttendeeWorkHours.Validate(TimeSpan startTime, TimeSpan endTime).

Este error puede producirse si una o varias de las siguientes configuraciones de calendario para un buzón de sala de una lista de salas no son válidas:

• WorkingHoursStartTime
• WorkingHoursEndTime
• WorkingHoursTimeZone

La hora de inicio de las horas de trabajo debe ser menor o igual que la hora de finalización de las horas de trabajo y se debe establecer la zona horaria del horario laboral.

Solución

Para resolver el problema, siga estos pasos:

1. Ejecute el siguiente cmdlet de PowerShell para comprobar la configuración del calendario de cada buzón de la lista de salas para identificar el buzón de sala que tiene una configuración no válida:

   Get-DistributionGroupMember -Identity <room list name> | Get-MailboxCalendarConfiguration | FL Identity,WorkingHours* 
   

2. Ejecute el siguiente cmdlet de PowerShell para establecer los valores de parámetro necesarios para un buzón de sala:

   Set-MailboxCalendarConfiguration -Identity <room ID> -WorkingHoursStartTime <start time> -WorkingHoursEndTime <end time> -WorkingHoursTimeZone <time zone>
   

   Para obtener más información, vea Set-MailboxCalendarConfiguration.

Volver al principio

Error en la solicitud con el estado HTTP 401: No autorizado (el token tiene una firma no válida)

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

System.Net.WebException: se produjo un error en la solicitud con el estado HTTP 401: No autorizado.

Al ejecutar el siguiente cmdlet de PowerShell para probar la autenticación de OAuth:

Test-OAuthConnectivity -Service EWS -TargetUri <external EWS URL> -Mailbox <cloud mailbox ID> -Verbose | FL

Recibirá la siguiente salida de comando:

System.Net.WebException: The remote server returned an error: (401) Unauthorized. Boolean reloadConfig, diagnostics: 2000000; reason="The token has an invalid signature.";error_category="invalid_signature".

Nota: El valor del TargetUri parámetro del comando Test-OAuthConnectivity es una dirección URL externa de Exchange Web Services (EWS), como https://mail.contoso.com/ews/exchange.asmx.

Este error puede producirse si la configuración del servidor de autorización de Microsoft no es válida.

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Actualice los metadatos de autorización en el servidor de autorización de Microsoft especificado de confianza para Exchange. Ejecute el siguiente cmdlet de PowerShell en EMS (local):

   Set-AuthServer <name of the authorization server> -RefreshAuthMetadata 
   

   Espere unos 15 minutos para que el comando surta efecto o reinicie IIS ejecutando el iisreset /noforce comando en una ventana de PowerShell o símbolo del sistema en cada servidor de Exchange.

2. Compruebe la configuración del servidor de autorización de Microsoft en su organización de Exchange ejecutando el siguiente cmdlet de PowerShell en EMS:

   Get-AuthServer | FL Name, IssuerIdentifier, TokenIssuingEndpoint, AuthMetadataUrl, Enabled
   

   La salida del comando siguiente es un ejemplo de configuración válida:

   Name : WindowsAzureACS
   IssuerIdentifier : 00000001-0000-0000-c000-000000000000
   TokenIssuingEndpoint : https://accounts.accesscontrol.windows.net/XXXXXXXX-5045-4d00-a59a-c7896ef052a1/tokens/OAuth/2
   AuthMetadataUrl : https://accounts.accesscontrol.windows.net/contoso.com/metadata/json/1
   Enabled : True
   

   Si la configuración del servidor de autorización de Microsoft no es válida, intente volver a ejecutar el Asistente para configuración híbrida para restablecer la configuración del servidor de autorización de Microsoft a valores válidos.

Volver al principio

Error en la solicitud con el estado HTTP 401: No autorizado (no se encontró la clave)

Incidencia

Tiene un usuario local que no puede ver la información de disponibilidad de un usuario en la nube. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

System.Net.WebException: se produjo un error en la solicitud con el estado HTTP 401: No autorizado.

Al ejecutar el siguiente cmdlet de PowerShell en EMS para probar la autenticación de OAuth:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox <on-premises mailbox ID> -Verbose | FL

Recibirá la siguiente salida de comando:

System.Net.WebException: el servidor remoto devolvió un error: (401) Unauthorized.
Error: No se puede obtener el token del servidor de autenticación. Código de error: "invalid_client". Descripción: 'AADSTS70002:
Error al validar las credenciales. AADSTS50012: La aserción del cliente contiene una firma no válida. [Motivo: no se encontró la clave., Huella digital de la clave usada por el cliente: '<huella digital>'.

Este error puede producirse si el certificado de OAuth en Exchange Server no existe en Exchange Online.

Solución

Para corregir el problema, siga estos pasos:

1. Determine si el certificado de OAuth de Exchange Server local existe en su organización de Exchange Online:

   1. Ejecute el siguiente cmdlet de PowerShell en el Shell de administración de Exchange (EMS) para obtener el certificado de OAuth en Exchange Server:

      Get-ExchangeCertificate -Thumbprint (Get-AuthConfig).CurrentCertificateThumbprint | FL
      

      La salida del comando contiene el Thumbprint valor .

   2. Ejecute los siguientes cmdlets de PowerShell para obtener el certificado de OAuth de Exchange Online mediante el servicio MSOL:

      Connect-MsolService
      Get-MsolServicePrincipalCredential -ServicePrincipalName "00000002-0000-0ff1-ce00-000000000000" -ReturnKeyValues $true
      

      Si el valor del Value parámetro de la salida del comando está vacío, no existe un certificado OAuth en Exchange Online. En ese caso, vaya al paso 3 para cargar el certificado local en Exchange Online.

      Si el valor del Value parámetro no está vacío, guarde el valor en un archivo que tenga una extensión ".cer". Abra el archivo en la herramienta Administrador de certificados de Microsoft para ver el certificado de OAuth de Exchange Online. Compare el Thumbprint valor del certificado de Exchange Online con la huella digital del certificado local que obtuvo en el paso 1a. Si los valores de huella digital coinciden, vaya al paso 4. Si los valores de huella digital no coinciden, elija una de las siguientes opciones:

      • Vaya al paso 2 para reemplazar el certificado local existente por el certificado de Exchange Online.

      • Vaya al paso 3 para reemplazar el certificado de Exchange Online existente por el certificado local.

2. Reemplace el certificado local existente por el certificado de Exchange Online:

   1. Ejecute el siguiente cmdlet de PowerShell para actualizar la huella digital del certificado local:

      Set-AuthConfig -NewCertificateThumbprint <thumbprint of Exchange Online certificate> -NewCertificateEffectiveDate (Get-Date) 
      

      Si se le notifica que la fecha de vigencia del certificado es inferior a 48 horas a partir de ahora, acepte el aviso para continuar.

   2. Ejecute el siguiente cmdlet de PowerShell para publicar el certificado local:

      Set-AuthConfig -PublishCertificate  
      

   3. Ejecute el siguiente cmdlet de PowerShell para quitar las referencias al certificado anterior:

      Set-AuthConfig -ClearPreviousCertificate 
      

   4. Vaya al paso 4.

3. Exporte el certificado de autorización local y, a continuación, cargue el certificado en la organización de Exchange Online.

4. Ejecute el siguiente cmdlet de PowerShell para comprobar si el SPN en la configuración de autenticación local es 00000002-0000-0ff1-ce00-000000000000:

   Get-AuthConfig | FL ServiceName
   

   Si el valor de SPN es diferente, actualice el SPN ejecutando el siguiente cmdlet de PowerShell:

   Set-AuthConfig -ServiceName "00000002-0000-0ff1-ce00-000000000000"
   

Volver al principio

Error en la solicitud web de proxy: la respuesta no es XML con formato correcto

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error en la solicitud web de proxy, excepción interna: la respuesta no es XML con formato correcto

Si ejecuta la prueba sincronización, notificación, disponibilidad y respuestas automáticas para el usuario local, recibirá el siguiente mensaje de error:

La respuesta recibida del servicio no contenía XML válido.

Estos errores pueden producirse por cualquiera de los siguientes motivos:

• Problema de servicios web de Exchange externos (EWS)
• Configuración incorrecta de dispositivos de red, como un proxy inverso o un firewall

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Compruebe si una solicitud de disponibilidad de Exchange Online puede llegar a IIS en un servidor exchange. Realice una consulta de disponibilidad y, a continuación, busque en los registros de IIS entradas que tengan código 200 OK de estado HTTP o 401 Unauthorized en el momento de la consulta. Esas entradas indican que la solicitud de disponibilidad alcanzó IIS. Nota: Las marcas de tiempo de los registros de IIS usan la hora UTC.

   Si no encuentra esas entradas, compruebe los registros de proxy inverso y firewall para determinar dónde se ha bloqueado la solicitud de disponibilidad.

2. Realice una consulta de disponibilidad y, a continuación, busque en el registro de aplicaciones de Exchange Server en el Visor de eventos de Windows las entradas que se realizaron en el momento de la consulta para ayudar a reducir la causa del problema.

Volver al principio

No se puede conectar al servidor remoto

Incidencia

Tiene un usuario local que no puede ver la información de disponibilidad de un usuario en la nube. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error al comunicarse con https://login.microsoftonline.com/extSTS.srf., excepción interna: no se puede conectar al servidor remoto.

Este error puede producirse si uno o varios servidores de Exchange no pueden conectarse a una dirección URL de puerta de enlace de federación de Microsoft.

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Ejecute los siguientes cmdlets de PowerShell en el Shell de administración de Exchange (EMS) para comprobar si puede recuperar un token de delegación:

   Test-OrganizationRelationship -Identity "On-premises to O365*" -UserIdentity <on-premises user ID> -Verbose
   Test-FederationTrust -UserIdentity <on-premises user ID> -Verbose
   Test-FederationTrustCertificate
   

2. Compruebe que los servidores de Exchange locales tienen acceso saliente a Internet a los dos recursos siguientes:

   • La puerta de enlace de federación de Microsoft o el servidor de autorización de Microsoft si usa la autenticación de OAuth.

   • Dirección URL de disponibilidad de Microsoft 365: https://outlook.office365.com/ews/exchange.asmx.

   Para obtener más información, consulte Direcciones URL y intervalos de direcciones IP de Microsoft 365 y Consideraciones de firewall para la delegación federada.

3. Compruebe que la cuenta del sistema de Exchange Server tiene acceso a Internet a las siguientes direcciones URL. Siga estos pasos en todos los servidores de Exchange de su organización:

   1. Ejecute el siguiente comando psexec para iniciar una sesión de PowerShell que inicie un explorador web desde la cuenta del sistema:

      PsExec.exe -i -s "C:\Program Files\Internet Explorer\iexplore.exe"
      

   2. Pruebe el acceso al explorador (sin autenticación de OAuth) desde la cuenta del sistema a las siguientes direcciones URL de Puerta de enlace de federación de Microsoft:

      • https://nexus.microsoftonline-p.com/federationmetadata/2006-12/federationmetadata.xml

        El explorador debe mostrar una página xml.

      • https://login.microsoftonline.com/extSTS.srf

        El explorador debe solicitarle que descargue el archivo.

      • https://domains.live.com/service/managedelegation2.asmx

        El explorador debe mostrar una lista de operaciones compatibles con ManageDelegation2.

   3. Pruebe el acceso al explorador (autenticación de OAuth) desde la cuenta del sistema a las siguientes direcciones URL del servidor de autorización de Microsoft:

      • https://outlook.office365.com/ews/exchange.asmx

        El explorador debe mostrar un símbolo del sistema de inicio de sesión.

      • https://login.windows.net/common/oauth2/authorize

        El explorador debe mostrar el mensaje de error de inicio de sesión, "Lo sentimos, pero tenemos problemas para iniciar sesión".

      • https://accounts.accesscontrol.windows.net/<tenant guid>/tokens/OAuth/2

        El explorador debe mostrar el código 400 Bad Request de estado HTTP o el mensaje de error de inicio de sesión, "Lo sentimos, pero tenemos problemas para iniciar sesión".

Volver al principio

Error de detección automática de la dirección de correo electrónico: no se pudo resolver el nombre remoto

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error de detección automática de la dirección de correo <electrónico de la dirección> de correo electrónico con el error System.Net.WebException: No se pudo resolver el nombre remoto: "<nombre> de host local".

Este error puede producirse si la dirección URL del punto de conexión de detección automática local o la configuración de DNS pública son incorrectas.

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Ejecute los siguientes cmdlets de PowerShell en Exchange Online PowerShell para obtener el valor del TargetAutodiscoverEpr parámetro :

   Get-IntraOrganizationConnector | FL TargetAutodiscoverEpr
   Get-OrganizationRelationship | FL TargetAutodiscoverEpr
   

   Por ejemplo, si el valor del nombre de host local en el mensaje de error es mail.contoso.com, es probable que la dirección URL del punto de conexión de detección automática sea https://autodiscover.contoso.com/autodiscover/autodiscover.svc.

   Si el valor del TargetAutodiscoverEpr parámetro es correcto, vaya al paso 3. De lo contrario, vaya al paso 2.

2. Actualice la dirección URL del punto de conexión de detección automática mediante uno de los métodos siguientes:

   • Ejecute el Asistente para configuración híbrida (HCW) para restaurar el punto de conexión de detección automática predeterminado.

   • Actualice manualmente el DiscoveryEndpoint parámetro o el parámetro mediante la TargetAutodiscoverEpr ejecución de cualquiera de los siguientes cmdlets de PowerShell:

     • Set-IntraOrganizationConnector -Identity <cloud connector ID> -DiscoveryEndpoint <Autodiscover endpoint URL>

     • Set-OrganizationRelationship <O365 to On-premises*> -TargetAutodiscoverEpr <Autodiscover endpoint URL>

3. Asegúrese de que el nombre de host local en el mensaje de error (por ejemplo: mail.contoso.com) se puede resolver en DNS público. La entrada DNS del nombre de host debe apuntar al servicio de detección automática local en la dirección URL del punto de conexión de detección automática.

   Nota: Si no puede corregir el problema y desea una solución temporal, ejecute cualquiera de los siguientes cmdlets de PowerShell para actualizar manualmente el valor del TargetSharingEpr parámetro a la dirección URL externa de Exchange Web Services (EWS). La dirección URL de EWS externa debe ser similar https://<EWS hostname>/ews/exchange.asmx a y ser resolvible en DNS.

   • Set-IntraOrganizationConnector <cloud connector ID> -TargetSharingEpr <external EWS URL>

   • Set-OrganizationRelationship <O365 to On-premises*> -TargetSharingEpr <external EWS URL>

   Nota:

   Si establece el valor del TargetSharingEpr parámetro, el buzón de nube omite la detección automática y se conecta directamente al punto de conexión de EWS.

Volver al principio

No se pudo obtener ASURL. Error 8004010F

Incidencia

Tiene un usuario local que no puede ver la información de disponibilidad de un usuario en la nube. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

No se pudo obtener ASURL. Error 8004010F.

Se trata de un error general relacionado con el servicio de detección automática.

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Asegúrese de que la detección automática del usuario afectado devuelve la dirección URL de Exchange Web Services (EWS) para el usuario.

2. Ejecute la prueba de configuración automática de correo electrónico en el cliente de Outlook del usuario afectado para asegurarse de que la detección automática devuelve la dirección URL de EWS para el usuario.

3. Asegúrese de que la disponibilidad funciona entre usuarios locales hospedados en distintos servidores de Exchange.

4. Si tiene equilibradores de carga, compruebe si los equilibradores de carga provocaron el problema. Para ello, modifique el archivo hosts de Windows (en el equipo que tiene instalado el cliente de Outlook del usuario) para omitir los equilibradores de carga y apuntar a un servidor de acceso de cliente específico.

5. Si la disponibilidad funciona entre usuarios locales, compruebe si todos los servidores de Exchange locales tienen acceso saliente a direcciones URL de Microsoft 365 e intervalos de direcciones IP.

6. Compruebe si cada servidor de Exchange puede recuperar un token de delegación. Para ello, ejecute el siguiente cmdlet de PowerShell en EMS en todos los servidores de Exchange locales:

   Test-FederationTrust -UserIdentity <on-premises user ID> -Verbose
   

   Si el comando no puede recuperar un token de delegación, compruebe si el servidor puede conectarse a Office 365 en el nivel de proxy o firewall.

Volver al principio

Error en la solicitud web de proxy: objeto movido

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error en la solicitud web de proxy. , excepción interna: System.Net.WebException: se produjo un error en la solicitud con el mensaje de error: Objeto movido.

Este error puede producirse si el valor del TargetSharingEpr parámetro de la configuración de la organización está establecido en una dirección URL de punto de conexión de Exchange Web Services (EWS) incorrecta.

Puede ejecutar los siguientes cmdlets de PowerShell para obtener el valor del TargetSharingEpr parámetro de la configuración de la organización (conector entre organizaciones o relación de organización):

Get-IntraOrganizationConnector | FL TargetSharingEpr
Get-OrganizationRelationship | FL TargetSharingEpr

Compruebe que el valor del TargetSharingEpr parámetro no se resuelve en DNS público.

Nota: El Asistente para configuración híbrida (HCW) no establece un valor para el TargetSharingEpr parámetro a menos que seleccione Usar tecnología híbrida moderna de Exchange para instalar un agente híbrido. En ese escenario, HCW establece el TargetSharingEpr parámetro en un valor de punto de conexión de dirección URL de EWS externo similar a https://<GUID>.resource.mailboxmigration.his.msappproxy.net/ews/exchange.asmx. También puede establecer el valor del TargetSharingEpr parámetro manualmente. Si el TargetSharingEpr valor se establece en un punto de conexión, Outlook omite la detección automática y se conecta directamente a ese punto de conexión.

Solución

Para corregir el problema, ejecute cualquiera de los siguientes comandos para actualizar manualmente el valor del TargetSharingEpr parámetro a una dirección URL de EWS externa que se resuelva en DNS:

• Set-IntraOrganizationConnector <cloud connector ID> -TargetSharingEpr <external EWS URL>
• Set-OrganizationRelationship <O365 to On-premises*> -TargetSharingEpr <external EWS URL>

Volver al principio

Se anuló la solicitud: No se pudo crear un canal seguro SSL/TLS.

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local o viceversa. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Se anuló la solicitud: no se pudo crear un canal seguro SSL/TLS.

Causa 1: El usuario en la nube no puede ver la información de disponibilidad de un usuario local

El problema puede producirse si TLS 1.2 está mal configurado o deshabilitado en un punto de conexión local al que Se conecta Microsoft 365, como Exchange Server o un firewall.

Causa 2: El usuario local no puede ver la información de disponibilidad de un usuario en la nube

El problema también puede producirse por cualquiera de los siguientes motivos:

• Falta el certificado de Microsoft 365 (outlook.office365.com) en el almacén de entidades de certificación raíz (CA) de confianza.
• Existe un error de coincidencia del conjunto cypher .
• Otros problemas de SSL/TLS.

Pasos para la solución de problemas

Use las herramientas siguientes para diagnosticar problemas de TLS 1.2 locales:

• Ejecute la prueba del servidor SSL en el Analizador de conectividad remota de Microsoft.
• Ejecute el script HealthChecker en el Shell de administración de Exchange (EMS) en cada servidor exchange.

Para obtener información sobre la configuración de TLS, vea Procedimientos recomendados de configuración de TLS de Exchange Server y Preparación de TLS 1.2.

Para obtener información sobre cómo buscar certificados en el almacén de CA raíz de confianza, consulte Ver certificados con el complemento MMC.

Para obtener información sobre los conjuntos de cifrado TLS admitidos, consulte Conjuntos de cifrado TLS compatibles con Microsoft 365.

Volver al principio

El usuario especificado por el contexto de usuario en el token no existe

Incidencia

Tiene un usuario local que no puede ver la información de disponibilidad de un usuario en la nube. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

El usuario especificado por el contexto de usuario en el token no existe. error_category="invalid_user". 401: No autorizado.

Recibirá el mismo mensaje de error si ejecuta el cmdlet de PowerShell Test-OAuthConnectivity .

El error puede producirse si no se sincronizan el buzón de usuario local y el objeto de usuario de correo correspondiente en Microsoft Entra ID. Hasta que se sincronicen, el objeto de usuario de correo en Microsoft Entra ID podría no aprovisionarse.

Solución

Para solucionar el problema, use Microsoft Entra Connect para sincronizar el usuario local y el objeto de usuario de correo correspondiente en Microsoft Entra ID.

Volver al principio

El componente de nombre de host del valor de notificación de audiencia no es válido.

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

El componente de nombre de host del valor de notificación de audiencia "https://< hybrid.domain.com>" no es válido; error_category="invalid_resource"

El error puede producirse por cualquiera de las siguientes razones.

Causa 1

La descarga SSL y la autenticación de OAuth están habilitadas. La descarga ssl no funciona si la autenticación de OAuth está habilitada.

Causa 2

Un dispositivo de red delante de Exchange Server está bloqueando las solicitudes de disponibilidad.

Solución

Solución alternativa para la causa 1

Seleccione una de las siguientes soluciones alternativas:

• Deshabilite la descarga de SSL para los servicios web de Exchange (EWS) y la detección automática en el entorno local. Para obtener más información, vea Configuring SSL offloading for the Autodiscover and Configuring SSL offloading for EWS (Configuración de la descarga de SSL para la detección automática y configuración de la descarga de SSL para EWS) y la configuración predeterminada de SSL.

• Ejecute el siguiente cmdlet de PowerShell para deshabilitar la autenticación de OAuth deshabilitando el conector entre organizaciones en la nube:

  Set-IntraOrganizationConnector "HybridIOC*" -Enabled $false
  

  Cuando el conector entre organizaciones está deshabilitado, la autenticación DAuth se habilita a través de la relación de la organización. Para comprobar la relación de la organización, ejecute el siguiente cmdlet de PowerShell:

  Get-OrganizationRelationship
  

  Para obtener más información sobre la configuración de relaciones de la organización, consulte Desmitificación de la disponibilidad híbrida.

Resolución de la causa 2

Configure el dispositivo de red delante de Exchange para no bloquear las solicitudes de disponibilidad.

Volver al principio

Error en la solicitud web de proxy con el estado HTTP 503: Servicio no disponible

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error en la solicitud web de proxy, excepción interna: System.Net.WebException: Error en la solicitud con el estado HTTP 503: Servicio no disponible...

Este error puede producirse si hay un servicio de Microsoft Windows detenido, un componente de servidor, un grupo de aplicaciones IIS o un punto de conexión mal configurado.

Pasos para la solución de problemas

Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Asegúrese de que se están ejecutando los servicios de Windows que Exchange Server requiere. Para comprobar el estado de los servicios, ejecute el siguiente cmdlet de PowerShell en cada servidor exchange de su organización:

   Test-ServiceHealth
   

   Use la consola servicios para iniciar los servicios detenidos que necesite Exchange Server.

2. Compruebe que los componentes de Exchange Server necesarios están activos. Para comprobar el estado de los componentes, ejecute el siguiente cmdlet de PowerShell en cada servidor exchange de su organización:

   Get-ServerComponentState <server name>
   

   Para activar un componente inactivo, use el cmdlet Set-ServerComponentState de PowerShell.

3. Asegúrese de que se inician los siguientes grupos de aplicaciones DE IIS para Exchange Web Services (EWS) y Detección automática:

   • MSExchangeServicesAppPool
   • MSExchangeSyncAppPool
   • MSExchangeAutodiscoverAppPool

4. Compruebe si el punto de conexión de detección automática es válido. Siga estos pasos:

   1. Ejecute los siguientes cmdlets de PowerShell para obtener la dirección URL del punto de conexión de detección automática de los DiscoveryEndpoint valores de parámetro o TargetAutodiscoverEpr :

      Get-IntraOrganizationConnector | FL DiscoveryEndpoint
      Get-OrganizationRelationship | FL TargetAutodiscoverEpr
      

   2. Vaya a la dirección URL del punto de conexión de detección automática en un explorador web o ejecute el Invoke-WebRequest -Uri "<endpoint URL>" -Verbose cmdlet de PowerShell para asegurarse de que la dirección URL es válida. Preferiblemente, compruebe la dirección URL de una red externa.

5. Para comprobar si la dirección URL de EWS es válida, siga estos pasos:

   1. Ejecute los siguientes cmdlets de PowerShell para obtener la dirección URL de EWS del valor del TargetSharingEpr parámetro en la configuración de la organización:

      Get-IntraOrganizationConnector | FL TargetSharingEpr
      Get-OrganizationRelationship | FL TargetSharingEpr
      

   b. Vaya a la dirección URL de EWS en un explorador web o ejecute el Invoke-WebRequest -Uri "<endpoint URL>" -Verbose cmdlet de PowerShell para asegurarse de que la dirección URL es válida. Preferiblemente, compruebe la dirección URL de una red externa.

6. Compruebe en los registros de IIS las solicitudes de disponibilidad que devuelven código 503 Service Unavailablede estado HTTP:

   1. Realice una solicitud de disponibilidad de Exchange Online.

   2. Compruebe si hay entradas de código 503 Service Unavailable de estado HTTP en los registros de IIS de la carpeta W3SVC1 para el sitio web predeterminado en cada servidor exchange. La ruta de acceso de la carpeta W3SVC1 es %SystemDrive%\inetpub\logs\LogFiles\W3SVC1. Esas entradas pueden ayudar a identificar el servidor que tiene el problema.

   3. Si la solicitud de disponibilidad no se registra en la carpeta W3SVC1 , compruebe si la solicitud se registra en los registros de error de la carpeta HTTPERR de cada servidor exchange. La ruta de acceso de la carpeta HTTPERR es %SystemRoot%\System32\LogFiles\HTTPERR. Si la solicitud de disponibilidad se registra en los registros HTTPERR , compruebe si hay una configuración de IIS mal configurada.

7. Compruebe el encabezado de la respuesta del servidor que recibe al conectarse a la dirección URL de EWS local para comprobar que IIS (no un servidor web diferente) envió la respuesta. Para ello, ejecute los siguientes comandos en una sesión de PowerShell que no esté conectada a EWS local (no ejecute los comandos en el Shell de administración de Exchange):

   $req = [System.Net.HttpWebRequest]::Create("<EWS URL>") 
   $req.UseDefaultCredentials = $false $req.GetResponse()
   $ex = $error[0].Exception
   $ex.InnerException.Response $resp.Headers["Server"]
   

   Por ejemplo, si ve "Microsoft-HTTPAPI/2.0" en la salida del comando en lugar de "Microsoft -IIS/10.0", es probable que un servicio proxy de aplicación web (WAP) (no IIS) responda a la solicitud. Compruebe si el servicio WAP está inactivo.

Volver al principio

Error en la solicitud web de proxy con el estado HTTP 504: Tiempo de espera de la puerta de enlace

LID: 43532

Incidencia

Tiene un usuario en la nube que no puede ver la información de disponibilidad de un usuario local. Al diagnosticar el problema, encontrará el siguiente mensaje de error:

Error en la solicitud web de proxy, excepción interna: la solicitud produjo un error con el estado HTTP 504: Tiempo de espera de la puerta de enlace...

Este error puede producirse si un agente híbrido de la organización está configurado incorrectamente.

Solución

Para corregir el problema, siga estos pasos. Después de completar cada paso, compruebe si se ha corregido el problema de disponibilidad.

1. Compruebe el valor del TargetSharingEpr parámetro en la configuración de la organización. El valor debe ser similar a https://<GUID>.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx. Para determinar el valor del TargetSharingEpr parámetro, ejecute los siguientes cmdlets de PowerShell:

   Get-IntraOrganizationConnector | FL TargetSharingEpr
   Get-OrganizationRelationship | FL TargetSharingEpr
   

   Si el valor del TargetSharingEpr parámetro es incorrecto:

   1. Ejecute el Asistente para configuración híbrida (HCW) y seleccione Usar topología híbrida clásica de Exchange.

   2. Vuelva a ejecutar hcw y seleccione Usar topología híbrida moderna de Exchange. Este procedimiento obliga al HCW a restablecer el valor del TargetSharingEpr parámetro.

2. Compruebe el estado del servicio híbrido de Microsoft en el servidor donde está instalado el Agente híbrido. Si el servicio está detenido, inícielo.

3. Compruebe el estado del Agente híbrido. Si el estado es Inactivo:

   1. Ejecute el Asistente para configuración híbrida (HCW) y seleccione Usar topología híbrida clásica de Exchange.

   2. Vuelva a ejecutar hcw y seleccione Usar topología híbrida moderna de Exchange. Este procedimiento obliga a HCW a reinstalar el Agente híbrido.

   3. Instale el módulo de PowerShell del Agente híbrido y, a continuación, ejecute el cmdlet Get-HybridApplication de PowerShell para buscar la dirección URL interna a la que apunta el Agente híbrido.

4. Vaya a la dirección URL interna que encontró en el paso 3. Resuelva los errores que encuentre, como los errores de certificado.

5. Configure el Agente híbrido para dirigir las solicitudes a un equilibrador de carga en lugar de a un servidor que ejecuta Microsoft Exchange Server para descartar los problemas que pueden existir en ese servidor.

6. Compruebe que el Agente híbrido admite solicitudes de disponibilidad y migración de buzones.

Volver al principio