L’utilisateur ne peut pas afficher les informations de disponibilité d’un utilisateur distant dans un déploiement hybride de Exchange Server

Numéro de la base de connaissances d’origine : 2667844

Remarque

L’Assistant Configuration hybride inclus dans le console de gestion Exchange dans Microsoft Exchange Server 2010 n’est plus pris en charge. Par conséquent, vous ne devez plus utiliser l’ancien Assistant Configuration hybride. Utilisez plutôt l’Assistant Configuration hybride De Microsoft 365 disponible à l’adresse https://aka.ms/HybridWizard. Pour plus d’informations, consultez Assistant Configuration hybride Microsoft 365 pour Exchange 2010.

Symptômes

Vous disposez d’un déploiement hybride de Microsoft Exchange Server et de Microsoft Exchange Online locaux dans Microsoft 365 dans lequel votre serveur hybride s’exécute Exchange Server 2010. Toutefois, les utilisateurs ne peuvent pas afficher les informations de disponibilité d’un utilisateur distant. Lorsqu’un utilisateur tente d’afficher les informations de disponibilité d’un utilisateur distant, les informations de disponibilité ne s’affichent pas. Au lieu de cela, l’utilisateur peut rencontrer un ou plusieurs des symptômes suivants :

  • Les informations de disponibilité de l’utilisateur distant sont affichées sous forme de signe numéro (#) dans le calendrier.

  • Dans Outlook Web App, « erreur 5037 » s’affiche.

  • Les fichiers Microsoft Outlook <FileName>-fb.log et <FileName>-as.log contiennent un message d’erreur semblable au suivant :

    <FreeBusyResponse><ResponseMessage ResponseClass="Error"><MessageText>L’appelant n’a pas accès aux données de disponibilité.</MessageText><ResponseCode>ErrorNoFreeBusyAccess</ResponseCode><DescriptiveLinkKey>0</DescriptiveLinkKey><MessageXml><ExceptionType xmlns=""http://schemas.microsoft.com/exchange/services/2006/errors>Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException</ExceptionType><ExceptionCode xmlns="http://schemas.microsoft.com/exchange/services/2006/errors>5037</ExceptionCode ExceptionServerName><xmlns=""http://schemas.microsoft.com/exchange/services/2006/errorsServerName<>/ExceptionServerName><ResponseSource xmlns=""http://schemas.microsoft.com/exchange/services/2006/errors<>https://\<Server>.outlook.com/EWS/Exchange.asmx/WSSecurity/ResponseSource></MessageXml></ResponseMessage><FreeBusyView><FreeBusyViewType xmlns="">http://schemas.microsoft.com/exchange/services/2006/typesNone</FreeBusyViewType></FreeBusyView></FreeBusyResponse>

Par exemple, un utilisateur Microsoft 365 ne peut pas afficher les informations de disponibilité d’un utilisateur local. Toutefois, d’autres utilisateurs peuvent afficher les informations de disponibilité pour ce même utilisateur local.

Cause

Ce problème se produit si le nom de domaine de l’adresse SMTP (Simple Mail Transfer Protocol) de l’utilisateur qui tente d’afficher les informations de disponibilité n’est pas inclus parmi les noms de domaine dans la relation organization. Par exemple, lorsque vous exécutez l’applet de commande Test-OrganizationRelationship, la sortie suivante s’affiche :

RunspaceId : a6c3799f-2ecd-4d79-ae4b-6c470ddd1dee
Identité:
Id : LocalFederatedDomainsAreMissingFromTheRemoteOrganizationRelationsipDomains
État : Avertissement
Description : Il existe des domaines fédérés localement qui ne sont pas présents dans la liste des domaines pour l’objet de relation organization distant.
IsValid : True

Cela se produit si le domaine SMTP n’a pas été ajouté manuellement à la relation organization. Cela peut également se produire si les conditions suivantes sont remplies :

  • Le compte d’utilisateur Microsoft 365 a été créé avant la mise à niveau de l’environnement local vers Exchange Server 2010.
  • Vous avez utilisé l’Assistant Configuration hybride dans Exchange Server 2010 dans l’environnement local pour configurer l’approbation de fédération. Par exemple, le nom de domaine de l’utilisateur Microsoft 365 est contoso.com.

Dans ce scénario, le compte d’utilisateur Microsoft 365 n’a @contoso.mail.onmicrosoft.com pas comme adresse proxy. La demande adressée à l’environnement local utilise @contoso.com au lieu de pour le compte d’utilisateur @contoso.mail.onmicrosoft.com Microsoft 365. La demande est rejetée, car la relation organization dans l’environnement local n’y a contoso.com pas été ajoutée.

Résolution

Pour résoudre ce problème, modifiez la relation organization dans l’environnement local pour inclure le domaine SMTP de l’utilisateur qui rencontre le problème. Pour cela, appliquez l’une des méthodes suivantes :

Méthode 1 : Utiliser console de gestion Exchange

  1. Sur le serveur Exchange local, ouvrez console de gestion Exchange, puis sélectionnez Configuration de l’organisation sous Microsoft Exchange local.
  2. Sélectionnez l’onglet Relations de l’organisation, puis affichez les propriétés de la relation organization.
  3. Sélectionnez l’onglet Organisation externe, tapez le nom de domaine fédéré dans la zone Domaines fédérés de la organization Exchange externe, puis sélectionnez Ajouter.
  4. Répétez l’étape 3 pour chaque domaine que vous souhaitez ajouter.
  5. Sélectionnez OK.

Méthode 2 : Utiliser Exchange Management Shell

  1. Sur le serveur local, ouvrez Exchange Management Shell.

  2. Configurez la relation organization en tant que variable. Par exemple, exécutez la commande suivante :

    $OrgRel = Get-OrganizationRelationship Contoso
    
  3. Ajoutez les noms de domaine supplémentaires souhaités à la variable. Par exemple, exécutez la commande suivante :

    $OrgRel.DomainNames += "contoso.com"
    
  4. Mettez à jour la relation organization à l’aide de la nouvelle valeur de noms de domaine. Par exemple, exécutez la commande suivante :

    Set-OrganizationRelationship $OrgRel.Name -DomainName $OrgRel.DomainNames
    

Informations supplémentaires

Pour identifier le problème dans Microsoft 365, procédez comme suit :

  1. Connectez-vous à Exchange Online à l’aide de Remote PowerShell. Pour plus d’informations sur la procédure à suivre, consultez Se connecter à Exchange Online PowerShell.

  2. Comparez l’adresse SMTP de l’utilisateur avec la relation organization. Pour ce faire, exécutez la commande suivante :

    if ( (Get-OrganizationRelationship).DomainNames -contains (Get-Mailbox user).PrimarySmtpAddress.Split("@")[1]) { write-host "The domain was found" -ForegroundColor Green } else { write-host (Get-Mailbox user).PrimarySmtpAddress.Split("@")[1] "was not found" -ForegroundColor Yellow}
    

    Remarque

    Vous pouvez également comparer chaque domaine répertorié dans les domaines acceptés avec les noms de domaine qui se trouvent dans la relation organization. Pour ce faire, exécutez la commande suivante :

    Get-AcceptedDomain | ForEach-Object { if ( (Get-OrganizationRelationship).DomainNames -contains $_.DomainName) { write-host $_.DomainName "was found" -ForegroundColor Green } else { write-host $_.DomainName "was not found" -ForegroundColor Yellow} }
    

Encore besoin d’aide ? Accédez à Microsoft Community ou aux forums TechNet sur Exchange.

Démarrez le guide pour résoudre ce problème.