L'utente non può visualizzare informazioni sulla disponibilità per un utente remoto in una distribuzione ibrida di Exchange Server

Numero KB originale: 2667844

Nota

La configurazione guidata ibrida inclusa nel Exchange Management Console in Microsoft Exchange Server 2010 non è più supportata. Pertanto, non è più consigliabile usare la configurazione guidata ibrida precedente. Usare invece la procedura guidata configurazione ibrida di Microsoft 365 disponibile all'indirizzo https://aka.ms/HybridWizard. Per altre informazioni, vedere Configurazione guidata ibrida di Microsoft 365 per Exchange 2010.

Sintomi

È disponibile una distribuzione ibrida di Microsoft Exchange Server e Microsoft Exchange Online locali in Microsoft 365 in cui il server ibrido è in esecuzione Exchange Server 2010. Tuttavia, gli utenti non possono visualizzare le informazioni sulla disponibilità per un utente remoto. Quando un utente tenta di visualizzare le informazioni sulla disponibilità per un utente remoto, le informazioni sulla disponibilità non vengono visualizzate. L'utente potrebbe invece riscontrare uno o più dei sintomi seguenti:

  • Le informazioni sulla disponibilità per l'utente remoto vengono visualizzate come caratteri di segno di numero (#) nel calendario.

  • In Outlook Web App viene visualizzato "errore 5037".

  • I file FileName>-fb.log e <FileName>-as.log di Microsoft Outlook <contengono un messaggio di errore simile al seguente:

    <FreeBusyResponse><ResponseMessage ResponseClass="Error"><MessageText>Il chiamante non ha accesso ai dati sulla 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/errors>ServerName</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>

Ad esempio, un utente di Microsoft 365 non può visualizzare le informazioni sulla disponibilità per un utente locale. Tuttavia, altri utenti possono visualizzare informazioni sulla disponibilità per lo stesso utente locale.

Causa

Questo problema si verifica se il nome di dominio per l'indirizzo SMTP (Simple Mail Transfer Protocol) dell'utente che tenta di visualizzare le informazioni sulla disponibilità non è incluso tra i nomi di dominio nella relazione organizzativa. Ad esempio, quando si esegue il cmdlet Test-OrganizationRelationship, viene visualizzato l'output seguente:

RunspaceId : a6c3799f-2ecd-4d79-ae4b-6c470ddd1dee
Identità:
ID: LocalFederatedDomainsAreMissingFromTheRemoteOrganizationRelationsipDomains
Stato: avviso
Descrizione: nell'elenco dei domini per l'oggetto relazione dell'organizzazione remota non sono presenti domini federati in locale.
IsValid: True

Ciò si verifica se il dominio SMTP non è stato aggiunto manualmente alla relazione dell'organizzazione. Ciò può verificarsi anche se si verificano le condizioni seguenti:

  • L'account utente di Microsoft 365 è stato creato prima dell'aggiornamento dell'ambiente locale a Exchange Server 2010.
  • È stata usata la configurazione guidata ibrida in Exchange Server 2010 nell'ambiente locale per configurare l'attendibilità federativa. Ad esempio, il nome di dominio dell'utente di Microsoft 365 è contoso.com.

In questo scenario, l'account utente di Microsoft 365 non ha @contoso.mail.onmicrosoft.com come uno degli indirizzi proxy. La richiesta all'ambiente locale usa @contoso.com anziché per l'account utente di @contoso.mail.onmicrosoft.com Microsoft 365. La richiesta viene rifiutata perché la relazione dell'organizzazione nell'ambiente locale non è stata contoso.com aggiunta.

Risoluzione

Per risolvere questo problema, modificare la relazione dell'organizzazione nell'ambiente locale in modo da includere il dominio SMTP dell'utente che sta riscontrando il problema. A tale scopo, utilizzare uno dei seguenti metodi.

Metodo 1: Usare Exchange Management Console

  1. Nel server Exchange locale aprire Exchange Management Console e quindi selezionare Configurazione dell'organizzazione in Microsoft Exchange locale.
  2. Selezionare la scheda Relazioni dell'organizzazione e quindi visualizzare le proprietà della relazione organizzativa.
  3. Selezionare la scheda Organizzazione esterna , digitare il nome di dominio federato nella casella Domini federati dell'organizzazione di Exchange esterna e quindi selezionare Aggiungi.
  4. Ripetere il passaggio 3 per ogni dominio da aggiungere.
  5. Selezionare OK.

Metodo 2: Usare Exchange Management Shell

  1. Nel server locale aprire Exchange Management Shell.

  2. Configurare la relazione dell'organizzazione come variabile. Ad esempio, eseguire il seguente comando:

    $OrgRel = Get-OrganizationRelationship Contoso
    
  3. Aggiungere i nomi di dominio aggiuntivi che si desidera alla variabile. Ad esempio, eseguire il seguente comando:

    $OrgRel.DomainNames += "contoso.com"
    
  4. Aggiornare la relazione dell'organizzazione usando il nuovo valore dei nomi di dominio. Ad esempio, eseguire il seguente comando:

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

Ulteriori informazioni

Per identificare il problema in Microsoft 365, seguire questa procedura:

  1. Connettersi a Exchange Online tramite una sessione remota di PowerShell. Per altre informazioni su come eseguire questa operazione, vedere Connettersi a Exchange Online PowerShell.

  2. Confrontare l'indirizzo SMTP dell'utente con la relazione organizzativa. A tale scopo, utilizzare il seguente comando:

    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}
    

    Nota

    È anche possibile confrontare ogni dominio elencato nei domini accettati con i nomi di dominio presenti nella relazione organizzativa. A tale scopo, utilizzare il seguente comando:

    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} }
    

Ulteriore assistenza Visitare community Microsoft o forum TechNet di Exchange.

Avviare la guida per risolvere questo problema.