Résoudre les erreurs de disponibilité

Pour résoudre une erreur liée aux informations de disponibilité, sélectionnez le message d’erreur applicable dans la table des matières en haut de cet article.

Si les étapes de résolution des problèmes ne vous aident pas à résoudre le problème, contactez le support Microsoft.

Une erreur s’est produite lors de la vérification de la sécurité du message

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Échec de la découverte automatique pour l’adresse> smtp de l’adresse <e-mail avec l’erreur System.Web.Services.Protocols.SoapHeaderException : une erreur s’est produite lors de la vérification de la sécurité du message sur System.Web. Services.Protocols. SoapHttpClientProtocol. ReadResponse(SoapClientMessage message, WebResponse responseStream, Boolean asyncCall) à l’adresse System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

Cette erreur peut se produire si l’authentification WSSecurity n’est pas activée ou doit être réinitialisée, ou après le renouvellement des certificats de fédération dans Exchange Server.

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Pour actualiser les métadonnées dans la passerelle de fédération Microsoft, exécutez la commande suivante deux fois dans l’environnement de ligne de commande Exchange Management Shell (EMS) local :

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Pour plus d’informations, consultez Les recherches de disponibilité cessent de fonctionner dans un environnement intersite ou dans un déploiement hybride Exchange Server.

2. Procédez comme suit pour activer/désactiver l’authentification WSSecurity :

   1. Suivez la procédure décrite dans Les utilisateurs d’une organisation fédérée ne peuvent pas voir les informations de disponibilité d’une autre organisation Exchange pour activer (ou réinitialiser l’authentification WSSecurity si elle est déjà activée) dans les répertoires virtuels découverte automatique et EWS sur tous les serveurs Exchange locaux.

      Remarques

      • Effectuez cette étape même si la sortie des applets Get-AutodiscoverVirtualDirectory de commande PowerShell et Get-WebServicesVirtualDirectory indique que l’authentification WSSecurity est déjà activée.

      • La procédure affecte uniquement la disponibilité intersite et n’affecte pas les autres connexions client-serveur.

   2. Exécutez la iisreset /noforce commande dans une fenêtre PowerShell ou invite de commandes sur chaque serveur Exchange local pour redémarrer IIS.

   3. Redémarrez tous les serveurs Exchange locaux.

3. Recherchez et résolvez les avertissements ou erreurs d’asymétrie temporelle dans le journal des événements système.

4. Définissez la valeur du TargetSharingEpr paramètre dans la relation d’organisation sur l’URL des services Web Exchange (EWS) externes locaux en exécutant l’applet de commande suivante dans Exchange Online PowerShell :

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

   Après avoir défini la valeur du TargetSharingEpr paramètre, la boîte aux lettres cloud contourne la découverte automatique et se connecte directement au point de terminaison EWS de la boîte aux lettres locale.

   Remarque : La valeur par défaut du TargetSharingEpr paramètre est vide. Les paramètres TargetAutodiscoverEpr de découverte automatique ou DiscoveryEndpoint contiennent généralement l’URL externe EWS locale (point de terminaison de découverte automatique). Pour obtenir les valeurs de TargetAutodiscoverEpr paramètre et DiscoveryEndpoint , exécutez les applets de commande PowerShell suivantes :

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

5. Assurez-vous que la valeur du TargetApplicationUri paramètre dans la relation d’organisation correspond à la valeur de AccountNamespace paramètre dans l’identificateur d’organisation fédérée. Pour rechercher la valeur du TargetApplicationUri paramètre, exécutez l’applet de commande PowerShell Test-OrganizationRelationship . Pour trouver la valeur du AccountNamespace paramètre, consultez Démystification de la disponibilité hybride.

Retour en haut

Échec de la requête web de proxy : impossible de se connecter au serveur distant

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local, ou vice versa. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Échec de la requête web de proxy. , exception interne : System.Net.WebException : Impossible de se connecter au serveur distant ; System.Net.Sockets.SocketException : une tentative de connexion a échoué car le tiers connecté n’a pas répondu correctement après un certain temps, ou la connexion établie a échoué parce que l’hôte connecté n’a pas pu répondre CUSTOMER_IP :443 / MICROSOFT_IP :443 à System.Net.Sockets.Sockets.EndConnect(IAsyncResult asyncResult)

Cette erreur peut se produire si des problèmes de connectivité réseau empêchent les connexions entrantes ou sortantes entre les adresses IP dans Exchange Online et les points de terminaison dans Exchange Server.

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Vérifiez que le pare-feu sur chaque serveur Exchange local autorise les connexions entrantes ou sortantes entre les points de terminaison Exchange Server et les adresses IP Exchange Online. Pour identifier les problèmes de pare-feu, effectuez une demande de disponibilité à partir d’Exchange Online, puis vérifiez le pare-feu local, le proxy inverse et les journaux réseau. Pour plus d’informations sur la configuration d’un pare-feu, consultez Considérations relatives au pare-feu pour la délégation fédérée et URL Microsoft 365 et plages d’adresses IP.

2. Vérifiez que les demandes d’Exchange Online atteignent les serveurs d’accès au client locaux. Suivez ces étapes sur tous les serveurs d’accès au client locaux :

   1. Effectuez une demande de disponibilité à partir d’Exchange Online.

   2. Vérifiez les journaux IIS dans le dossier W3SVC1 pour le site web par défaut pour vérifier que la demande de disponibilité est enregistrée. Le chemin du dossier W3SVC1 est %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

   3. Vérifiez les journaux du proxy HTTP dans les dossiers suivants pour vérifier que la demande de disponibilité est journalisée :

      • %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover

      • %ExchangeInstallPath%\Logging\HttpProxy\Ews

3. Testez la connectivité d’Exchange Online au point de terminaison EWS (Exchange Web Services) local en exécutant l’applet de commande suivante dans Exchange Online PowerShell :

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

   Remarques

   • Ce test est utile si vous limitez les connexions entrantes à partir d’Internet pour autoriser uniquement les adresses IP Exchange Online à se connecter à votre point de terminaison EWS local.

   • Si seuls quelques utilisateurs cloud sont affectés par ce problème et que leurs boîtes aux lettres sont hébergées sur le même serveur de messagerie dans Exchange Online, vérifiez si ce serveur de messagerie peut se connecter à des points de terminaison locaux. Il est possible qu’un point de terminaison local bloque les connexions à partir de l’adresse IP externe sortante de ce serveur de messagerie.

   • Lorsque vous êtes invité à entrer des informations d’identification, entrez vos informations d’identification d’administrateur de domaine au format « domaine\administrateur ».

Retour en haut

Échec de la découverte automatique pour l’adresse e-mail : état HTTP 404

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Échec de la découverte automatique pour l’adresse> SMTP de l’adresse <de messagerie de l’utilisateur avec l’erreur System.Net.WebException : la requête a échoué avec le code 404 Not Foundd’état HTTP .

Cette erreur peut se produire si les points de terminaison de découverte automatique ne sont pas fonctionnels ou mal configurés.

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Vérifiez si le point de terminaison de découverte automatique est valide :

   1. Exécutez les commandes suivantes pour obtenir l’URL du point de terminaison de découverte automatique à partir du DiscoveryEndpoint paramètre ou TargetAutodiscoverEpr :

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

   2. Accédez à l’URL du point de terminaison de découverte automatique dans un navigateur web. Un point de terminaison de découverte automatique valide ne retourne pas le code 404 Not Foundd’état HTTP .

2. Assurez-vous que le domaine de l’utilisateur local est spécifié dans les paramètres de l’organisation (connecteur intra-organisation ou relation d’organisation) de l’utilisateur cloud :

   1. Exécutez les applets de commande PowerShell suivantes dans Exchange Online PowerShell :

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

      Vérifiez que le domaine de l’utilisateur local est répertorié dans la sortie de l’une ou l’autre commande. Par exemple, si l’utilisateur user1@contoso.com du cloud recherche la disponibilité de l’utilisateur user2@contoso.rolocal , vérifiez que le domaine contoso.ro local est répertorié.

   2. Si le domaine de l’utilisateur local n’existe pas dans les paramètres de l’organisation de l’utilisateur cloud, ajoutez le domaine en exécutant l’applet de commande PowerShell suivante :

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

3. Assurez-vous que le mappage du gestionnaire SVC existe dans les répertoires virtuels de découverte automatique et EWS sous Site web par défaut dans le Gestionnaire des services Internet. Pour plus d’informations, consultez FederationInformations impossibles à recevoir et Exception levée par la cible.

   Remarque : Le AutodiscoverDiscoveryHander mappage (*.svc) n’est pas utilisé pour la recherche de disponibilité de fédération.

Retour en haut

Échec de la demande web du proxy d’exception

LID : 43532

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Échec de la demande web du proxy d’exception. , exception interne : la requête a échoué avec l’état HTTP 401 : Diagnostics non autorisés : 2000005 ; reason= « L’utilisateur spécifié par le contexte utilisateur dans le jeton est ambigu. » ; error_category="invalid_user »

Cette erreur peut se produire si l’UPN, l’adresse SMTP ou l’adresse SIP de l’utilisateur local est utilisé par une autre boîte aux lettres locale.

Résolution

Pour résoudre ce problème, procédez comme suit :

1. Recherchez des objets utilisateur locaux qui ont un UPN, une adresse SMTP ou une adresse SIP en double à l’aide de requêtes LDAP personnalisées. Vous pouvez exécuter des requêtes LDAP à l’aide de LDP.exe ou du composant logiciel enfichable MMC Utilisateurs et ordinateurs Active Directory.

   Par exemple, pour afficher tous les utilisateurs qui ont user@corp.contoso.com comme UPN, user@contoso.com comme adresse SMTP ou user@contoso.com comme adresse SIP, utilisez la requête LDAP suivante :

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

   Pour plus d’informations sur l’utilisation d'LDP.exe ou d’utilisateurs et d’ordinateurs Active Directory pour rechercher des objets Active Directory, consultez exemples LDP.

2. Modifiez l’adresse dupliquée ou supprimez l’objet utilisateur en double.

Retour en haut

Une connexion existante a dû être fermée par l’hôte distant

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Échec de la requête web de proxy. , exception interne : System.Net.WebException : la connexion sous-jacente a été fermée : une erreur inattendue s’est produite sur une réception. System.IO.IOException : impossible de lire les données à partir de la connexion de transport : une connexion existante a été fermée de force par l’hôte distant. System.Net.Sockets.SocketException : une connexion existante a été fermée de force par l’hôte distant.

Cette erreur peut se produire si un pare-feu local bloque une connexion entrante à partir d’une adresse IP sortante externe dans Exchange Online.

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Vérifiez si les demandes de disponibilité d’Exchange Online atteignent IIS sur un serveur Exchange. Effectuez une demande de disponibilité à partir d’Exchange Online et recherchez les entrées de journal IIS suivantes qui ont été effectuées au moment de la demande de disponibilité :

   • Entrée de découverte automatique dans le dossier %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover qui contient « ASAutoDiscover/CrossForest/EmailDomain ».

     Remarque : Si vous définissez manuellement le TargetSharingEpr paramètre dans la relation d’organisation sur l’URL des services Web Exchange (EWS) externes locaux, la découverte automatique est ignorée et cette entrée n’existe pas.

   • Entrée EWS dans le dossier %ExchangeInstallPath%\Logging\HttpProxy\Ews qui contient « ASProxy/CrossForest/EmailDomain ».

   Remarque : Les horodatages des journaux IIS utilisent l’heure UTC.

2. Vérifiez que le pare-feu sur chaque serveur Exchange local autorise les connexions entrantes ou sortantes entre les points de terminaison Exchange Server et les adresses IP Exchange Online. Pour identifier les problèmes de pare-feu, effectuez des demandes de disponibilité à partir d’Exchange Online, puis vérifiez le pare-feu local, le proxy inverse et les journaux réseau. Pour plus d’informations sur la configuration d’un pare-feu, consultez Considérations relatives au pare-feu pour la délégation fédérée et URL Microsoft 365 et plages d’adresses IP.

3. Si votre organisation utilise des relations d’organisation pour implémenter la disponibilité, assurez-vous qu’un certificat de fédération est installé sur chaque serveur Exchange. Exécutez les commandes suivantes dans Exchange Management Shell (EMS) :

   Test-FederationTrustCertificate
   Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo | FL
   

   Si le certificat de fédération est installé, la sortie de commande ne doit pas contenir d’erreurs ou d’avertissements.

4. Procédez comme suit pour activer/désactiver l’authentification WSSecurity :

   1. Suivez la procédure décrite dans Les utilisateurs d’une organisation fédérée ne peuvent pas voir les informations de disponibilité d’une autre organisation Exchange pour activer (ou réinitialiser l’authentification WSSecurity si elle est déjà activée) dans les répertoires virtuels découverte automatique et EWS sur tous les serveurs Exchange locaux. Effectuez cette étape même si l’authentification WSSecurity est déjà activée.

   2. Recyclez les pools d’applications de découverte automatique et EWS dans le Gestionnaire des services Internet.

   3. Exécutez la iisreset /noforce commande dans une fenêtre PowerShell ou invite de commandes sur chaque serveur Exchange local pour redémarrer IIS.

5. Si seuls quelques utilisateurs cloud sont affectés par ce problème et que leurs boîtes aux lettres sont hébergées sur le même serveur de messagerie dans Exchange Online, vérifiez si ce serveur de messagerie peut se connecter à des points de terminaison locaux. Il est possible qu’un point de terminaison local bloque les connexions à partir de l’adresse IP sortante de ce serveur de messagerie.

Retour en haut

Impossible de trouver des informations de configuration pour la forêt/le domaine dans Active Directory

LID : 47932

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local, ou vice versa. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Les informations de configuration pour le domaine> de forêt/domaine <sont introuvables dans Active Directory.

Cette erreur peut se produire si les paramètres de l’organisation sont mal configurés.

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Vérifiez que le domaine d’un utilisateur dont les informations de disponibilité sont demandées existe dans les paramètres de l’organisation de l’utilisateur qui tente d’afficher les informations de disponibilité. Sélectionnez l’une des procédures suivantes en fonction de la direction de la disponibilité.

   • Cloud vers local

     Pour un utilisateur cloud qui tente d’afficher les informations de disponibilité d’un utilisateur local, procédez comme suit :

     1. Connectez-vous à Exchange Online PowerShell, puis exécutez les applets de commande PowerShell suivantes pour obtenir les domaines fédérés :

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

        Vérifiez que le domaine de l’utilisateur local est répertorié dans la sortie de l’une ou l’autre commande. Par exemple, si l’utilisateur user1@contoso.com du cloud recherche la disponibilité de l’utilisateur user2@contoso.rolocal , vérifiez que le domaine contoso.ro local est répertorié.

        Remarque

        Vous pouvez également trouver les noms de domaine en exécutant (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses dans Exchange Online PowerShell ou en exécutant (Get-FederatedOrganizationIdentifier).Domains dans l’environnement Exchange Management Shell (EMS) local.

     2. Si le domaine de l’utilisateur local n’existe pas dans les paramètres de l’organisation de l’utilisateur cloud, ajoutez le domaine en exécutant l’applet de commande PowerShell suivante :

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

   • Local vers le cloud

     Pour un utilisateur local qui tente d’afficher les informations de disponibilité d’un utilisateur cloud, procédez comme suit :

     1. Dans EMS, exécutez les applets de commande PowerShell suivantes :

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

        Vérifiez si le domaine de l’utilisateur cloud correspond à l’un des domaines répertoriés dans la sortie de la commande. Par exemple, si l’utilisateur user1@contoso.ro local recherche des informations de disponibilité pour l’utilisateur user2@contoso.comcloud , vérifiez que le domaine contoso.com cloud est présent dans la sortie de l’une ou l’autre commande.

     2. Si le domaine de l’utilisateur cloud n’existe pas dans les paramètres de l’organisation de l’utilisateur local, ajoutez le domaine. Exécutez la commande suivante :

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

2. Assurez-vous que votre déploiement Exchange hybride dispose d’une configuration hybride complète. Si nécessaire, réexécutez l’Assistant Configuration hybride (HCW) et sélectionnez Configuration hybride complète au lieu de Configuration hybride minimale. Une configuration hybride minimale ne crée pas de relation d’organisation (approbation de fédération) ou de connecteurs intra-organisation.

Retour en haut

Échec de la requête web de proxy : état HTTP 401

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, vous trouvez l’un des messages d’erreur suivants.

Message d’erreur 1

Échec de la requête web de proxy. Exception interne : la requête a échoué avec l’état HTTP 401 : Non autorisé.

Message d’erreur 2

Échec de la découverte automatique pour l’adresse e-mail. Exception interne : la requête a échoué avec l’état HTTP 401 : Non autorisé.

Cette erreur peut se produire si un périphérique de périmètre devant Exchange Server est configuré pour préauthentifier (exiger un nom d’utilisateur et un mot de passe) au lieu de transmettre des demandes d’Exchange Online directement à Exchange Server. La découverte automatique et les répertoires virtuels EWS dans les déploiements Exchange hybrides ne prennent pas en charge la pré-authentification.

Les proxys inversés, les pare-feu et la passerelle de gestion des menaces Microsoft (TMG) sont des exemples d’appareils de périmètre.

Le message d’erreur 1 indique qu’une demande EWS a échoué.

Le message d’erreur 2 indique qu’une demande de découverte automatique a échoué.

Étapes de résolution des problèmes

Pour résoudre le problème de disponibilité, quel que soit le message d’erreur que vous avez reçu, procédez comme suit. Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Vérifiez si la pré-authentification est activée. Procédez comme suit :

   1. Exécutez le test Disponibilité dans l’Analyseur de connectivité à distance pour vérifier si la pré-authentification est activée. La boîte aux lettres cloud est la boîte aux lettres source et la boîte aux lettres locale est la boîte aux lettres cible. Une fois le test terminé, vérifiez l’état de l’authentification directe au niveau du point de terminaison. Si vous voyez une coche rouge, désactivez la préauthentification et retestez. Si vous voyez une coche verte, passez à l’étape suivante, car il peut s’agir d’un faux positif.

   2. Vérifiez si une demande de disponibilité d’Exchange Online atteint IIS. Effectuez une requête de disponibilité, puis recherchez l’une des entrées suivantes dans les journaux IIS dans Exchange Server au moment de la requête :

      • Dans le dossier %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover , recherchez une entrée de découverte automatique qui a le code 401 Unauthorized d’état HTTP et contient le texte « ASAutoDiscover/CrossForest/EmailDomain ».

        Remarque : Si le TargetSharingEpr paramètre dans la relation d’organisation spécifie une URL externe EWS locale, la découverte automatique est ignorée et cette entrée n’apparaît pas.

      • Dans le dossier %ExchangeInstallPath%\Logging\HttpProxy\Ews , recherchez une entrée EWS qui a le code 401 Unauthorized d’état HTTP et contient le texte « ASProxy/CrossForest/EmailDomain ».

      Remarque : Les horodatages des journaux IIS utilisent l’heure UTC. Certaines entrées qui ont le code 401 Unauthorized d’état HTTP sont normales.

      Les entrées spécifiées indiquent que la demande de disponibilité a atteint IIS et exclut généralement les problèmes de pré-authentification. Si vous ne trouvez pas les entrées spécifiées, vérifiez vos journaux de proxy inverse et de pare-feu pour comprendre où la demande de disponibilité est bloquée.

2. Vérifiez que vous avez activé WSSecurity (Exchange Server 2010) ou l’authentification OAuth (Exchange Server 2013 et versions ultérieures) sur les répertoires virtuels EWS et autodiscover. Vérifiez également que vous avez activé les paramètres d’authentification par défaut dans IIS pour la découverte automatique et les répertoires virtuels EWS. Pour plus d’informations, consultez Paramètres d’authentification par défaut pour les répertoires virtuels Exchange et Paramètres par défaut pour les répertoires virtuels Exchange.

3. Suivez les étapes de résolution dans Une erreur s’est produite lors de la vérification de la sécurité du message. Si WSSecurity est configuré, veillez à effectuer l’étape qui bascule WSSecurity. Si l’authentification OAuth est configurée au lieu de WSSecurity, basculez l’authentification OAuth sur les répertoires virtuels de découverte automatique et EWS en exécutant les commandes suivantes :

   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. Vérifiez que vous disposez d’une approbation de fédération à jour. Exécutez la commande suivante dans Exchange Online PowerShell pour récupérer les informations d’approbation de fédération pour votre organisation Exchange :

   Get-FederationTrust
   

   La sortie de la commande doit contenir les informations suivantes :

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

   Remarque : l’approbation WindowsLiveId est une instance de consommateur de la passerelle de fédération Microsoft. L’approbation MicrosoftOnline est une instance métier de la passerelle de fédération Microsoft.

   Pour une approbation de fédération à jour, assurez-vous que est ApplicationIdentifier260563 et non 292841, et que est ApplicationUrioutlook.com et non outlook.live.com. Si vous avez une approbation de fédération obsolète, contactez le support Microsoft.

Retour en haut

Échec de la découverte automatique pour l’adresse e-mail : InvalidUser

LID : 33676

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

La réponse du service de découverte automatique à «https://Autodiscover/Autodiscover.svc/WSSecurity » a échoué en raison d’une erreur dans le paramètre utilisateur « ExternalEwsUrl ». Message d’erreur : InvalidUser.

Le message d’erreur peut s’afficher lorsque vous exécutez le test De disponibilité dans l’Analyseur de connectivité à distance.

Cette erreur peut se produire si la boîte aux lettres cloud ou le point de terminaison de découverte automatique est mal configuré.

Étapes de résolution des problèmes

1. Vérifiez que l’utilisateur cloud dispose d’une adresse SMTP secondaire qui inclut le onmicrosoft.com domaine en exécutant la commande suivante :

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

   Par exemple, un utilisateur qui a l’adresse user1@contoso.com SMTP principale doit avoir une adresse SMTP secondaire similaire à user1@contoso.mail.onmicrosoft.com.

   Si l’utilisateur cloud est géré à partir d’Exchange Server, ajoutez l’adresse SMTP secondaire à Exchange Server, puis synchronisez les données d’identité entre votre environnement local et l’ID Microsoft Entra.

2. Exécutez les commandes suivantes pour définir la valeur du TargetSharingEpr paramètre dans la relation d’organisation sur l’URL des services web Exchange (EWS) externes locaux :

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

   Après avoir défini la valeur du TargetSharingEpr paramètre, la boîte aux lettres cloud contourne la découverte automatique et se connecte directement au point de terminaison EWS de la boîte aux lettres locale.

Retour en haut

L’appelant n’a pas accès aux données de disponibilité

LID : 47652, 44348, 40764

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local, ou vice versa. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException : l’appelant n’a pas accès aux données de disponibilité.

Cette erreur peut se produire si la boîte aux lettres de l’utilisateur dont les informations de disponibilité sont demandées est mal configurée.

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Vérifiez les autorisations de calendrier de l’utilisateur dont les informations de disponibilité sont demandées en exécutant la commande suivante :

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

   La AccessRights valeur de l’utilisateur Default dans la sortie de commande doit être AvailabilityOnly ou LimitedDetails. Si la AccessRights valeur est None, exécutez l’applet de commande PowerShell suivante pour définir cette valeur sur AvailabilityOnly ou LimitedDetails:

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

2. Utilisez la méthode applicable pour vérifier la relation d’organisation :

   • Si un utilisateur cloud ne peut pas afficher les informations de disponibilité d’un utilisateur local :

     Vérifiez que la relation d’organisation locale spécifie le domaine cloud qui peut accéder aux informations de disponibilité locales. Un exemple de domaine cloud est contoso.mail.onmicrosoft.com. Pour plus d’informations sur la modification de la relation d’organisation dans Exchange Server, consultez Utiliser PowerShell pour modifier la relation d’organisation. Vérifiez également que l’adresse e-mail De de l’utilisateur cloud a le même domaine cloud, par exemple lucine.homsi@contoso.mail.onmicrosoft.com.

   • Si un utilisateur local ne peut pas afficher les informations de disponibilité d’un utilisateur cloud :

     Vérifiez que la relation d’organisation cloud spécifie le domaine local qui peut accéder aux informations de disponibilité du cloud. Un exemple de domaine local est contoso.com. Pour plus d’informations sur la modification de la relation d’organisation dans Exchange Online, consultez Utiliser Exchange Online PowerShell pour modifier la relation d’organisation. Vérifiez également que l’adresse e-mail De de l’utilisateur local a le même domaine local, par exemple lucine.homsi@contoso.com.

Retour en haut

Une erreur s’est produite lors du traitement des jetons de sécurité dans le message

LID : 59916

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

ProxyWebRequestProcessingException ErrorProxyRequestProcessingFailed
Échec de la requête web de proxy. , exception interne : une erreur s’est produite lors du traitement des jetons de sécurité dans le message.

Cette erreur peut se produire si les certificats ou métadonnées de la passerelle de fédération Microsoft ne sont pas valides.

Étapes de résolution des problèmes

1. Vérifiez la date d’expiration et les empreintes des certificats d’approbation de fédération locaux en exécutant les applets de commande PowerShell suivantes :

   Get-FederationTrust | FL
   Test-FederationTrust
   Test-FederationTrustCertificate
   

2. Pour actualiser les métadonnées dans la passerelle de fédération Microsoft, exécutez la commande suivante deux fois dans l’environnement de ligne de commande Exchange Management Shell (EMS) local :

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Pour plus d’informations, consultez Les recherches de disponibilité cessent de fonctionner.

Retour en haut

La demande inter-organisations n’est pas autorisée, car le demandeur provient d’une autre organisation

LID : 39660

Problème

Vous disposez d’un scénario de maillage hybride dans lequel un utilisateur cloud d’un locataire Exchange Online non intègre ne peut pas afficher les informations de disponibilité d’un utilisateur cloud dans un autre locataire Exchange Online qui passe en mode hybride. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

La demande inter-organisation pour l’adresse> SMTP de boîte aux lettres <n’est pas autorisée, car le demandeur provient d’une autre organisation
Destinataire : <adresse SMTP>
Type d’exception : CrossOrganizationProxyNotAllowedForExternalOrganization
Message d’exception : la demande inter-organisation pour <l’adresse> SMTP n’est pas autorisée, car le demandeur appartient à une autre organisation.

Par exemple, un utilisateur d’un lucine@adatum.com locataire Exchange Online nonhybrid ne peut pas afficher la disponibilité d’un utilisateur chanok@contoso.com cloud dans un locataire hybride. L’utilisateur chanok@contoso.com cloud a une adresse chanok@contoso.mail.onmicrosoft.come-mail proxy . Le locataire non-hybride a deux relations d’organisation : contoso.com (local) et contoso.mail.onmicrosoft.com (cloud). Découverte automatique pour contoso.com les points vers Exchange Server et découverte automatique pour contoso.mail.onmicrosoft.com les points vers Exchange Online. L’utilisateur du locataire non-hybride reçoit le message d’erreur lors de l’interrogation des informations de disponibilité pour chanok@contoso.com, car la découverte automatique des contoso.com points ne pointe pas vers Exchange Online.

Remarque

Pour le scénario de maillage hybride local équivalent, consultez Maillage hybride.

Solution de contournement

Pour contourner ce problème, votre organisation peut utiliser l’une des méthodes suivantes :

• Les utilisateurs du locataire Exchange Online non autonome doivent interroger la disponibilité d’un utilisateur cloud dans un locataire hybride à l’aide de l’adresse e-mail pour laquelle la découverte automatique pointe vers Exchange Online. Par exemple, lucine@adatum.com interroge les informations de disponibilité pour chanok@contoso.mail.onmicrosoft.com. Pour interroger correctement les informations de disponibilité, les utilisateurs du locataire Exchange Online non autonome doivent savoir quels utilisateurs du locataire hybride sont hébergés dans le cloud et, pour chacun de ces utilisateurs, l’adresse e-mail pour laquelle la découverte automatique pointe vers Exchange Online.

• Un administrateur du locataire Exchange Online non hybride doit définir l’adresse e-mail externe de chaque utilisateur cloud dans le locataire hybride sur l’adresse e-mail pour laquelle la découverte automatique pointe vers Exchange Online. Par exemple, un administrateur dans le locataire Exchange Online non hybride définit l’adresse e-mail cible de chanok@contoso.com dans le locataire hybride sur chanok@contoso.mail.onmicrosoft.com. Pour effectuer cette modification, l’administrateur doit savoir quels utilisateurs du locataire hybride sont hébergés dans le cloud et, pour chacun de ces utilisateurs, l’adresse e-mail pour laquelle la découverte automatique pointe vers Exchange Online. Pour plus d’informations sur la synchronisation interlocataire des adresses e-mail des utilisateurs, consultez Qu’est-ce que la synchronisation entre locataires ?

Informations supplémentaires

Un utilisateur peut rencontrer un problème similaire dans le scénario suivant :

• L’utilisateur se trouve dans un locataire Exchange Server non hybride.
• L’utilisateur tente d’afficher la disponibilité d’un utilisateur local dans un locataire hybride.
• La découverte automatique du locataire hybride pointe vers Exchange Online.

Par exemple, un utilisateur d’un locataire Exchange Server non autonome ne peut pas afficher les informations de disponibilité de l’utilisateur chanok@contoso.com local dans un locataire hybride, car la découverte automatique des contoso.com points vers Exchange Online (autodiscover-s.outlook.com).

Retour en haut

Échec de la requête avec l’état HTTP 401 : Non autorisé (certificat de signature manquant)

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

System.Net.WebException : la requête a échoué avec l’état HTTP 401 : Non autorisé.

Si vous exécutez l’applet de commande Test-OAuthConnectivity , le message d’erreur suivant s’affiche dans la sortie de la commande :

Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException : certificat de signature manquant.

Exécutez par exemple la commande suivante :

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

La TargetUri valeur du paramètre est l’URL du service de découverte automatique local. Un exemple de cette URL est https://mail.contoso.com/Autodiscover/Autodiscover.svc.

Cette erreur peut se produire si la configuration d’authentification a un certificat OAuth non valide.

Résolution

Pour résoudre ce problème, procédez comme suit :

1. Exécutez l’applet de commande PowerShell suivante dans Exchange Management Shell (EMS) pour obtenir l’empreinte du certificat OAuth utilisé par la configuration d’authentification :

   Get-AuthConfig | FL CurrentCertificateThumbprint
   

   Si la sortie de la commande ne renvoie pas d’empreinte numérique de certificat, passez à l’étape 3. Sinon, passez à l’étape suivante.

2. Exécutez l’applet de commande PowerShell suivante pour vérifier si le certificat identifié à l’étape 1 existe dans Exchange Server :

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

   Si Exchange Server ne retourne aucun certificat, passez à l’étape 3 pour créer un certificat.

   Si Exchange Server renvoie un certificat, mais que son empreinte est différente de celle que vous avez obtenue à l’étape 1, passez à l’étape 4. À l’étape 4, spécifiez l’empreinte numérique du certificat retourné par Exchange Server.

3. Exécutez l’applet de commande PowerShell suivante pour créer un certificat OAuth :

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

   Remarque

   Si vous êtes invité à remplacer le certificat SMTP, n’acceptez pas l’invite.

   À l’étape 4, spécifiez l’empreinte numérique du nouveau certificat que vous avez créé à cette étape.

4. Exécutez les applets de commande PowerShell suivantes pour mettre à jour la configuration d’authentification afin d’utiliser le certificat spécifié :

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

   Remarque

   Si vous êtes averti que la date d’effet est inférieure à 48 heures, choisissez de continuer.

5. Exécutez l’applet de commande PowerShell suivante pour supprimer toutes les références au certificat précédent :

   Set-AuthConfig -ClearPreviousCertificate
   

Retour en haut

Il manque à l’application un compte lié pour les rôles RBAC, ou le compte lié n’a aucune attribution de rôle RBAC, ou le compte des utilisateurs appelants est désactivé

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

System.Web.Services.Protocols.SoapException : il manque un compte lié à l’application pour les rôles RBAC, ou le compte lié n’a aucune attribution de rôle RBAC, ou le compte des utilisateurs appelants est désactivé.

Étapes de résolution des problèmes

Pour résoudre les problèmes mentionnés dans le message d’erreur, procédez comme suit. Après avoir effectué les étapes 1 et 2, vérifiez si le problème de disponibilité est résolu.

1. Vérifiez que l’entrée « Exchange Online-ApplicationAccount » existe dans la liste des applications partenaires Exchange Server. Pour vérifier, exécutez l’applet de commande PowerShell suivante dans la console de gestion Exchange (EMS) :

   Get-PartnerApplication | FL LinkedAccount
   

   L’entrée de compte doit apparaître sous la forme <root domain FQDN>/Users/Exchange Online-ApplicationAccount. Si l’entrée est listée, passez à l’étape 2.

   Si l’entrée de compte n’est pas répertoriée, ajoutez le compte en procédant comme suit :

   1. Exécutez les applets de commande PowerShell suivantes pour rechercher le compte dans l’annuaire Active Directory local :

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

      Si le compte est répertorié dans Active Directory, passez à l’étape 1b.

      Si le compte n’est pas répertorié dans Active Directory, il a peut-être été supprimé. Utilisez ADRestore pour vérifier l’état du compte et le restaurer, s’il est supprimé. Si vous avez restauré le compte à l’aide d’ADRestore, passez à l’étape 1b.

      Si vous ne pouvez pas restaurer le compte à l’aide d’ADRestore, suivez la procédure décrite dans Active Directory et domaines pour Exchange Server. Si cette procédure ne restaure pas le compte, créez-le manuellement dans Active Directory, puis passez à l’étape 1b.

   2. Exécutez l’applet de commande PowerShell suivante pour ajouter le compte Active Directory à la liste des applications partenaires Exchange Server :

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

   3. Redémarrez tous les serveurs Exchange locaux ou redémarrez IIS en exécutant la iisreset /noforce commande dans une fenêtre PowerShell ou d’invite de commandes sur chaque serveur.

2. Exécutez l’applet de commande PowerShell suivante dans EMS pour vérifier les affectations de contrôle d’accès en fonction du rôle (RBAC) :

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

   Par exemple, la sortie de la commande peut répertorier les attributions de rôles suivantes :

   

3. Recherchez dans les journaux suivants les problèmes indiqués dans le message d’erreur :

   • Journaux des services Web Exchange (EWS) qui se trouvent dans le dossier %ExchangeInstallPath%\Logging\Ews
   • Journaux des événements d’application
   • Journaux des événements système

4. Recherchez dans les journaux répertoriés à l’étape 3 un message d’erreur qui fait référence à AuthzInitializeContextFromSid. Si vous trouvez ce message d’erreur, consultez les ressources suivantes :

   • Certaines applications et API nécessitent l’accès aux informations d’autorisation sur les objets de compte

   • Échec des vérifications d’accès en raison d’AuthZ

Retour en haut

Les mots de passe entrés et stockés ne correspondent pas

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Exception d’erreur soap reçue. Les mots de passe entrés et stockés ne correspondent pas.

Le même message d’erreur s’affiche lorsque vous exécutez l’applet de commande suivante pour vérifier si l’utilisateur cloud peut récupérer un jeton de délégation pour la boîte aux lettres de l’utilisateur local :

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

Cause

Il existe une incohérence dans les informations d’identification Azure pour des utilisateurs du cloud spécifiques.

Résolution

Pour résoudre ce problème, procédez comme suit :

1. Réinitialisez le mot de passe de l’utilisateur cloud. Choisissez le même mot de passe ou un mot de passe différent.

2. Mettez à jour le nom d’utilisateur principal (UPN) de l’utilisateur cloud pour utiliser le onmicrosoft.com domaine, puis rétablissez l’UPN à son ancienne valeur. Par exemple, si l’UPN de l’utilisateur cloud est user@contoso.com, remplacez-le par l’UPN temporaire, user@contoso.mail.onmicrosoft.com, puis rétablissez l’UPN sur user@contoso.com. Pour ce faire, utilisez Azure AD PowerShell ou le service MSOL.

   • Azure AD PowerShell

     Exécutez les applets de commande Windows PowerShell suivantes dans cet ordre:

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

   • Utiliser le service MSOL

     Exécutez les applets de commande Windows PowerShell suivantes dans cet ordre:

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

3. Assurez-vous que la ImmutableId valeur de l’objet utilisateur local est null. Vérifiez la ImmutableId valeur de l’objet utilisateur local en exécutant la commande suivante dans Exchange Management Shell (EMS) :

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

   Utilisez l’une des méthodes suivantes, en fonction de la ImmutableId valeur .

   • La valeur ImmutableId est null

     Si la ImmutableId valeur est null, basculez sa valeur :

     1. Définissez le ImmutableId de l’objet de boîte aux lettres distant sur l’UPN de l’utilisateur cloud en exécutant l’applet de commande PowerShell suivante dans ems :

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

        Par exemple : Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

     2. Synchronisez la modification dans le cloud en exécutant les applets de commande PowerShell suivantes dans EMS :

        Import-Module ADSync
        Start-ADSyncSyncCycle -PolicyType Delta
        

        Pour vérifier que la ImmutableId valeur a été mise à jour, exécutez l’applet de commande PowerShell suivante dans Exchange Online PowerShell :

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

     3. Rétablissez la ImmutableId valeur null de l’objet de boîte aux lettres distante en exécutant l’applet de commande PowerShell suivante dans ems :

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

     4. Synchronisez la modification dans le cloud en exécutant l’applet de commande PowerShell suivante dans EMS :

        Start-ADSyncSyncCycle -PolicyType Delta
        

        Pour vérifier que la ImmutableId valeur a été mise à jour, exécutez l’applet de commande PowerShell suivante dans Exchange Online PowerShell :

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

   • La valeur ImmutableId n’est pas null

     Si la ImmutableId valeur n’est pas null, exécutez la commande suivante dans le système EMS pour définir la ImmutableId valeur sur null :

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

     Vous pouvez vérifier que la ImmutableId valeur a été mise à jour en exécutant l’applet de commande PowerShell suivante dans Exchange Online PowerShell :

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

Retour en haut

Le mot de passe doit être modifié ou le mot de passe du compte a expiré

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, vous trouvez l’un des messages d’erreur suivants.

Message d’erreur 1

Le mot de passe du compte a expiré

Message d’erreur 2

Le mot de passe doit être modifié

Le même message d’erreur s’affiche lorsque vous exécutez l’applet de commande suivante pour vérifier si l’utilisateur cloud peut récupérer un jeton de délégation pour la boîte aux lettres de l’utilisateur local :

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

Cette erreur peut se produire si une incohérence existe dans les informations d’identification Azure pour des utilisateurs cloud spécifiques.

Résolution

Sélectionnez la résolution qui correspond au message d’erreur.

Résolution du message d’erreur 1

Pour résoudre le problème, utilisez Azure AD PowerShell ou le service MSOL.

• Azure AD PowerShell

  Exécutez les applets de commande Windows PowerShell suivantes dans cet ordre:

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

• Utiliser le service MSOL

  Exécutez les applets de commande Windows PowerShell suivantes dans cet ordre:

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

Résolution du message d’erreur 2

Pour résoudre le problème, exécutez les applets de commande PowerShell suivantes :

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

Pour plus d’informations, consultez Impossible d’afficher les informations de disponibilité après la migration à partir d’Exchange en local.

Retour en haut

L’approvisionnement est nécessaire avant que le compte fédéré puisse être connecté

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

L’approvisionnement est nécessaire avant que le compte fédéré puisse être connecté. ErrorWin32InteropError

Vous obtenez également le même message d’erreur lorsque vous exécutez l’applet de commande suivante pour vérifier si l’utilisateur cloud peut récupérer un jeton de délégation pour la boîte aux lettres utilisateur locale :

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

Cette erreur peut se produire en cas d’incohérence dans la configuration des utilisateurs fédérés dans l’ID Microsoft Entra.

Résolution

Remarque

Si le problème affecte la plupart ou la totalité des utilisateurs du cloud de votre organisation, contactez le support Microsoft.

Pour résoudre le problème, mettez à jour le nom d’utilisateur principal (UPN) de l’utilisateur cloud pour utiliser le onmicrosoft.com domaine, puis revenez à son ancienne valeur (domaine fédéré). Par exemple, si l’UPN de l’utilisateur cloud est user@contoso.com, basculez-le vers l’UPN user@contoso.mail.onmicrosoft.com temporaire, puis revenez à user@contoso.com. Pour ce faire, utilisez l’une des approches suivantes (Azure AD PowerShell ou service MSOL) :

• Azure AD PowerShell

  Exécutez les applets de commande Windows PowerShell suivantes dans cet ordre:

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

• Utiliser le service MSOL

  Exécutez les applets de commande Windows PowerShell suivantes dans cet ordre:

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

Retour en haut

La requête a expiré

LID : 43404

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

La requête a expiré
La demande n’a pas pu être traitée à temps. Le délai d’expiration s’est produit pendant « Waiting-For-Request-Completion ».
Microsoft.Exchange.InfoWorker.Common.Availability.TimeoutExpiredException : la demande n’a pas pu être traitée à temps. Le délai d’expiration s’est produit pendant « Waiting-For-Request-Completion ».
Nom du serveur d’où provient l’exception : <nom du> serveur.

Vous obtenez également le même message d’erreur si vous exécutez l’applet de commande suivante pour vérifier si l’utilisateur cloud peut récupérer un jeton de délégation pour la boîte aux lettres utilisateur locale :

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

Cette erreur peut se produire en cas de problèmes réseau ou temporaires. Le message d’erreur est générique.

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Pour exclure les problèmes temporaires, vérifiez que l’utilisateur du cloud reçoit systématiquement le même message d’erreur lors de tentatives répétées d’obtention des informations de disponibilité de l’utilisateur local.

2. Vérifiez si vous pouvez récupérer un jeton de délégation lorsque vous exécutez chacune des applets de commande suivantes :

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

   Remarque : exécutez l’applet de commande Test-FederationTrust sur tous les serveurs Exchange locaux.

3. Vérifiez qu’Exchange Server dispose d’un accès Internet sortant aux deux ressources suivantes :

   • La passerelle de fédération Microsoft (ou un serveur d’autorisation, si vous utilisez OAuth)

   • URL de disponibilité pour Microsoft 365 : https://outlook.office365.com/ews/exchange.asmx

   Pour plus d’informations, consultez URL et plages d’adresses IP Microsoft 365 etConsidérations relatives au pare-feu pour la délégation fédérée.

4. Vérifiez que le compte système dans Exchange Server dispose d’un accès Internet aux URL suivantes. Procédez comme suit sur chaque serveur Exchange :

   1. Exécutez la commande PsExec suivante pour démarrer une session PowerShell qui démarre un navigateur web à partir du compte système :

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

   2. Testez l’accès du navigateur (sans OAuth) du compte système aux URL de la passerelle de fédération Microsoft suivantes :

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

        Le navigateur doit afficher une page xml.

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

        Le navigateur doit vous inviter à télécharger le fichier.

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

        Le navigateur doit afficher une liste des opérations prises en charge par ManageDelegation2.

   3. Testez l’accès du navigateur (OAuth) du compte système aux URL de serveur d’autorisation Microsoft suivantes :

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

        Le navigateur doit afficher une invite de connexion.

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

        Le navigateur doit afficher l’erreur de connexion , « Désolé, mais nous rencontrons des difficultés pour vous connecter ».

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

        Le navigateur doit afficher le code 400 Bad Requestd’état HTTP ou le message d’erreur de connexion, « Désolé, mais nous rencontrons des difficultés pour vous connecter ».

5. Obtenez les détails d’une demande de disponibilité en consultant les journaux des services Web Exchange (EWS) :

   1. Effectuez une demande de disponibilité à partir d’Exchange Online.

   2. Recherchez l’entrée dans les journaux EWS et vérifiez la valeur dans la time-taken colonne . Les journaux EWS se trouvent dans le dossier %ExchangeInstallPath%\Logging\Ews .

   3. Vérifiez les journaux IIS dans le dossier W3SVC1 du site web par défaut pour vérifier que la demande de disponibilité est enregistrée. Le chemin du dossier W3SVC1 est %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

Retour en haut

Le nom de membre spécifié n’est pas valide ou vide

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

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>Le nom de membre spécifié n’est pas valide ou vide. </psf :text></psf :internalerror></psf :error></S :Detail></S :Fault> Microsoft.Exchange.Net.WSTrust.SoapFaultException : exception d’erreur Soap reçue. sur Microsoft.Exchange.Net.WSTrust.SecurityTokenService.EndIssueToken(IAsyncResult asyncResult) à l’adresse Microsoft.Exchange.InfoWorker.Common.Availability.ExternalAuthenticationRequest.Complete(IAsyncResult asyncResult)

L’erreur peut se produire pour l’une des raisons suivantes :

• Incohérence dans l’ID Microsoft Entra pour les utilisateurs qui demandent un jeton de délégation
• Incohérence dans la configuration des utilisateurs fédérés dans les services de fédération Active Directory (AD FS)

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Mettez à jour le nom d’utilisateur principal (UPN) de l’utilisateur cloud pour utiliser le onmicrosoft.com domaine, puis rétablissez l’UPN à son ancienne valeur. Par exemple, si l’UPN de l’utilisateur cloud est user@contoso.com, remplacez-le par l’UPN temporaire, user@contoso.mail.onmicrosoft.compuis rétablissez l’UPN sur user@contoso.com. Pour ce faire, utilisez l’une des méthodes suivantes (Azure AD PowerShell ou service MSOL) :

   • Azure AD PowerShell

     Exécutez les applets de commande Windows PowerShell suivantes dans cet ordre:

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

   • Utiliser le service MSOL

     Exécutez les applets de commande Windows PowerShell suivantes dans cet ordre:

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

2. Vérifiez les règles, les points de terminaison et les journaux AD FS.

3. Recherchez une erreur liée à l’utilisateur ImmutableID du cloud dans la sortie de commande de l’applet de commande PowerShell suivante :

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

   Par exemple, la sortie de la commande peut contenir le message d’erreur suivant :

   « L’adresse e-mail « XGuNpVunD0afQeVNfyoUIQ== » n’est pas correcte. Utilisez ce format : nom d’utilisateur, signe @ suivi du nom de domaine. Par exemple : tonysmith@contoso.com ou tony.smith@contoso.com.
   + CategoryInfo : NotSpecified : (:) [Test-OrganizationRelationship], FormatException"

   Si vous recevez un message d’erreur similaire, utilisez l’une des méthodes suivantes pour vous assurer que la ImmutableId valeur est null (valeur vide) :

   • Si l’utilisateur cloud n’est pas synchronisé à partir d’un emplacement local, vérifiez la ImmutableId valeur en exécutant l’applet de commande PowerShell suivante dans Exchange Online PowerShell :

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

     Si la ImmutableId valeur n’est pas null, exécutez l’applet de commande PowerShell suivante dans Exchange Online PowerShell :

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

   • Si l’utilisateur cloud est synchronisé à partir d’un emplacement local, vérifiez la ImmutableId valeur de l’objet utilisateur local en exécutant la commande suivante dans Exchange Management Shell (EMS) :

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

     Utilisez l’une des méthodes suivantes, en fonction de la ImmutableId valeur :

     • La valeur ImmutableId est null

       Si la ImmutableId valeur est null, basculez sa valeur :

       1. Définissez le ImmutableId de l’objet de boîte aux lettres distant sur l’UPN de l’utilisateur cloud en exécutant l’applet de commande PowerShell suivante dans ems :

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

          Par exemple : Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

       2. Synchronisez la modification dans le cloud en exécutant les applets de commande PowerShell suivantes dans EMS :

          Import-Module ADSync
          Start-ADSyncSyncCycle -PolicyType Delta
          

          Pour vérifier que la ImmutableId valeur a été mise à jour, exécutez l’applet de commande PowerShell suivante dans Exchange Online PowerShell :

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

       3. Rétablissez la ImmutableId valeur null de l’objet de boîte aux lettres distante en exécutant l’applet de commande PowerShell suivante dans ems :

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

       4. Synchronisez la modification dans le cloud en exécutant l’applet de commande PowerShell suivante dans EMS :

          Start-ADSyncSyncCycle -PolicyType Delta
          

          Vérifiez que la ImmutableId valeur a été mise à jour. Pour ce faire, exécutez l’applet de commande PowerShell suivante dans Exchange Online PowerShell :

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

     • La valeur ImmutableId n’est pas null

       Si la ImmutableId valeur n’est pas null, exécutez la commande suivante dans le système EMS pour définir la ImmutableId valeur sur null :

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

       Pour vérifier que la ImmutableId valeur a été mise à jour, exécutez l’applet de commande PowerShell suivante dans Exchange Online PowerShell :

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

4. Vérifiez les paramètres de relation d’organisation. Pour plus d’informations, consultez Démystification de la disponibilité hybride.

5. Si le message d’erreur est généré pour un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local, procédez comme suit :

   1. Exécutez les applets de commande PowerShell suivantes :

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

   2. Recréez l’approbation de fédération. Pour plus d’informations, consultez Supprimer une approbation de fédération et Configurer une approbation de fédération.

Retour en haut

Le jeu de résultats contient trop d’entrées de calendrier

LID : 54796

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un autre utilisateur cloud. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Exception : le jeu de résultats contient trop d’entrées de calendrier. Taille autorisée = 1 000 ; taille réelle = 5009.

Cette erreur se produit si le nombre d’entrées de calendrier dans un même intervalle de temps dépasse 1 000 éléments. Une seule demande de disponibilité ne peut pas récupérer plus de 1 000 éléments.

Résolution

Supprimez certains éléments de calendrier du créneau horaire afin de ne pas dépasser la limite de 1 000 éléments pouvant être récupérés dans une seule demande de disponibilité.

Pour plus d’informations, voir Vous ne pouvez pas afficher les informations de disponibilité sur le calendrier d’un autre utilisateur dans Exchange Online.

Retour en haut

L’heure de début des heures de travail doit être inférieure ou égale à l’heure de fin

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’une liste de salles. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Exception : Microsoft.Exchange.InfoWorker.Common.InvalidParameterException : l’heure de début des heures de travail doit être inférieure ou égale à l’heure de fin.
Microsoft.Exchange.InfoWorker.Common.MeetingSuggestions.AttendeeWorkHours.Validate(TimeSpan startTime, TimeSpan endTime).

Cette erreur peut se produire si un ou plusieurs des paramètres de calendrier suivants pour une boîte aux lettres de salle dans une liste de salles ne sont pas valides :

• WorkingHoursStartTime
• WorkingHoursEndTime
• WorkingHoursTimeZone

L’heure de début des heures de travail doit être inférieure ou égale à l’heure de fin des heures de travail, et le fuseau horaire des heures de travail doit être défini.

Résolution

Pour résoudre ce problème, procédez comme suit :

1. Exécutez l’applet de commande PowerShell suivante pour vérifier les paramètres de calendrier de chaque boîte aux lettres dans la liste des salles afin d’identifier la boîte aux lettres de salle qui a des paramètres non valides :

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

2. Exécutez l’applet de commande PowerShell suivante pour définir les valeurs de paramètre requises pour une boîte aux lettres de salle :

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

   Pour plus d’informations, consultez Set-MailboxCalendarConfiguration.

Retour en haut

Échec de la requête avec l’état HTTP 401 : Non autorisé (le jeton a une signature non valide)

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

System.Net.WebException : la requête a échoué avec l’état HTTP 401 : Non autorisé.

Lorsque vous exécutez l’applet de commande PowerShell suivante pour tester l’authentification OAuth :

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

Vous recevez la sortie de commande suivante :

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".

Remarque : la TargetUri valeur du paramètre dans la commande Test-OAuthConnectivity est une URL EWS (Exchange Web Services) externe, telle que https://mail.contoso.com/ews/exchange.asmx.

Cette erreur peut se produire si les paramètres du serveur d’autorisation Microsoft ne sont pas valides.

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Actualisez les métadonnées d’autorisation sur le serveur d’autorisation Microsoft spécifié approuvé par Exchange. Exécutez l’applet de commande PowerShell suivante dans ems (local) :

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

   Attendez environ 15 minutes que la commande prenne entièrement effet, ou redémarrez IIS en exécutant la iisreset /noforce commande dans une fenêtre PowerShell ou d’invite de commandes sur chaque serveur Exchange Server.

2. Vérifiez les paramètres du serveur d’autorisation Microsoft dans votre organisation Exchange en exécutant l’applet de commande PowerShell suivante dans EMS :

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

   La sortie de commande suivante est un exemple de paramètres valides :

   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 les paramètres du serveur d’autorisation Microsoft ne sont pas valides, essayez de réexécuter l’Assistant Configuration hybride pour rétablir les valeurs valides des paramètres du serveur d’autorisation Microsoft.

Retour en haut

Échec de la requête avec l’état HTTP 401 : Non autorisé (clé introuvable)

Problème

Vous avez un utilisateur local qui ne peut pas afficher les informations de disponibilité d’un utilisateur cloud. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

System.Net.WebException : la requête a échoué avec l’état HTTP 401 : Non autorisé.

Lorsque vous exécutez l’applet de commande PowerShell suivante dans EMS pour tester l’authentification OAuth :

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

Vous recevez la sortie de commande suivante :

System.Net.WebException : le serveur distant a renvoyé une erreur : (401) Non autorisé.
Erreur : Impossible d’obtenir le jeton à partir du serveur d’authentification. Code d’erreur : « invalid_client ». Description : 'AADSTS70002 :
Erreur lors de la validation des informations d’identification. AADSTS50012 : l’assertion du client contient une signature non valide. [Raison : la clé est introuvable., Empreinte numérique de la clé utilisée par le client : '<thumbprint>'.

Cette erreur peut se produire si le certificat OAuth dans Exchange Server n’existe pas dans Exchange Online.

Résolution

Pour résoudre le problème, procédez comme suit :

1. Déterminez si votre certificat OAuth Exchange Server local existe dans votre organisation Exchange Online :

   1. Exécutez l’applet de commande PowerShell suivante dans Exchange Management Shell (EMS) pour obtenir le certificat OAuth dans Exchange Server :

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

      La sortie de la commande contient la Thumbprint valeur .

   2. Exécutez les applets de commande PowerShell suivantes pour obtenir le certificat OAuth Exchange Online à l’aide du service MSOL :

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

      Si la valeur du Value paramètre dans la sortie de commande est vide, un certificat OAuth n’existe pas dans Exchange Online. Dans ce cas, passez à l’étape 3 pour charger le certificat local dans Exchange Online.

      Si la valeur du Value paramètre n’est pas vide, enregistrez la valeur dans un fichier qui a une extension « .cer ». Ouvrez le fichier dans l’outil Gestionnaire de certificats Microsoft pour afficher le certificat OAuth Exchange Online. Comparez la Thumbprint valeur du certificat Exchange Online à l’empreinte numérique du certificat local que vous avez obtenue à l’étape 1a. Si les valeurs d’empreinte correspondent, passez à l’étape 4. Si les valeurs de l’empreinte numérique ne correspondent pas, choisissez l’une des options suivantes :

      • Passez à l’étape 2 pour remplacer le certificat local existant par le certificat Exchange Online.

      • Passez à l’étape 3 pour remplacer le certificat Exchange Online existant par le certificat local.

2. Remplacez le certificat local existant par le certificat Exchange Online :

   1. Exécutez l’applet de commande PowerShell suivante pour mettre à jour l’empreinte numérique du certificat local :

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

      Si vous êtes informé que la date d’entrée en vigueur du certificat est inférieure à 48 heures, acceptez l’invite de continuer.

   2. Exécutez l’applet de commande PowerShell suivante pour publier le certificat local :

      Set-AuthConfig -PublishCertificate  
      

   3. Exécutez l’applet de commande PowerShell suivante pour supprimer toutes les références au certificat précédent :

      Set-AuthConfig -ClearPreviousCertificate 
      

   4. Passez à l’étape 4.

3. Exportez le certificat d’autorisation local, puis chargez le certificat dans votre organisation Exchange Online.

4. Exécutez l’applet de commande PowerShell suivante pour vérifier si le SPN dans la configuration de l’authentification locale est 00000002-0000-0ff1-ce00-000000000000:

   Get-AuthConfig | FL ServiceName
   

   Si la valeur du SPN est différente, mettez à jour le SPN en exécutant l’applet de commande PowerShell suivante :

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

Retour en haut

Échec de la requête web de proxy : la réponse n’est pas un xml bien formé

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Échec de la requête web proxy., exception interne : la réponse n’est pas un xml bien formé

Si vous exécutez le test synchronisation, notification, disponibilité et réponses automatiques pour l’utilisateur local, vous recevez le message d’erreur suivant :

La réponse reçue du service ne contenait pas de code XML valide

Ces erreurs peuvent se produire pour l’une des raisons suivantes :

• Problème de services web Exchange externes (EWS)
• Configuration incorrecte des périphériques réseau, comme un proxy inverse ou un pare-feu

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Vérifiez si une demande de disponibilité d’Exchange Online peut atteindre IIS sur un serveur Exchange. Effectuez une requête de disponibilité, puis recherchez dans les journaux IIS des entrées qui ont un code 200 OK d’état HTTP ou 401 Unauthorized au moment de la requête. Ces entrées indiquent que la demande de disponibilité a atteint IIS. Remarque : Les horodatages des journaux IIS utilisent l’heure UTC.

   Si vous ne trouvez pas ces entrées, vérifiez les journaux du proxy inverse et du pare-feu pour déterminer où la demande de disponibilité est bloquée.

2. Effectuez une requête de disponibilité, puis recherchez dans le journal des applications Exchange Server dans l’Observateur d’événements Windows les entrées qui ont été effectuées au moment de la requête afin d’identifier la cause du problème.

Retour en haut

Impossible de se connecter au serveur distant

Problème

Vous avez un utilisateur local qui ne peut pas afficher les informations de disponibilité d’un utilisateur cloud. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Échec de la communication avec https://login.microsoftonline.com/extSTS.srf., exception interne : impossible de se connecter au serveur distant.

Cette erreur peut se produire si un ou plusieurs serveurs Exchange ne peuvent pas se connecter à une URL de passerelle de fédération Microsoft.

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Exécutez les applets de commande PowerShell suivantes dans Exchange Management Shell (EMS) pour vérifier si vous pouvez récupérer un jeton de délégation :

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

2. Vérifiez que vos serveurs Exchange locaux disposent d’un accès Internet sortant aux deux ressources suivantes :

   • La passerelle de fédération Microsoft ou le serveur d’autorisation Microsoft si vous utilisez l’authentification OAuth.

   • URL de disponibilité pour Microsoft 365 : https://outlook.office365.com/ews/exchange.asmx.

   Pour plus d’informations, consultez URL et plages d’adresses IP Microsoft 365 etConsidérations relatives au pare-feu pour la délégation fédérée.

3. Vérifiez que le compte système dans Exchange Server dispose d’un accès Internet aux URL suivantes. Suivez ces étapes sur tous les serveurs Exchange de votre organisation :

   1. Exécutez la commande PsExec suivante pour démarrer une session PowerShell qui lance un navigateur web à partir du compte système :

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

   2. Testez l’accès du navigateur (sans authentification OAuth) du compte système aux URL de la passerelle de fédération Microsoft suivantes :

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

        Le navigateur doit afficher une page xml.

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

        Le navigateur doit vous inviter à télécharger le fichier.

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

        Le navigateur doit afficher une liste des opérations prises en charge par ManageDelegation2.

   3. Testez l’accès au navigateur (authentification OAuth) à partir du compte système vers les URL de serveur d’autorisation Microsoft suivantes :

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

        Le navigateur doit afficher une invite de connexion.

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

        Le navigateur doit afficher le message d’erreur de connexion, « Désolé, mais nous rencontrons des difficultés pour vous connecter ».

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

        Le navigateur doit afficher le code 400 Bad Request d’état HTTP ou le message d’erreur de connexion, « Désolé, mais nous rencontrons des difficultés pour vous connecter ».

Retour en haut

Échec de la découverte automatique pour l’adresse e-mail : Impossible de résoudre le nom distant

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Échec de la découverte automatique pour l’adresse e-mail de l’adresse e-mail <de l’utilisateur avec l’erreur System.Net.WebException : Le nom distant n’a pas pu être résolu : «< nom> d’hôte local ».>

Cette erreur peut se produire si l’URL du point de terminaison de découverte automatique locale ou les paramètres DNS publics sont incorrects.

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Exécutez les applets de commande PowerShell suivantes dans Exchange Online PowerShell pour obtenir la valeur du TargetAutodiscoverEpr paramètre :

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

   Par exemple, si la valeur du nom d’hôte local dans le message d’erreur est mail.contoso.com, l’URL du point de terminaison de découverte automatique est susceptible d’être https://autodiscover.contoso.com/autodiscover/autodiscover.svc.

   Si la valeur du TargetAutodiscoverEpr paramètre est correcte, passez à l’étape 3. Sinon, passez à l’étape 2.

2. Mettez à jour l’URL du point de terminaison de découverte automatique à l’aide de l’une des méthodes suivantes :

   • Exécutez l’Assistant Configuration hybride (HCW) pour restaurer le point de terminaison de découverte automatique par défaut.

   • Mettez à jour manuellement le DiscoveryEndpoint paramètre ou le TargetAutodiscoverEpr paramètre en exécutant l’une des applets de commande PowerShell suivantes :

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

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

3. Assurez-vous que le nom d’hôte local dans le message d’erreur (par exemple : mail.contoso.com) peut être résolu dans le DNS public. L’entrée DNS pour le nom d’hôte doit pointer vers le service de découverte automatique local à l’URL du point de terminaison de découverte automatique.

   Remarque : Si vous ne pouvez pas résoudre le problème et que vous souhaitez une solution de contournement temporaire, exécutez l’une des applets de commande PowerShell suivantes pour mettre à jour manuellement la valeur du TargetSharingEpr paramètre vers l’URL EWS (Exchange Web Services) externe. L’URL EWS externe doit ressembler https://<EWS hostname>/ews/exchange.asmx et être résolu dans DNS.

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

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

   Remarque

   Si vous définissez la valeur du TargetSharingEpr paramètre, la boîte aux lettres cloud contourne la découverte automatique et se connecte directement au point de terminaison EWS.

Retour en haut

Échec de l’obtention d’ASURL. Erreur 8004010F

Problème

Vous avez un utilisateur local qui ne peut pas afficher les informations de disponibilité d’un utilisateur cloud. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Échec de l’obtention d’ASURL. Erreur 8004010F.

Il s’agit d’une erreur générale liée au service de découverte automatique.

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Assurez-vous que la découverte automatique pour l’utilisateur affecté retourne l’URL des services Web Exchange (EWS) de l’utilisateur.

2. Exécutez le test de configuration automatique de l’e-mail dans le client Outlook de l’utilisateur affecté pour vous assurer que la découverte automatique renvoie l’URL EWS de l’utilisateur.

3. Assurez-vous que la disponibilité fonctionne entre les utilisateurs locaux hébergés sur différents serveurs Exchange.

4. Si vous avez des équilibreurs de charge, vérifiez si les équilibreurs de charge sont à l’origine du problème. Pour ce faire, modifiez le fichier Hôtes Windows (sur l’ordinateur sur lequel le client Outlook de l’utilisateur est installé) pour contourner les équilibreurs de charge et pointer vers un serveur d’accès au client spécifique.

5. Si la disponibilité fonctionne entre les utilisateurs locaux, vérifiez si tous les serveurs Exchange locaux disposent d’un accès sortant aux URL microsoft 365 et aux plages d’adresses IP.

6. Vérifiez si chaque serveur Exchange peut récupérer un jeton de délégation. Pour ce faire, exécutez l’applet de commande PowerShell suivante dans EMS sur tous les serveurs Exchange locaux :

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

   Si la commande ne parvient pas à récupérer un jeton de délégation, vérifiez si le serveur peut se connecter à Office 365 au niveau du proxy ou du pare-feu.

Retour en haut

Échec de la requête web proxy : l’objet a été déplacé

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Échec de la requête web de proxy. , exception interne : System.Net.WebException : la requête a échoué avec le message d’erreur : Objet déplacé.

Cette erreur peut se produire si la valeur du TargetSharingEpr paramètre dans les paramètres de l’organisation est définie sur une URL de point de terminaison EWS (Exchange Web Services) incorrecte.

Vous pouvez exécuter les applets de commande PowerShell suivantes pour obtenir la TargetSharingEpr valeur du paramètre à partir des paramètres de l’organisation (connecteur intra-organisation ou relation d’organisation) :

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

Vérifiez que la valeur du TargetSharingEpr paramètre ne se résout pas dans le DNS public.

Remarque : L’Assistant Configuration hybride (HCW) ne définit pas de valeur pour le TargetSharingEpr paramètre, sauf si vous sélectionnez Utiliser la technologie hybride moderne Exchange pour installer un agent hybride hybride. Dans ce scénario, le HCW définit le paramètre sur TargetSharingEpr une valeur de point de terminaison d’URL EWS externe qui ressemble à https://<GUID>.resource.mailboxmigration.his.msappproxy.net/ews/exchange.asmx. Vous pouvez également définir la valeur du TargetSharingEpr paramètre manuellement. Si la TargetSharingEpr valeur est définie sur un point de terminaison, Outlook contourne la découverte automatique et se connecte directement à ce point de terminaison.

Résolution

Pour résoudre le problème, exécutez l’une des commandes suivantes pour mettre à jour manuellement la valeur du TargetSharingEpr paramètre vers une URL EWS externe qui se résout dans DNS :

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

Retour en haut

La demande a été abandonnée : Impossible de créer un canal sécurisé SSL/TLS

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local, ou vice versa. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

La demande a été abandonnée : Impossible de créer un canal sécurisé SSL/TLS.

Cause 1 : L’utilisateur cloud ne peut pas afficher les informations de disponibilité d’un utilisateur local

Le problème peut se produire si TLS 1.2 est mal configuré ou désactivé dans un point de terminaison local auquel Microsoft 365 se connecte, tel qu’Exchange Server ou un pare-feu.

Cause 2 : L’utilisateur local ne peut pas afficher les informations de disponibilité d’un utilisateur cloud

Le problème peut également se produire pour l’une des raisons suivantes :

• Le certificat Microsoft 365 (outlook.office365.com) est manquant dans le magasin d’autorités de certification (CA) racine approuvée.
• Il existe une incompatibilité de suite Cypher .
• Autres problèmes SSL/TLS.

Étapes de résolution des problèmes

Utilisez les outils suivants pour diagnostiquer les problèmes liés au protocole TLS 1.2 local :

• Exécutez le test du serveur SSL dans Microsoft Remote Connectivity Analyzer.
• Exécutez le script HealthChecker dans Exchange Management Shell (EMS) sur chaque serveur Exchange.

Pour plus d’informations sur la configuration TLS, consultez Meilleures pratiques en matière de configuration TLS d’Exchange Server et Préparation de TLS 1.2.

Pour plus d’informations sur la vérification des certificats dans le magasin d’autorité de certification racine approuvée, consultez Afficher les certificats avec le composant logiciel enfichable MMC.

Pour plus d’informations sur les suites de chiffrement TLS prises en charge, consultez Suites de chiffrement TLS prises en charge par Microsoft 365.

Retour en haut

L’utilisateur spécifié par le contexte utilisateur dans le jeton n’existe pas

Problème

Vous avez un utilisateur local qui ne peut pas afficher les informations de disponibilité d’un utilisateur cloud. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

L’utilisateur spécifié par le contexte utilisateur dans le jeton n’existe pas. error_category="invalid_user ». 401 : Non autorisé.

Vous obtenez le même message d’erreur si vous exécutez l’applet de commande PowerShell Test-OAuthConnectivity .

L’erreur peut se produire si la boîte aux lettres de l’utilisateur local et l’objet utilisateur de messagerie correspondant dans l’ID Microsoft Entra ne sont pas synchronisés. Tant qu’ils ne sont pas synchronisés, l’objet utilisateur de messagerie dans l’ID Microsoft Entra peut ne pas être approvisionné.

Résolution

Pour résoudre le problème, utilisez Microsoft Entra Connect pour synchroniser l’utilisateur local et l’objet mail-utilisateur correspondant dans l’ID Microsoft Entra.

Retour en haut

Le composant de nom d’hôte de la valeur de revendication d’audience n’est pas valide

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Le composant hostname de la valeur de revendication d’audience « https://< hybrid.domain.com> » n’est pas valide ; error_category="invalid_resource »

L’erreur peut se produire pour l’une des raisons suivantes.

Cause 1

Le déchargement SSL et l’authentification OAuth sont tous deux activés. Le déchargement SSL ne fonctionne pas si l’authentification OAuth est activée.

Cause 2

Un périphérique réseau devant Exchange Server bloque les demandes de disponibilité.

Solution

Solution de contournement pour cause 1

Sélectionnez l’une des solutions de contournement suivantes :

• Désactivez le déchargement SSL pour les services Web Exchange (EWS) et la découverte automatique dans l’environnement local. Pour plus d’informations, consultez Configuration du déchargement SSL pour la découverte automatique et Configuration du déchargement SSL pour EWS et paramètres SSL par défaut.

• Exécutez l’applet de commande PowerShell suivante pour désactiver l’authentification OAuth en désactivant le connecteur intra-organisation cloud :

  Set-IntraOrganizationConnector "HybridIOC*" -Enabled $false
  

  Lorsque le connecteur intra-organisation est désactivé, l’authentification DAuth est activée via la relation d’organisation. Pour vérifier la relation d’organisation, exécutez l’applet de commande PowerShell suivante :

  Get-OrganizationRelationship
  

  Pour plus d’informations sur les paramètres de relation d’organisation, consultez Démystification de la disponibilité hybride.

Résolution pour cause 2

Configurez l’appareil réseau devant Exchange pour ne pas bloquer les demandes de disponibilité.

Retour en haut

Échec de la requête web de proxy avec l’état HTTP 503 : Service indisponible

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Échec de la requête web proxy, exception interne : System.Net.WebException : La requête a échoué avec l’état HTTP 503 : Service indisponible...

Cette erreur peut se produire en cas d’arrêt d’un service Microsoft Windows, d’un composant serveur, d’un pool d’applications IIS ou d’un point de terminaison mal configuré.

Étapes de résolution des problèmes

Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Assurez-vous que les services Windows requis par Exchange Server sont en cours d’exécution. Pour vérifier l’état des services, exécutez l’applet de commande PowerShell suivante sur chaque serveur Exchange de votre organisation :

   Test-ServiceHealth
   

   Utilisez la console Services pour démarrer tous les services arrêtés requis par Exchange Server.

2. Vérifiez que les composants Exchange Server requis sont actifs. Pour vérifier l’état des composants, exécutez l’applet de commande PowerShell suivante sur chaque serveur Exchange de votre organisation :

   Get-ServerComponentState <server name>
   

   Pour activer un composant inactif, utilisez l’applet de commande PowerShell Set-ServerComponentState .

3. Assurez-vous que les pools d’applications IIS suivants pour les services Web Exchange (EWS) et la découverte automatique sont démarrés :

   • MSExchangeServicesAppPool
   • MSExchangeSyncAppPool
   • MSExchangeAutodiscoverAppPool

4. Testez si le point de terminaison de découverte automatique est valide. Procédez comme suit :

   1. Exécutez les applets de commande PowerShell suivantes pour obtenir l’URL du point de terminaison de découverte automatique à partir des valeurs du DiscoveryEndpoint paramètre ou TargetAutodiscoverEpr :

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

   2. Accédez à l’URL du point de terminaison de découverte automatique dans un navigateur web ou exécutez l’applet Invoke-WebRequest -Uri "<endpoint URL>" -Verbose de commande PowerShell pour vous assurer que l’URL est valide. De préférence, vérifiez l’URL à partir d’un réseau externe.

5. Testez si l’URL EWS est valide en procédant comme suit :

   1. Exécutez les applets de commande PowerShell suivantes pour obtenir l’URL EWS à partir de la TargetSharingEpr valeur de paramètre dans les paramètres de l’organisation :

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

   b. Accédez à l’URL EWS dans un navigateur web ou exécutez l’applet Invoke-WebRequest -Uri "<endpoint URL>" -Verbose de commande PowerShell pour vous assurer que l’URL est valide. De préférence, vérifiez l’URL à partir d’un réseau externe.

6. Vérifiez les journaux IIS pour les demandes de disponibilité qui retournent le code 503 Service Unavailabled’état HTTP :

   1. Effectuez une demande de disponibilité à partir d’Exchange Online.

   2. Recherchez les entrées de code 503 Service Unavailable d’état HTTP dans les journaux IIS du dossier W3SVC1 pour le site web par défaut sur chaque serveur Exchange. Le chemin du dossier W3SVC1 est %SystemDrive%\inetpub\logs\LogFiles\W3SVC1. Ces entrées peuvent aider à identifier le serveur qui rencontre le problème.

   3. Si la demande de disponibilité n’est pas enregistrée dans le dossier W3SVC1 , vérifiez si la requête est enregistrée dans les journaux d’erreurs dans le dossier HTTPERR sur chaque serveur Exchange. Le chemin du dossier HTTPERR est %SystemRoot%\System32\LogFiles\HTTPERR. Si la demande de disponibilité est consignée dans les journaux HTTPERR , recherchez les paramètres IIS mal configurés.

7. Vérifiez l’en-tête de la réponse du serveur que vous recevez lorsque vous vous connectez à l’URL EWS locale pour vérifier qu’IIS (pas un autre serveur web) a envoyé la réponse. Pour ce faire, exécutez les commandes suivantes dans une session PowerShell qui n’est pas connectée à EWS local (n’exécutez pas les commandes dans Exchange Management Shell) :

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

   Par exemple, si vous voyez « Microsoft-HTTPAPI/2.0 » dans la sortie de commande au lieu de « Microsoft -IIS/10.0 », il est probable qu’un service de proxy d’application web (et non IIS) ait répondu à la requête. Vérifiez si le service WAP est arrêté.

Retour en haut

Échec de la requête web de proxy avec l’état HTTP 504 : Délai d’expiration de la passerelle

LID : 43532

Problème

Vous avez un utilisateur cloud qui ne peut pas afficher les informations de disponibilité d’un utilisateur local. Lorsque vous diagnostiquez le problème, le message d’erreur suivant s’affiche :

Échec de la requête web proxy, exception interne : La requête a échoué avec l’état HTTP 504 : Délai d’expiration de la passerelle...

Cette erreur peut se produire si un agent hybride de votre organisation n’est pas configuré de manière incorrecte.

Résolution

Pour résoudre le problème, procédez comme suit. Après avoir effectué chaque étape, vérifiez si le problème de disponibilité est résolu.

1. Vérifiez la valeur du TargetSharingEpr paramètre dans les paramètres de l’organisation. La valeur doit ressembler à https://<GUID>.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx. Pour déterminer la valeur du TargetSharingEpr paramètre, exécutez les applets de commande PowerShell suivantes :

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

   Si la valeur du TargetSharingEpr paramètre est incorrecte :

   1. Exécutez l’Assistant Configuration hybride (HCW), puis sélectionnez Utiliser la topologie hybride Exchange Classic.

   2. Réexécutez le HCW, puis sélectionnez Utiliser la topologie hybride moderne Exchange. Cette procédure force le HCW à réinitialiser la valeur du TargetSharingEpr paramètre.

2. Vérifiez l’état du service hybride Microsoft sur le serveur sur lequel l’agent hybride est installé. Si le service est arrêté, démarrez-le.

3. Vérifiez l’état de l’agent hybride. Si l’état est Inactif :

   1. Exécutez l’Assistant Configuration hybride (HCW), puis sélectionnez Utiliser la topologie hybride Exchange Classic.

   2. Réexécutez le HCW, puis sélectionnez Utiliser la topologie hybride moderne Exchange. Cette procédure force le HCW à réinstaller l’agent hybride.

   3. Installez le module PowerShell de l’agent hybride, puis exécutez l’applet de commande PowerShell Get-HybridApplication pour rechercher l’URL interne vers laquelle l’agent hybride pointe.

4. Accédez à l’URL interne que vous avez trouvée à l’étape 3. Résolvez les erreurs que vous trouvez, telles que les erreurs de certificat.

5. Configurez l’agent hybride pour diriger les requêtes vers un équilibreur de charge au lieu d’un serveur exécutant Microsoft Exchange Server afin d’exclure les problèmes qui peuvent exister sur ce serveur.

6. Vérifiez que l’agent hybride prend en charge les demandes de disponibilité et la migration de boîtes aux lettres.

Retour en haut