Risolvere gli errori di disponibilità

Per risolvere un errore correlato alle informazioni sulla disponibilità, selezionare il messaggio di errore applicabile nel sommario nella parte superiore di questo articolo.

Se la procedura di risoluzione dei problemi non consente di risolvere il problema, contattare il supporto tecnico Microsoft.

Errore durante la verifica della sicurezza per il messaggio

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Individuazione automatica non riuscita per l'indirizzo smtp dell'indirizzo <> di posta elettronica con errore System.Web.Services.Protocols.SoapHeaderException: errore durante la verifica della sicurezza per il messaggio in System.Web. Services.Protocols. SoapHttpClientProtocol. ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

Questo errore può verificarsi se l'autenticazione WSSecurity non è abilitata o deve essere reimpostata o dopo il rinnovo dei certificati federativi in Exchange Server.

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Per aggiornare i metadati nel gateway federativo Microsoft, eseguire il comando seguente due volte in Exchange Management Shell (EMS) locale:

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Per altre informazioni, vedere Le ricerche sulla disponibilità non funzionano più in un ambiente cross-premise o in una distribuzione ibrida di Exchange Server.

2. Seguire questa procedura per attivare/disattivare l'autenticazione WSSecurity:

   1. Seguire la procedura descritta in Gli utenti di un'organizzazione federata non possono visualizzare le informazioni sulla disponibilità di un'altra organizzazione di Exchange per abilitare o reimpostare se già abilitata l'autenticazione WSSecurity nelle directory virtuali di individuazione automatica e EWS in tutti i server Exchange locali.

      Note

      • Eseguire questo passaggio anche se l'output dei cmdlet Get-AutodiscoverVirtualDirectory di PowerShell e Get-WebServicesVirtualDirectory indicare che l'autenticazione WSSecurity è già abilitata.

      • La procedura interessa solo la disponibilità cross-premise e non influisce sulle altre connessioni client-server.

   2. Eseguire il iisreset /noforce comando in una finestra di PowerShell o del prompt dei comandi in ogni server Exchange locale per riavviare IIS.

   3. Riavviare tutti i server Exchange locali.

3. Controllare e risolvere eventuali avvisi o errori di asimmetria del tempo nel registro eventi di sistema.

4. Impostare il valore del TargetSharingEpr parametro nella relazione dell'organizzazione sull'URL di Exchange Web Services (EWS) esterno locale eseguendo il cmdlet seguente in PowerShell di Exchange Online:

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

   Dopo aver impostato il valore del TargetSharingEpr parametro, la cassetta postale cloud ignora l'individuazione automatica e si connette direttamente all'endpoint EWS della cassetta postale locale.

   Nota: il valore predefinito del TargetSharingEpr parametro è vuoto. I parametri TargetAutodiscoverEpr di individuazione automatica o DiscoveryEndpoint contengono in genere l'URL esterno EWS locale (endpoint di individuazione automatica). Per ottenere i valori dei TargetAutodiscoverEpr parametri e DiscoveryEndpoint , eseguire i cmdlet di PowerShell seguenti:

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

5. Assicurarsi che il valore del TargetApplicationUri parametro nella relazione organizzativa corrisponda al valore del AccountNamespace parametro nell'identificatore dell'organizzazione federata. Per trovare il valore del TargetApplicationUri parametro, eseguire il cmdlet Di PowerShell Test-OrganizationRelationship . Per trovare il valore del AccountNamespace parametro, vedere Demistificazione della disponibilità ibrida.

Inizio pagina

Richiesta Web proxy non riuscita: impossibile connettersi al server remoto

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale o viceversa. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Richiesta Web proxy non riuscita. , eccezione interna: System.Net.WebException: Impossibile connettersi al server remoto; System.Net.Sockets.SocketException: tentativo di connessione non riuscito perché la parte connessa non ha risposto correttamente dopo un periodo di tempo oppure la connessione stabilita non è riuscita perché l'host connesso non è riuscito a rispondere CUSTOMER_IP:443/MICROSOFT_IP:443 in System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)

Questo errore può verificarsi se problemi di connettività di rete impediscono connessioni in ingresso o in uscita tra gli indirizzi IP in Exchange Online e gli endpoint in Exchange Server.

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Verificare che il firewall in ogni server Exchange locale consenta connessioni in ingresso o in uscita tra gli endpoint di Exchange Server e gli indirizzi IP di Exchange Online. Per identificare i problemi del firewall, effettuare una richiesta di disponibilità da Exchange Online e quindi controllare il firewall locale, il proxy inverso e i log di rete. Per altre informazioni su come configurare un firewall, vedere Considerazioni sul firewall per la delega federata e GLI URL e gli intervalli di indirizzi IP di Microsoft 365.

2. Verificare che le richieste provenienti da Exchange Online raggiungano i server Accesso client locali. Seguire questa procedura in tutti i server Accesso client locali:

   1. Effettuare una richiesta di disponibilità da Exchange Online.

   2. Controllare i log IIS nella cartella W3SVC1 per il sito Web predefinito per verificare che la richiesta di disponibilità sia registrata. Il percorso della cartella W3SVC1 è %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

   3. Controllare i log del proxy HTTP nelle cartelle seguenti per verificare che la richiesta di disponibilità sia registrata:

      • %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover

      • %ExchangeInstallPath%\Logging\HttpProxy\Ews

3. Testare la connettività da Exchange Online all'endpoint di Exchange Web Services (EWS) locale eseguendo il cmdlet seguente in PowerShell di Exchange Online:

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

   Note

   • Questo test è utile se si limitano le connessioni in ingresso da Internet per consentire solo agli indirizzi IP di Exchange Online di connettersi all'endpoint EWS locale.

   • Se questo problema interessa solo alcuni utenti cloud e le cassette postali sono ospitate nello stesso server di posta in Exchange Online, verificare se il server di posta può connettersi agli endpoint locali. È possibile che un endpoint locale blocchi le connessioni dall'indirizzo IP esterno in uscita del server di posta elettronica.

   • Quando vengono richieste le credenziali, immettere le credenziali di amministratore di dominio nel formato "dominio\amministratore".

Inizio pagina

Individuazione automatica non riuscita per l'indirizzo di posta elettronica: stato HTTP 404

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Individuazione automatica non riuscita per l'indirizzo SMTP dell'utente dell'indirizzo <> di posta elettronica con errore System.Net.WebException: la richiesta non è riuscita con codice 404 Not Founddi stato HTTP.

Questo errore può verificarsi se gli endpoint di individuazione automatica non sono funzionali o non configurati correttamente.

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Controllare se l'endpoint di individuazione automatica è valido:

   1. Eseguire i comandi seguenti per ottenere l'URL dell'endpoint di individuazione automatica dal DiscoveryEndpoint parametro o TargetAutodiscoverEpr :

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

   2. Passare all'URL dell'endpoint di individuazione automatica in un Web browser. Un endpoint di individuazione automatica valido non restituirà il codice 404 Not Founddi stato HTTP.

2. Assicurarsi che il dominio dell'utente locale sia specificato nelle impostazioni dell'organizzazione (connettore all'interno dell'organizzazione o relazione organizzativa) dell'utente cloud:

   1. Eseguire i cmdlet di PowerShell seguenti in PowerShell per Exchange Online:

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

      Verificare che il dominio dell'utente locale sia elencato nell'output di entrambi i comandi. Ad esempio, se l'utente user1@contoso.com cloud cerca la disponibilità per l'utente user2@contoso.rolocale, verificare che il dominio contoso.ro locale sia elencato.

   2. Se il dominio dell'utente locale non esiste nelle impostazioni dell'organizzazione dell'utente cloud, aggiungere il dominio eseguendo il cmdlet di PowerShell seguente:

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

3. Assicurarsi che il mapping del gestore SVC esista sia nelle directory virtuali di individuazione automatica che in sito Web predefinito in Gestione IIS. Per altre informazioni, vedere FederationInformation couldn't be received and Exception has been thrown by the target .see FederationInformation couldn't be received and Exception has been thrown by the target.

   Nota: il AutodiscoverDiscoveryHander mapping (*.svc) non viene usato per la ricerca della disponibilità della federazione.

Inizio pagina

Richiesta Web proxy eccezione non riuscita

LID: 43532

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Richiesta Web proxy eccezione non riuscita. , eccezione interna: la richiesta non è riuscita con stato HTTP 401: Diagnostica non autorizzata: 2000005; reason= "L'utente specificato dal contesto utente nel token è ambiguo." ; error_category="invalid_user"

Questo errore può verificarsi se l'UPN, l'indirizzo SMTP o l'indirizzo SIP dell'utente locale viene usato da un'altra cassetta postale locale.

Risoluzione

Per correggere il problema, attenersi alla seguente procedura:

1. Cercare oggetti utente locali con un upn duplicato, un indirizzo SMTP o un indirizzo SIP usando query LDAP personalizzate. È possibile eseguire query LDAP usando LDP.exe o lo snap-in MMC Utenti e computer di Active Directory.

   Ad esempio, per visualizzare tutti gli utenti che hanno user@corp.contoso.com come UPN, user@contoso.com come indirizzo SMTP o user@contoso.com come indirizzo SIP, usare la query LDAP seguente:

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

   Per altre informazioni su come usare LDP.exe o Utenti e computer di Active Directory per trovare oggetti Active Directory, vedere Esempi di LDP.

2. Modificare l'indirizzo duplicato o eliminare l'oggetto utente duplicato.

Inizio pagina

Una connessione esistente è stata forzatamente chiusa dall'host remoto

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Richiesta Web proxy non riuscita. , eccezione interna: System.Net.WebException: la connessione sottostante è stata chiusa: si è verificato un errore imprevisto durante una ricezione. System.IO.IOException: impossibile leggere i dati dalla connessione di trasporto: una connessione esistente è stata chiusa forzatamente dall'host remoto. System.Net.Sockets.SocketException: una connessione esistente è stata chiusa forzatamente dall'host remoto.

Questo errore può verificarsi se un firewall locale blocca una connessione in ingresso da un indirizzo IP esterno in uscita in Exchange Online.

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Verificare se le richieste di disponibilità da Exchange Online raggiungono IIS in un server Exchange. Effettuare una richiesta di disponibilità da Exchange Online e cercare le voci di log IIS seguenti effettuate al momento della richiesta di disponibilità:

   • Voce di individuazione automatica nella cartella %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover che contiene "ASAutoDiscover/CrossForest/EmailDomain".

     Nota: se si imposta manualmente il TargetSharingEpr parametro nella relazione dell'organizzazione sull'URL di Exchange Web Services (EWS) esterno locale, l'individuazione automatica viene ignorata e questa voce non esiste.

   • Voce EWS nella cartella %ExchangeInstallPath%\Logging\HttpProxy\Ews che contiene "ASProxy/CrossForest/EmailDomain".

   Nota: i timestamp nei log IIS usano l'ora UTC.

2. Verificare che il firewall in ogni server Exchange locale consenta connessioni in ingresso o in uscita tra gli endpoint di Exchange Server e gli indirizzi IP di Exchange Online. Per identificare i problemi del firewall, effettuare richieste di disponibilità da Exchange Online e quindi controllare il firewall locale, il proxy inverso e i log di rete. Per altre informazioni su come configurare un firewall, vedere Considerazioni sul firewall per la delega federata e GLI URL e gli intervalli di indirizzi IP di Microsoft 365.

3. Se l'organizzazione usa le relazioni dell'organizzazione per implementare la disponibilità, assicurarsi che sia installato un certificato federativo in ogni server Exchange. Eseguire i comandi seguenti in Exchange Management Shell (EMS):

   Test-FederationTrustCertificate
   Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo | FL
   

   Se il certificato federativo è installato, l'output del comando non deve contenere errori o avvisi.

4. Seguire questa procedura per attivare/disattivare l'autenticazione WSSecurity:

   1. Seguire la procedura descritta in Gli utenti di un'organizzazione federata non possono visualizzare le informazioni sulla disponibilità di un'altra organizzazione di Exchange per abilitare o reimpostare se già abilitata l'autenticazione WSSecurity nelle directory virtuali di individuazione automatica e EWS in tutti i server Exchange locali. Eseguire questo passaggio anche se l'autenticazione WSSecurity è già abilitata.

   2. Riciclare i pool di applicazioni EWS e individuazione automatica in Gestione IIS.

   3. Eseguire il iisreset /noforce comando in una finestra di PowerShell o del prompt dei comandi in ogni server Exchange locale per riavviare IIS.

5. Se questo problema interessa solo alcuni utenti cloud e le cassette postali sono ospitate nello stesso server di posta in Exchange Online, verificare se il server di posta può connettersi agli endpoint locali. È possibile che un endpoint locale blocchi le connessioni dall'indirizzo IP in uscita del server di posta elettronica.

Inizio pagina

Impossibile trovare informazioni di configurazione per foresta/dominio in Active Directory

LID: 47932

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale o viceversa. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Impossibile trovare le informazioni di configurazione per il dominio di foresta/dominio <> in Active Directory.

Questo errore può verificarsi se le impostazioni dell'organizzazione non sono configurate correttamente.

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Verificare che il dominio di un utente le cui informazioni sulla disponibilità sono richieste esista nelle impostazioni dell'organizzazione dell'utente che sta tentando di visualizzare le informazioni sulla disponibilità. Selezionare una delle procedure seguenti a seconda della direzione della disponibilità.

   • Da cloud a locale

     Per un utente cloud che tenta di visualizzare le informazioni sulla disponibilità per un utente locale, seguire questa procedura:

     1. Connettersi a PowerShell di Exchange Online ed eseguire i cmdlet di PowerShell seguenti per ottenere i domini federati:

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

        Verificare che il dominio dell'utente locale sia elencato nell'output di entrambi i comandi. Ad esempio, se l'utente user1@contoso.com cloud cerca la disponibilità per l'utente user2@contoso.rolocale, verificare che il dominio contoso.ro locale sia elencato.

        Nota

        È anche possibile trovare i nomi di dominio eseguendo (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses in PowerShell di Exchange Online o eseguendo (Get-FederatedOrganizationIdentifier).Domains Exchange Management Shell (EMS) locale.

     2. Se il dominio dell'utente locale non esiste nelle impostazioni dell'organizzazione dell'utente cloud, aggiungere il dominio eseguendo il cmdlet di PowerShell seguente:

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

   • Da locale a cloud

     Per un utente locale che tenta di visualizzare le informazioni sulla disponibilità per un utente cloud, seguire questa procedura:

     1. In EMS eseguire i cmdlet di PowerShell seguenti:

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

        Controllare se il dominio dell'utente cloud corrisponde a uno dei domini elencati nell'output del comando. Ad esempio, se l'utente user1@contoso.ro locale cerca informazioni sulla disponibilità per l'utente user2@contoso.comcloud, verificare che il dominio contoso.com cloud sia presente nell'output di entrambi i comandi.

     2. Se il dominio dell'utente cloud non esiste nelle impostazioni dell'organizzazione dell'utente locale, aggiungere il dominio. Eseguire il comando qui riportato:

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

2. Assicurarsi che la distribuzione ibrida di Exchange abbia una configurazione ibrida completa. Se necessario, eseguire di nuovo la Configurazione guidata ibrida (HCW) e selezionare Configurazione ibrida completa anziché Configurazione ibrida minima. Una configurazione ibrida minima non crea una relazione organizzativa (trust federativo) o connettori all'interno dell'organizzazione.

Inizio pagina

Richiesta Web proxy non riuscita: stato HTTP 401

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato uno dei messaggi di errore seguenti.

Messaggio di errore 1

Richiesta Web proxy non riuscita. ,eccezione interna: la richiesta non è riuscita con stato HTTP 401: Non autorizzato.

Messaggio di errore 2

Individuazione automatica non riuscita per l'indirizzo di posta elettronica. ,eccezione interna: la richiesta non è riuscita con stato HTTP 401: Non autorizzato.

Questo errore può verificarsi se un dispositivo perimetrale davanti a Exchange Server è configurato per preautenticare (richiedere nome utente e password) anziché passare le richieste da Exchange Online direttamente a Exchange Server. Le directory virtuali di individuazione automatica ed EWS nelle distribuzioni di Exchange ibride non supportano la preautenticazione.

Esempi di dispositivi perimetrali includono proxy inversi, firewall e Microsoft Threat Management Gateway (TMG).

Il messaggio di errore 1 indica che una richiesta EWS non è riuscita.

Il messaggio di errore 2 indica che una richiesta di individuazione automatica non è riuscita.

Procedura di risoluzione dei problemi

Per risolvere il problema di disponibilità indipendentemente dal messaggio di errore ricevuto, seguire questa procedura. Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Verificare se la preautenticazione è abilitata. attenersi alla seguente procedura:

   1. Eseguire il test della disponibilità nell'analizzatore connettività remota per verificare se la preautenticazione è abilitata. La cassetta postale cloud è la cassetta postale di origine e la cassetta postale locale è la cassetta postale di destinazione. Al termine del test, controllare lo stato di autenticazione pass-through nell'endpoint. Se viene visualizzato un segno di spunta rosso, disabilitare la preautenticazione e il nuovo test. Se viene visualizzato un segno di spunta verde, continuare con il passaggio successivo perché potrebbe essere un falso positivo.

   2. Verificare se una richiesta di disponibilità da Exchange Online raggiunge IIS. Eseguire una query sulla disponibilità e quindi cercare una delle voci seguenti nei log IIS in Exchange Server al momento della query:

      • Nella cartella %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover cercare una voce di individuazione automatica con il codice 401 Unauthorized di stato HTTP e contenente il testo "ASAutoDiscover/CrossForest/EmailDomain".

        Nota: se il TargetSharingEpr parametro nella relazione organizzativa specifica un URL esterno EWS locale, l'individuazione automatica viene ignorata e questa voce non verrà visualizzata.

      • Nella cartella %ExchangeInstallPath%\Logging\HttpProxy\Ews cercare una voce EWS con il codice 401 Unauthorized di stato HTTP e contenente il testo "ASProxy/CrossForest/EmailDomain".

      Nota: i timestamp nei log IIS usano l'ora UTC. Alcune voci con il codice 401 Unauthorized di stato HTTP sono normali.

      Le voci specificate indicano che la richiesta di disponibilità ha raggiunto IIS e in genere esclude i problemi di preautenticazione. Se non si trovano le voci specificate, controllare i log del proxy inverso e del firewall per comprendere dove è rimasta bloccata la richiesta di disponibilità.

2. Assicurarsi di aver abilitato WSSecurity (Exchange Server 2010) o l'autenticazione OAuth (Exchange Server 2013 e versioni successive) nelle directory virtuali EWS e Individuazione automatica. Verificare inoltre di aver abilitato le impostazioni di autenticazione predefinite in IIS per l'individuazione automatica e le directory virtuali EWS. Per altre informazioni, vedere Impostazioni di autenticazione predefinite per le directory virtuali di Exchange e Impostazioni predefinite per le directory virtuali di Exchange.

3. Seguire la procedura di risoluzione descritta in Errore durante la verifica della sicurezza per il messaggio. Se WSSecurity è configurato, assicurarsi di eseguire il passaggio che attiva/disattiva WSSecurity. Se l'autenticazione OAuth è configurata anziché WSSecurity, attivare o disattivare l'autenticazione OAuth nelle directory virtuali di individuazione automatica ed EWS eseguendo i comandi seguenti:

   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. Verificare di avere un trust federativo aggiornato. Eseguire il comando seguente in PowerShell di Exchange Online per recuperare le informazioni sull'attendibilità federativa per l'organizzazione di Exchange:

   Get-FederationTrust
   

   L'output del comando deve contenere le informazioni seguenti:

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

   Nota: l'attendibilità WindowsLiveId è un'istanza consumer del gateway federativo Microsoft. Il MicrosoftOnline trust è un'istanza aziendale del gateway federativo Microsoft.

   Per un trust federativo aggiornato, assicurarsi che sia ApplicationIdentifier260563 e non 292841e che sia ApplicationUrioutlook.com e non outlook.live.com. Se si dispone di un trust federativo obsoleto, contattare il supporto tecnico Microsoft.

Inizio pagina

Individuazione automatica non riuscita per l'indirizzo di posta elettronica: InvalidUser

LID: 33676

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

La risposta del servizio di individuazione automatica in 'https://Autodiscover/Autodiscover.svc/WSSecurity' non è riuscita a causa di un errore nell'impostazione utente 'ExternalEwsUrl'. Messaggio di errore: InvalidUser.

Il messaggio di errore potrebbe essere visualizzato quando si esegue il test della disponibilità nell'analizzatore connettività remota.

Questo errore può verificarsi se la cassetta postale cloud o l'endpoint di individuazione automatica non è configurato correttamente.

Procedura di risoluzione dei problemi

1. Verificare che l'utente cloud disponga di un indirizzo SMTP secondario che include il onmicrosoft.com dominio eseguendo il comando seguente:

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

   Ad esempio, un utente che ha l'indirizzo user1@contoso.com SMTP primario deve avere un indirizzo SMTP secondario simile a user1@contoso.mail.onmicrosoft.com.

   Se l'utente cloud è gestito da Exchange Server, aggiungere l'indirizzo SMTP secondario a Exchange Server e quindi sincronizzare i dati di identità tra l'ambiente locale e l'ID Microsoft Entra.

2. Eseguire i comandi seguenti per impostare il valore del TargetSharingEpr parametro nella relazione organizzativa sull'URL di Exchange Web Services (EWS) esterno locale:

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

   Dopo aver impostato il valore del TargetSharingEpr parametro, la cassetta postale cloud ignora l'individuazione automatica e si connette direttamente all'endpoint EWS della cassetta postale locale.

Inizio pagina

Il chiamante non ha accesso ai dati sulla disponibilità

LID: 47652, 44348, 40764

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale o viceversa. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException: il chiamante non ha accesso ai dati sulla disponibilità.

Questo errore può verificarsi se la cassetta postale dell'utente le cui informazioni sulla disponibilità sono richieste non è configurata correttamente.

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Controllare le autorizzazioni del calendario dell'utente le cui informazioni sulla disponibilità sono richieste eseguendo il comando seguente:

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

   Il AccessRights valore per l'utente Default nell'output del comando deve essere AvailabilityOnly o LimitedDetails. Se il AccessRights valore è None, eseguire il cmdlet di PowerShell seguente per impostare tale valore AvailabilityOnly su o LimitedDetails:

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

2. Usare il metodo applicabile per controllare la relazione dell'organizzazione:

   • Se un utente cloud non può visualizzare le informazioni sulla disponibilità per un utente locale:

     Verificare che la relazione dell'organizzazione locale specifichi il dominio cloud che può accedere alle informazioni sulla disponibilità locale. Un dominio cloud di esempio è contoso.mail.onmicrosoft.com. Per informazioni su come modificare la relazione organizzativa in Exchange Server, vedere Usare PowerShell per modificare la relazione dell'organizzazione. Verificare anche che l'indirizzo di posta elettronica Da dell'utente cloud abbia lo stesso dominio cloud, ad esempio lucine.homsi@contoso.mail.onmicrosoft.com.

   • Se un utente locale non è in grado di visualizzare le informazioni sulla disponibilità per un utente cloud:

     Verificare che la relazione dell'organizzazione cloud specifichi il dominio locale che può accedere alle informazioni sulla disponibilità del cloud. Un dominio locale di esempio è contoso.com. Per informazioni su come modificare la relazione organizzativa in Exchange Online, vedere Usare Exchange Online PowerShell per modificare la relazione dell'organizzazione. Verificare anche che l'indirizzo di posta elettronica Da dell'utente locale abbia lo stesso dominio locale, ad esempio lucine.homsi@contoso.com.

Inizio pagina

Errore durante l'elaborazione dei token di sicurezza nel messaggio

LID: 59916

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

ProxyWebRequestProcessingException ErrorProxyRequestProcessingFailed
Richiesta Web proxy non riuscita. , eccezione interna: si è verificato un errore durante l'elaborazione dei token di sicurezza nel messaggio.

Questo errore può verificarsi se i certificati o i metadati nel gateway federativo Microsoft non sono validi.

Procedura di risoluzione dei problemi

1. Controllare la data di scadenza e le identificazioni personali dei certificati di attendibilità federativi locali eseguendo i cmdlet di PowerShell seguenti:

   Get-FederationTrust | FL
   Test-FederationTrust
   Test-FederationTrustCertificate
   

2. Per aggiornare i metadati nel gateway federativo Microsoft, eseguire il comando seguente due volte in Exchange Management Shell (EMS) locale:

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Per altre informazioni, vedere Le ricerche sulla disponibilità non funzionano più.

Inizio pagina

La richiesta tra organizzazioni non è consentita perché il richiedente proviene da un'organizzazione diversa

LID: 39660

Problema

Si dispone di uno scenario di rete ibrida in cui un utente cloud in un tenant di Exchange Online non ibrido non può visualizzare le informazioni sulla disponibilità per un utente cloud in un altro tenant di Exchange Online ibrido. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

La richiesta tra organizzazioni per l'indirizzo> SMTP della cassetta postale <non è consentita perché il richiedente proviene da un'organizzazione diversa
Destinatario: <indirizzo SMTP>
Tipo di eccezione: CrossOrganizationProxyNotAllowedForExternalOrganization
Messaggio di eccezione: la richiesta tra organizzazioni per <l'indirizzo> SMTP non è consentita perché il richiedente proviene da un'organizzazione diversa.

Ad esempio, un utente lucine@adatum.com in un tenant di Exchange Online non ibrido non può visualizzare la disponibilità di un utente chanok@contoso.com cloud in un tenant ibrido. L'utente chanok@contoso.com cloud ha un indirizzo chanok@contoso.mail.onmicrosoft.comdi posta elettronica proxy. Il tenant nonhybrid ha due relazioni dell'organizzazione: contoso.com (locale) e contoso.mail.onmicrosoft.com (cloud). Individuazione automatica per contoso.com i punti a Exchange Server e Individuazione automatica per contoso.mail.onmicrosoft.com i punti a Exchange Online. L'utente nel tenant nonhybrid riceve il messaggio di errore quando esegue una query sulle informazioni sulla disponibilità per chanok@contoso.com, perché l'individuazione automatica dei contoso.com punti non punta a Exchange Online.

Nota

Per lo scenario di rete ibrida locale equivalente, vedere Mesh ibrida.

Soluzione alternativa

Per risolvere questo problema, l'organizzazione può usare uno dei metodi seguenti:

• Gli utenti nel tenant di Exchange Online non ibrido devono eseguire query sulla disponibilità di un utente cloud in un tenant ibrido usando l'indirizzo di posta elettronica per cui l'individuazione automatica punta a Exchange Online. Ad esempio, lucine@adatum.com esegue query sulle informazioni sulla disponibilità per chanok@contoso.mail.onmicrosoft.com. Per eseguire correttamente una query sulle informazioni sulla disponibilità, gli utenti del tenant di Exchange Online non ibrido devono sapere quali utenti nel tenant ibrido sono ospitati nel cloud e, per ognuno di questi utenti, l'indirizzo di posta elettronica per cui l'individuazione automatica punta a Exchange Online.

• Un amministratore del tenant di Exchange Online non ibrido deve impostare l'indirizzo di posta elettronica esterno di ogni utente cloud nel tenant ibrido sull'indirizzo di posta elettronica per il quale l'individuazione automatica punta a Exchange Online. Ad esempio, un amministratore nel tenant di Exchange Online non ibrido imposta l'indirizzo di posta elettronica di destinazione di chanok@contoso.com nel tenant ibrido su chanok@contoso.mail.onmicrosoft.com. Per apportare questa modifica, l'amministratore deve sapere quali utenti nel tenant ibrido sono ospitati nel cloud e per ognuno di questi utenti, l'indirizzo di posta elettronica per cui l'individuazione automatica punta a Exchange Online. Per altre informazioni sulla sincronizzazione tra tenant degli indirizzi di posta elettronica degli utenti, vedere Informazioni sulla sincronizzazione tra tenant.

Ulteriori informazioni

Un utente potrebbe riscontrare un problema simile nello scenario seguente:

• L'utente si trova in un tenant di Exchange Server non ibrido.
• L'utente tenta di visualizzare la disponibilità per un utente locale in un tenant ibrido.
• L'individuazione automatica per il tenant ibrido punta a Exchange Online.

Ad esempio, un utente in un tenant di Exchange Server non ibrido non può visualizzare le informazioni sulla disponibilità per l'utente chanok@contoso.com locale in un tenant ibrido perché l'individuazione automatica per contoso.com i punti di Exchange Online (autodiscover-s.outlook.com).

Inizio pagina

La richiesta non è riuscita con stato HTTP 401: Non autorizzato (certificato di firma mancante)

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

System.Net.WebException: la richiesta non è riuscita con stato HTTP 401: Non autorizzato.

Se si esegue il cmdlet Test-OAuthConnectivity , nell'output del comando viene visualizzato il messaggio di errore seguente:

Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException: certificato di firma mancante.

Eseguire ad esempio il comando seguente:

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

Il TargetUri valore del parametro è l'URL del servizio di individuazione automatica locale. Un esempio di tale URL è https://mail.contoso.com/Autodiscover/Autodiscover.svc.

Questo errore può verificarsi se la configurazione di autenticazione ha un certificato OAuth non valido.

Risoluzione

Per correggere il problema, attenersi alla seguente procedura:

1. Eseguire il cmdlet di PowerShell seguente in Exchange Management Shell (EMS) per ottenere l'identificazione personale del certificato OAuth usato dalla configurazione di autenticazione:

   Get-AuthConfig | FL CurrentCertificateThumbprint
   

   Se l'output del comando non restituisce un'identificazione personale del certificato, andare al passaggio 3. In caso contrario, continuare con il passaggio successivo.

2. Eseguire il cmdlet di PowerShell seguente per verificare se il certificato identificato nel passaggio 1 esiste in Exchange Server:

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

   Se Exchange Server non restituisce alcun certificato, andare al passaggio 3 per creare un nuovo certificato.

   Se Exchange Server restituisce un certificato, ma la relativa identificazione personale è diversa dall'identificazione personale ottenuta nel passaggio 1, andare al passaggio 4. Nel passaggio 4 specificare l'identificazione personale del certificato restituito da Exchange Server.

3. Eseguire il cmdlet di PowerShell seguente per creare un nuovo certificato OAuth:

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

   Nota

   Se viene richiesto di sostituire il certificato SMTP, non accettare la richiesta.

   Nel passaggio 4 specificare l'identificazione personale del nuovo certificato creato in questo passaggio.

4. Eseguire i cmdlet di PowerShell seguenti per aggiornare la configurazione di autenticazione per usare il certificato specificato:

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

   Nota

   Se viene visualizzato un avviso che indica che la data di validità è inferiore a 48 ore, scegliere di continuare.

5. Eseguire il cmdlet di PowerShell seguente per rimuovere tutti i riferimenti al certificato precedente:

   Set-AuthConfig -ClearPreviousCertificate
   

Inizio pagina

All'applicazione manca un account collegato per i ruoli controllo degli accessi in base al ruolo oppure l'account collegato non dispone di assegnazioni di ruolo controllo degli accessi in base al ruolo oppure l'account degli utenti chiamanti è disabilitato per l'accesso

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

System.Web.Services.Protocols.SoapException: all'applicazione manca un account collegato per i ruoli controllo degli accessi in base al ruolo oppure l'account collegato non dispone di assegnazioni di ruolo controllo degli accessi in base al ruolo oppure l'account degli utenti chiamanti è disabilitato.

Procedura di risoluzione dei problemi

Per risolvere i problemi indicati nel messaggio di errore, seguire questa procedura. Dopo aver completato i passaggi 1 e 2, verificare se il problema di disponibilità è stato risolto.

1. Assicurarsi che la voce "Exchange Online-ApplicationAccount" esista nell'elenco delle applicazioni partner di Exchange Server. Per controllare, eseguire il cmdlet di PowerShell seguente in Exchange Management Console (EMS):

   Get-PartnerApplication | FL LinkedAccount
   

   La voce dell'account deve essere visualizzata come <root domain FQDN>/Users/Exchange Online-ApplicationAccount. Se la voce è elencata, andare al passaggio 2.

   Se la voce dell'account non è elencata, aggiungere l'account seguendo questa procedura:

   1. Eseguire i cmdlet di PowerShell seguenti per trovare l'account in Active Directory locale:

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

      Se l'account è elencato in Active Directory, andare al passaggio 1b.

      Se l'account non è elencato in Active Directory, potrebbe essere stato eliminato. Usare ADRestore per controllare lo stato dell'account e ripristinarlo, se eliminato. Se l'account è stato ripristinato usando ADRestore, andare al passaggio 1b.

      Se non è possibile ripristinare l'account usando ADRestore, seguire la procedura descritta in Active Directory e domini per Exchange Server. Se questa procedura non ripristina l'account, creare manualmente l'account in Active Directory e quindi continuare con il passaggio 1b.

   2. Eseguire il cmdlet di PowerShell seguente per aggiungere l'account di Active Directory all'elenco delle applicazioni partner di Exchange Server:

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

   3. Riavviare tutti i server Exchange locali o riavviare IIS eseguendo il iisreset /noforce comando in una finestra di PowerShell o del prompt dei comandi in ogni server.

2. Eseguire il cmdlet di PowerShell seguente in EMS per controllare le assegnazioni di controllo degli accessi in base al ruolo:

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

   Ad esempio, l'output del comando potrebbe elencare le assegnazioni di ruolo seguenti:

   

3. Cercare i problemi indicati nel messaggio di errore nei log seguenti:

   • Log di Exchange Web Services (EWS) che si trovano nella cartella %ExchangeInstallPath%\Logging\Ews
   • Registri eventi dell'applicazione
   • Registri eventi di sistema

4. Cercare nei log elencati nel passaggio 3 un messaggio di errore che fa riferimento a AuthzInitializeContextFromSid. Se viene visualizzato il messaggio di errore, vedere le risorse seguenti:

   • Alcune applicazioni e API richiedono l'accesso alle informazioni di autorizzazione sugli oggetti account

   • I controlli di accesso hanno esito negativo a causa di AuthZ

Inizio pagina

Le password immesse e archiviate non corrispondono

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Eccezione di errore soap ricevuta. Le password immesse e archiviate non corrispondono.

Viene visualizzato lo stesso messaggio di errore quando si esegue il cmdlet seguente per verificare se l'utente cloud può recuperare un token di delega per la cassetta postale utente locale:

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

Causa

Esiste un'incoerenza nelle credenziali di Azure per utenti cloud specifici.

Risoluzione

Per correggere il problema, attenersi alla seguente procedura:

1. Reimpostare la password dell'utente cloud. Scegliere la stessa password o una password diversa.

2. Aggiornare il nome dell'entità utente (UPN) dell'utente cloud per usare il onmicrosoft.com dominio e quindi ripristinare il valore precedente dell'UPN. Ad esempio, se l'UPN dell'utente cloud è user@contoso.com, modificarlo in UPN temporaneo e user@contoso.mail.onmicrosoft.comquindi ripristinare l'UPN su user@contoso.com. A tale scopo, usare Azure AD PowerShell o il servizio MSOL.

   • Usare Azure AD PowerShell

     Eseguire i cmdlet di PowerShell seguenti:

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

   • Usare il servizio MSOL

     Eseguire i cmdlet di PowerShell seguenti:

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

3. Assicurarsi che il ImmutableId valore dell'oggetto utente locale sia Null. Controllare il ImmutableId valore per l'oggetto utente locale eseguendo il comando seguente in Exchange Management Shell (EMS):

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

   Usare uno dei metodi seguenti, a seconda del ImmutableId valore.

   • Il valore di ImmutableId è Null

     Se il ImmutableId valore è Null, attivarne o disattivare il valore:

     1. Impostare l'oggetto ImmutableId della cassetta postale remota sull'UPN dell'utente cloud eseguendo il cmdlet di PowerShell seguente in EMS:

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

        Ad esempio: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

     2. Sincronizzare la modifica nel cloud eseguendo i cmdlet di PowerShell seguenti in EMS:

        Import-Module ADSync
        Start-ADSyncSyncCycle -PolicyType Delta
        

        Per verificare che il ImmutableId valore sia stato aggiornato, eseguire il cmdlet di PowerShell seguente in PowerShell per Exchange Online:

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

     3. Ripristinare l'oggetto ImmutableId della cassetta postale remota su Null eseguendo il cmdlet di PowerShell seguente in EMS:

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

     4. Sincronizzare la modifica nel cloud eseguendo il cmdlet di PowerShell seguente in EMS:

        Start-ADSyncSyncCycle -PolicyType Delta
        

        Per verificare che il ImmutableId valore sia stato aggiornato, eseguire il cmdlet di PowerShell seguente in PowerShell per Exchange Online:

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

   • Il valore immutableId non è Null

     Se il ImmutableId valore non è Null, eseguire il comando seguente in EMS per impostare il ImmutableId valore su Null:

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

     È possibile verificare che il ImmutableId valore sia stato aggiornato eseguendo il cmdlet di PowerShell seguente in PowerShell per Exchange Online:

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

Inizio pagina

La password deve essere modificata o la password per l'account è scaduta

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato uno dei messaggi di errore seguenti.

Messaggio di errore 1

La password per l'account è scaduta

Messaggio di errore 2

La password deve essere modificata

Viene visualizzato lo stesso messaggio di errore quando si esegue il cmdlet seguente per verificare se l'utente cloud può recuperare un token di delega per la cassetta postale utente locale:

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

Questo errore può verificarsi se nelle credenziali di Azure esiste un'incoerenza per utenti cloud specifici.

Risoluzione

Selezionare la risoluzione corrispondente al messaggio di errore.

Risoluzione del messaggio di errore 1

Per risolvere il problema, usare Azure AD PowerShell o il servizio MSOL.

• Usare Azure AD PowerShell

  Eseguire i cmdlet di PowerShell seguenti:

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

• Usare il servizio MSOL

  Eseguire i cmdlet di PowerShell seguenti:

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

Risoluzione del messaggio di errore 2

Per risolvere il problema, eseguire i cmdlet di PowerShell seguenti:

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

Per altre informazioni, vedere Non è possibile visualizzare le informazioni sulla disponibilità dopo la migrazione da Exchange locale.

Inizio pagina

Il provisioning è necessario prima che l'account federato possa essere connesso

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Il provisioning è necessario prima che l'account federato possa essere connesso. ErrorWin32InteropError

Si riceve anche lo stesso messaggio di errore quando si esegue il cmdlet seguente per verificare se l'utente cloud può recuperare un token di delega per la cassetta postale utente locale:

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

Questo errore può verificarsi se si verifica un'incoerenza nella configurazione degli utenti federati in Microsoft Entra ID.

Risoluzione

Nota

Se il problema interessa la maggior parte o tutti gli utenti cloud dell'organizzazione, contattare il supporto tecnico Microsoft.

Per risolvere il problema, aggiornare il nome dell'entità utente (UPN) dell'utente cloud per usare il onmicrosoft.com dominio e quindi tornare al valore precedente (dominio federato). Ad esempio, se l'UPN dell'utente cloud è user@contoso.com, passarlo all'UPN user@contoso.mail.onmicrosoft.com temporaneo e quindi tornare a user@contoso.com. A tale scopo, usare uno degli approcci seguenti (Azure AD PowerShell o il servizio MSOL):

• Usare Azure AD PowerShell

  Eseguire i cmdlet di PowerShell seguenti:

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

• Usare il servizio MSOL

  Eseguire i cmdlet di PowerShell seguenti:

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

Inizio pagina

Timeout della richiesta

LID: 43404

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Timeout della richiesta
Impossibile elaborare la richiesta in tempo. Timeout durante 'Waiting-For-Request-Completion'.
Microsoft.Exchange.InfoWorker.Common.Availability.TimeoutExpiredException: impossibile elaborare la richiesta in tempo. Timeout durante 'Waiting-For-Request-Completion'.
Nome del server in cui ha avuto origine l'eccezione: <nome> del server.

Si riceve anche lo stesso messaggio di errore se si esegue il cmdlet seguente per verificare se l'utente cloud può recuperare un token di delega per la cassetta postale utente locale:

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

Questo errore può verificarsi in caso di problemi di rete o temporanei. Il messaggio di errore è generico.

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Per escludere i problemi temporanei, verificare che l'utente cloud riceva in modo coerente lo stesso messaggio di errore durante i tentativi ripetuti di ottenere le informazioni sulla disponibilità dell'utente locale.

2. Verificare se è possibile recuperare un token di delega quando si esegue ognuno dei cmdlet seguenti:

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

   Nota: eseguire il cmdlet Test-FederationTrust in tutti i server Exchange locali.

3. Verificare che Exchange Server disponga dell'accesso Internet in uscita a entrambe le risorse seguenti:

   • Microsoft Federation Gateway (o un server di autorizzazione, se si usa OAuth)

   • URL di disponibilità per Microsoft 365: https://outlook.office365.com/ews/exchange.asmx

   Per altre informazioni, vedere URL e intervalli di indirizzi IP di Microsoft 365 e Considerazioni sul firewall per la delega federata.

4. Assicurarsi che l'account di sistema in Exchange Server abbia accesso a Internet agli URL seguenti. Seguire questa procedura in ogni server Exchange:

   1. Eseguire il comando PsExec seguente per avviare una sessione di PowerShell che avvia un Web browser dall'account di sistema:

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

   2. Testare l'accesso al browser (nessun OAuth) dall'account di sistema agli URL di Microsoft Federation Gateway seguenti:

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

        Nel browser deve essere visualizzata una pagina XML.

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

        Il browser dovrebbe richiedere di scaricare il file.

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

        Il browser deve visualizzare un elenco di operazioni supportate da ManageDelegation2.

   3. Testare l'accesso al browser (OAuth) dall'account di sistema agli URL seguenti del server di autorizzazione Microsoft:

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

        Nel browser dovrebbe essere visualizzato un prompt di accesso.

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

        Il browser dovrebbe visualizzare l'errore di accesso, "Sorry, but we're having trouble sign in".

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

        Il browser deve visualizzare il codice 400 Bad Requestdi stato HTTP o il messaggio di errore di accesso"Sorry, but we're having trouble sign you in".

5. Ottenere i dettagli di una richiesta di disponibilità controllando i log di Exchange Web Services (EWS):

   1. Effettuare una richiesta di disponibilità da Exchange Online.

   2. Trovare la voce nei log EWS e controllare il valore nella time-taken colonna. I log EWS si trovano nella cartella %ExchangeInstallPath%\Logging\Ews .

   3. Controllare i log iis nella cartella W3SVC1 del sito Web predefinito per verificare che la richiesta di disponibilità sia registrata. Il percorso della cartella W3SVC1 è %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

Inizio pagina

Il nome del membro specificato non è valido o vuoto

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

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>Il nome del membro specificato non è valido o vuoto. </psf:text></psf:internalerror></psf:error></S:Detail></S:Fault> Microsoft.Exchange.Net.WSTrust.SoapFaultException: Eccezione di errore Soap ricevuta. in Microsoft.Exchange.Net.WSTrust.SecurityTokenService.EndIssueToken(IAsyncResult asyncResult) all'indirizzo Microsoft.Exchange.InfoWorker.Common.Availability.ExternalAuthenticationRequest.Complete(IAsyncResult asyncResult)

L'errore può verificarsi per uno dei motivi seguenti:

• Incoerenza nell'ID Microsoft Entra per gli utenti che richiedono un token di delega
• Incoerenza nella configurazione degli utenti federati in Active Directory Federation Services (AD FS)

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Aggiornare il nome dell'entità utente (UPN) dell'utente cloud per usare il onmicrosoft.com dominio e quindi ripristinare il valore precedente dell'UPN. Ad esempio, se l'UPN dell'utente cloud è user@contoso.com, modificarlo in UPN temporaneo e user@contoso.mail.onmicrosoft.comquindi ripristinare l'UPN su user@contoso.com. A tale scopo, usare uno dei metodi seguenti (Azure AD PowerShell o il servizio MSOL):

   • Usare Azure AD PowerShell

     Eseguire i cmdlet di PowerShell seguenti:

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

   • Usare il servizio MSOL

     Eseguire i cmdlet di PowerShell seguenti:

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

2. Controllare le regole, gli endpoint e i log di AD FS.

3. Cercare un errore correlato all'oggetto ImmutableID dell'utente cloud nell'output del comando del cmdlet di PowerShell seguente:

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

   Ad esempio, l'output del comando potrebbe contenere il messaggio di errore seguente:

   "L'indirizzo di posta elettronica "XGuNpVunD0afQeVNfyoUIQ==" non è corretto. Usare questo formato: nome utente, il segno @ seguito dal nome di dominio. Ad esempio, tonysmith@contoso.com o tony.smith@contoso.com.
   + CategoryInfo : NotSpecified: (:) [Test-OrganizationRelationship], FormatException"

   Se viene visualizzato un messaggio di errore simile, usare uno dei metodi seguenti per assicurarsi che il ImmutableId valore sia Null (valore vuoto):

   • Se l'utente cloud non è sincronizzato dall'ambiente locale, controllare il ImmutableId valore eseguendo il cmdlet di PowerShell seguente in PowerShell di Exchange Online:

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

     Se il ImmutableId valore non è Null, eseguire il cmdlet di PowerShell seguente in PowerShell per Exchange Online:

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

   • Se l'utente cloud è sincronizzato dall'ambiente locale, controllare il ImmutableId valore dell'oggetto utente locale eseguendo il comando seguente in Exchange Management Shell (EMS):

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

     Usare uno dei metodi seguenti, a seconda del ImmutableId valore:

     • Il valore di ImmutableId è Null

       Se il ImmutableId valore è Null, attivarne o disattivare il valore:

       1. Impostare l'oggetto ImmutableId della cassetta postale remota sull'UPN dell'utente cloud eseguendo il cmdlet di PowerShell seguente in EMS:

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

          Ad esempio: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

       2. Sincronizzare la modifica nel cloud eseguendo i cmdlet di PowerShell seguenti in EMS:

          Import-Module ADSync
          Start-ADSyncSyncCycle -PolicyType Delta
          

          Per verificare che il ImmutableId valore sia stato aggiornato, eseguire il cmdlet di PowerShell seguente in PowerShell per Exchange Online:

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

       3. Ripristinare l'oggetto ImmutableId della cassetta postale remota su Null eseguendo il cmdlet di PowerShell seguente in EMS:

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

       4. Sincronizzare la modifica nel cloud eseguendo il cmdlet di PowerShell seguente in EMS:

          Start-ADSyncSyncCycle -PolicyType Delta
          

          Verificare che il ImmutableId valore sia stato aggiornato. A tale scopo, eseguire il cmdlet di PowerShell seguente in PowerShell per Exchange Online:

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

     • Il valore immutableId non è Null

       Se il ImmutableId valore non è Null, eseguire il comando seguente in EMS per impostare il ImmutableId valore su Null:

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

       Per verificare che il ImmutableId valore sia stato aggiornato, eseguire il cmdlet di PowerShell seguente in PowerShell per Exchange Online:

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

4. Controllare le impostazioni delle relazioni dell'organizzazione. Per altre informazioni, vedere Demistificazione della disponibilità ibrida.

5. Se viene generato il messaggio di errore per un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale, seguire questa procedura:

   1. Eseguire i cmdlet di PowerShell seguenti:

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

   2. Ricreare il trust federativo. Per altre informazioni, vedere Rimuovere un trust federativo e Configurare un trust federativo.

Inizio pagina

Il set di risultati contiene troppe voci di calendario

LID: 54796

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un altro utente cloud. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Eccezione: il set di risultati contiene troppe voci di calendario. Dimensione consentita = 1000; la dimensione effettiva = 5009.

Questo errore si verifica se il numero di voci di calendario in un singolo timeslot supera 1.000 elementi. Una singola richiesta di disponibilità non può recuperare più di 1.000 elementi.

Risoluzione

Rimuovere alcuni elementi del calendario dal timestamp in modo da non superare il limite di 1.000 elementi che possono essere recuperati in una singola richiesta di disponibilità.

Per altre informazioni, vedere Non è possibile visualizzare le informazioni sulla disponibilità nel calendario di un altro utente in Exchange Online.

Inizio pagina

L'ora di inizio dell'orario di lavoro deve essere minore o uguale all'ora di fine

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un elenco di sale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Eccezione: Microsoft.Exchange.InfoWorker.Common.InvalidParameterException: l'ora di inizio dell'orario di lavoro deve essere minore o uguale all'ora di fine.
Microsoft.Exchange.InfoWorker.Common.MeetingSuggestions.AttendeeWorkHours.Validate(TimeSpan startTime, TimeSpan endTime).

Questo errore può verificarsi se una o più delle impostazioni del calendario seguenti per una cassetta postale della sala in un elenco di sale non sono valide:

• WorkingHoursStartTime
• WorkingHoursEndTime
• WorkingHoursTimeZone

L'ora di inizio dell'orario di lavoro deve essere minore o uguale all'ora di fine dell'orario di lavoro e deve essere impostato il fuso orario dell'orario di lavoro.

Risoluzione

Per correggere il problema, attenersi alla seguente procedura:

1. Eseguire il cmdlet di PowerShell seguente per controllare le impostazioni del calendario di ogni cassetta postale nell'elenco delle sale per identificare la cassetta postale della sala con impostazioni non valide:

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

2. Eseguire il cmdlet di PowerShell seguente per impostare i valori dei parametri necessari per una cassetta postale della sala:

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

   Per altre informazioni, vedere Set-MailboxCalendarConfiguration.

Inizio pagina

La richiesta non è riuscita con stato HTTP 401: non autorizzato (il token ha una firma non valida)

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

System.Net.WebException: la richiesta non è riuscita con stato HTTP 401: Non autorizzato.

Quando si esegue il cmdlet di PowerShell seguente per testare l'autenticazione OAuth:

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

Si riceve l'output del comando seguente:

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

Nota: il TargetUri valore del parametro nel comando Test-OAuthConnectivity è un URL esterno di Exchange Web Services (EWS), ad https://mail.contoso.com/ews/exchange.asmxesempio .

Questo errore può verificarsi se le impostazioni del server di autorizzazione Microsoft non sono valide.

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Aggiornare i metadati di autorizzazione nel server di autorizzazione Microsoft specificato considerato attendibile da Exchange. Eseguire il cmdlet di PowerShell seguente in EMS (locale):

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

   Attendere circa 15 minuti per rendere il comando completamente effettivo oppure riavviare IIS eseguendo il iisreset /noforce comando in una finestra di PowerShell o del prompt dei comandi in ogni Exchange Server.

2. Controllare le impostazioni del server di autorizzazione Microsoft nell'organizzazione di Exchange eseguendo il cmdlet di PowerShell seguente in EMS:

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

   L'output del comando seguente è un esempio di impostazioni valide:

   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
   

   Se le impostazioni del server di autorizzazione Microsoft non sono valide, provare a eseguire nuovamente la Configurazione guidata ibrida per reimpostare le impostazioni del server di autorizzazione Microsoft su valori validi.

Inizio pagina

La richiesta non è riuscita con stato HTTP 401: Non autorizzato (la chiave non è stata trovata)

Problema

Si dispone di un utente locale che non può visualizzare le informazioni sulla disponibilità per un utente cloud. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

System.Net.WebException: la richiesta non è riuscita con stato HTTP 401: Non autorizzato.

Quando si esegue il cmdlet di PowerShell seguente in EMS per testare l'autenticazione OAuth:

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

Si riceve l'output del comando seguente:

System.Net.WebException: il server remoto ha restituito un errore: (401) Non autorizzato.
Errore: impossibile ottenere il token dal server di autenticazione. Codice di errore: 'invalid_client'. Descrizione: 'AADSTS70002:
Errore durante la convalida delle credenziali. AADSTS50012: l'asserzione client contiene una firma non valida. [Motivo: la chiave non è stata trovata. Identificazione personale della chiave usata dal client: '<identificazione personale>'.

Questo errore può verificarsi se il certificato OAuth in Exchange Server non esiste in Exchange Online.

Risoluzione

Per risolvere il problema, seguire questa procedura:

1. Determinare se il certificato OAuth di Exchange Server locale esiste nell'organizzazione di Exchange Online:

   1. Eseguire il cmdlet di PowerShell seguente in Exchange Management Shell (EMS) per ottenere il certificato OAuth in Exchange Server:

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

      L'output del comando contiene il Thumbprint valore .

   2. Eseguire i cmdlet di PowerShell seguenti per ottenere il certificato OAuth di Exchange Online usando il servizio MSOL:

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

      Se il valore del Value parametro nell'output del comando è vuoto, non esiste un certificato OAuth in Exchange Online. In tal caso, passare al passaggio 3 per caricare il certificato locale in Exchange Online.

      Se il valore del Value parametro non è vuoto, salvare il valore in un file con estensione ".cer". Aprire il file nello strumento Gestione certificati Microsoft per visualizzare il certificato OAuth di Exchange Online. Confrontare il Thumbprint valore nel certificato di Exchange Online con l'identificazione personale del certificato locale ottenuto nel passaggio 1a. Se i valori di identificazione personale corrispondono, andare al passaggio 4. Se i valori di identificazione personale non corrispondono, scegliere una delle opzioni seguenti:

      • Passare al passaggio 2 per sostituire il certificato locale esistente con il certificato Exchange Online.

      • Passare al passaggio 3 per sostituire il certificato exchange online esistente con il certificato locale.

2. Sostituire il certificato locale esistente con il certificato Exchange Online:

   1. Eseguire il cmdlet di PowerShell seguente per aggiornare l'identificazione personale del certificato locale:

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

      Se si riceve una notifica che indica che la data di validità del certificato è inferiore a 48 ore, accettare la richiesta di continuare.

   2. Eseguire il cmdlet di PowerShell seguente per pubblicare il certificato locale:

      Set-AuthConfig -PublishCertificate  
      

   3. Eseguire il cmdlet di PowerShell seguente per rimuovere tutti i riferimenti al certificato precedente:

      Set-AuthConfig -ClearPreviousCertificate 
      

   4. Andare al passaggio 4.

3. Esportare il certificato di autorizzazione locale e quindi caricare il certificato nell'organizzazione exchange online.

4. Eseguire il cmdlet di PowerShell seguente per verificare se il nome SPN nella configurazione dell'autenticazione locale è 00000002-0000-0ff1-ce00-000000000000:

   Get-AuthConfig | FL ServiceName
   

   Se il valore SPN è diverso, aggiornare il nome SPN eseguendo il cmdlet di PowerShell seguente:

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

Inizio pagina

Richiesta Web proxy non riuscita: la risposta non è xml ben formato

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Richiesta Web proxy non riuscita. Eccezione interna: la risposta non è xml ben formato

Se si esegue il test di sincronizzazione, notifica, disponibilità e risposte automatiche per l'utente locale, viene visualizzato il messaggio di errore seguente:

La risposta ricevuta dal servizio non contiene xml valido

Questi errori possono verificarsi per uno dei motivi seguenti:

• Problema di Servizi Web Exchange esterni (EWS)
• Configurazione errata dei dispositivi di rete, ad esempio un proxy inverso o un firewall

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Verificare se una richiesta di disponibilità da Exchange Online può raggiungere IIS in un server Exchange. Eseguire una query sulla disponibilità e quindi cercare nei log IIS le voci con codice 200 OK di stato HTTP o 401 Unauthorized al momento della query. Tali voci indicano che la richiesta di disponibilità ha raggiunto IIS. Nota: i timestamp nei log IIS usano l'ora UTC.

   Se non si trovano queste voci, controllare i log del proxy inverso e del firewall per determinare dove la richiesta di disponibilità si è bloccata.

2. Eseguire una query sulla disponibilità e quindi cercare nel registro applicazioni di Exchange Server nel Visualizzatore eventi di Windows le voci effettuate al momento della query per ridurre la causa del problema.

Inizio pagina

Impossibile connettersi al server remoto

Problema

Si dispone di un utente locale che non può visualizzare le informazioni sulla disponibilità per un utente cloud. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Impossibile comunicare con https://login.microsoftonline.com/extSTS.srf., eccezione interna: impossibile connettersi al server remoto.

Questo errore può verificarsi se uno o più server Exchange non possono connettersi a un URL del gateway federativo Microsoft.

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Eseguire i cmdlet di PowerShell seguenti in Exchange Management Shell (EMS) per verificare se è possibile recuperare un token di delega:

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

2. Verificare che i server Exchange locali dispongano dell'accesso Internet in uscita a entrambe le risorse seguenti:

   • Il gateway federativo Microsoft o il server di autorizzazione Microsoft se si usa l'autenticazione OAuth.

   • URL di disponibilità per Microsoft 365: https://outlook.office365.com/ews/exchange.asmx.

   Per altre informazioni, vedere URL e intervalli di indirizzi IP di Microsoft 365 e Considerazioni sul firewall per la delega federata.

3. Verificare che l'account di sistema in Exchange Server abbia accesso a Internet agli URL seguenti. Seguire questa procedura in tutti i server Exchange nell'organizzazione:

   1. Eseguire il comando PsExec seguente per avviare una sessione di PowerShell che avvia un Web browser dall'account di sistema:

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

   2. Testare l'accesso al browser (nessuna autenticazione OAuth) dall'account di sistema agli URL di Microsoft Federation Gateway seguenti:

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

        Nel browser deve essere visualizzata una pagina XML.

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

        Il browser dovrebbe richiedere di scaricare il file.

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

        Il browser deve visualizzare un elenco di operazioni supportate da ManageDelegation2.

   3. Testare l'accesso al browser (autenticazione OAuth) dall'account di sistema agli URL seguenti del server di autorizzazione Microsoft:

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

        Nel browser dovrebbe essere visualizzato un prompt di accesso.

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

        Il browser dovrebbe visualizzare il messaggio di errore di accesso, "Sorry, but we're having trouble sign in".

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

        Il browser dovrebbe visualizzare il codice 400 Bad Request di stato HTTP o il messaggio di errore di accesso, "Sorry, but we're having trouble sign you in".

Inizio pagina

Individuazione automatica non riuscita per l'indirizzo di posta elettronica: impossibile risolvere il nome remoto

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Individuazione automatica non riuscita per l'indirizzo di posta elettronica dell'utente dell'indirizzo <> di posta elettronica con errore System.Net.WebException: Impossibile risolvere il nome remoto: "<nome> host locale".

Questo errore può verificarsi se l'URL dell'endpoint di individuazione automatica locale o le impostazioni DNS pubbliche non sono corrette.

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Eseguire i cmdlet di PowerShell seguenti in PowerShell di Exchange Online per ottenere il valore del TargetAutodiscoverEpr parametro:

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

   Ad esempio, se il valore del nome host locale nel messaggio di errore è mail.contoso.com, è probabile che l'URL dell'endpoint di individuazione automatica sia https://autodiscover.contoso.com/autodiscover/autodiscover.svc.

   Se il valore del TargetAutodiscoverEpr parametro è corretto, andare al passaggio 3. In caso contrario, andare al passaggio 2.

2. Aggiornare l'URL dell'endpoint di individuazione automatica usando uno dei metodi seguenti:

   • Eseguire la Configurazione guidata ibrida (HCW) per ripristinare l'endpoint di individuazione automatica predefinito.

   • Aggiornare manualmente il DiscoveryEndpoint parametro o il TargetAutodiscoverEpr parametro eseguendo uno dei cmdlet di PowerShell seguenti:

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

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

3. Assicurarsi che il nome host locale nel messaggio di errore ,ad esempio , mail.contoso.comsia risolvibile nel DNS pubblico. La voce DNS per il nome host deve puntare al servizio di individuazione automatica locale in corrispondenza dell'URL dell'endpoint di individuazione automatica.

   Nota: se non è possibile risolvere il problema e si vuole una soluzione temporanea, eseguire uno dei cmdlet di PowerShell seguenti per aggiornare manualmente il valore del TargetSharingEpr parametro all'URL esterno di Exchange Web Services (EWS). L'URL EWS esterno deve essere simile https://<EWS hostname>/ews/exchange.asmx e risolvibile in DNS.

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

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

   Nota

   Se si imposta il valore del TargetSharingEpr parametro, la cassetta postale cloud ignora l'individuazione automatica e si connette direttamente all'endpoint EWS.

Inizio pagina

Impossibile ottenere ASURL. Errore 8004010F

Problema

Si dispone di un utente locale che non può visualizzare le informazioni sulla disponibilità per un utente cloud. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Impossibile ottenere ASURL. Errore 8004010F.

Si tratta di un errore generale correlato al servizio di individuazione automatica.

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Assicurarsi che l'individuazione automatica per l'utente interessato restituisca l'URL di Exchange Web Services (EWS) per l'utente.

2. Eseguire il test di configurazione automatica della posta elettronica nel client Outlook dell'utente interessato per assicurarsi che l'individuazione automatica restituisca l'URL EWS per l'utente.

3. Assicurarsi che la disponibilità funzioni tra gli utenti locali ospitati in server Exchange diversi.

4. Se sono presenti servizi di bilanciamento del carico, verificare se il problema è stato causato dai servizi di bilanciamento del carico. A tale scopo, modificare il file host di Windows (nel computer in cui è installato il client Outlook dell'utente) per ignorare i servizi di bilanciamento del carico e puntare a un server di Accesso client specifico.

5. Se la disponibilità funziona tra gli utenti locali, verificare se tutti i server Exchange locali hanno accesso in uscita agli URL e agli intervalli di indirizzi IP di Microsoft 365.

6. Verificare se ogni server Exchange può recuperare un token di delega. A tale scopo, eseguire il cmdlet di PowerShell seguente in EMS in tutti i server Exchange locali:

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

   Se il comando non riesce a recuperare un token di delega, verificare se il server può connettersi a Office 365 a livello di proxy o firewall.

Inizio pagina

Richiesta Web proxy non riuscita: oggetto spostato

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Richiesta Web proxy non riuscita. , eccezione interna: System.Net.WebException: la richiesta non è riuscita con il messaggio di errore: Oggetto spostato.

Questo errore può verificarsi se il valore del TargetSharingEpr parametro nelle impostazioni dell'organizzazione è impostato su un URL endpoint di Exchange Web Services (EWS) non corretto.

È possibile eseguire i cmdlet di PowerShell seguenti per ottenere il valore del TargetSharingEpr parametro dalle impostazioni dell'organizzazione (connettore all'interno dell'organizzazione o relazione organizzativa):

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

Verificare che il valore del TargetSharingEpr parametro non si risolve nel DNS pubblico.

Nota: la Configurazione guidata ibrida (HCW) non imposta un valore per il TargetSharingEpr parametro a meno che non si selezioni Usa tecnologia ibrida moderna di Exchange per installare un agente ibrido. In questo scenario, HCW imposta il TargetSharingEpr parametro su un valore dell'endpoint URL EWS esterno simile a https://<GUID>.resource.mailboxmigration.his.msappproxy.net/ews/exchange.asmx. È anche possibile impostare manualmente il valore del TargetSharingEpr parametro. Se il TargetSharingEpr valore è impostato su un endpoint, Outlook ignora l'individuazione automatica e si connette direttamente a tale endpoint.

Risoluzione

Per risolvere il problema, eseguire uno dei comandi seguenti per aggiornare manualmente il valore del TargetSharingEpr parametro a un URL EWS esterno che si risolve in DNS:

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

Inizio pagina

La richiesta è stata interrotta: non è stato possibile creare un canale sicuro SSL/TLS

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale o viceversa. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

La richiesta è stata interrotta: non è stato possibile creare un canale sicuro SSL/TLS.

Causa 1: l'utente cloud non può visualizzare le informazioni sulla disponibilità per un utente locale

Il problema può verificarsi se TLS 1.2 non è configurato correttamente o è disabilitato in un endpoint locale a cui Microsoft 365 si connette, ad esempio Exchange Server o un firewall.

Causa 2: l'utente locale non può visualizzare le informazioni sulla disponibilità per un utente cloud

Il problema può verificarsi anche per uno dei motivi seguenti:

• Il certificato Di Microsoft 365 (outlook.office365.com) non è presente nell'archivio autorità di certificazione radice (CA) attendibile.
• Esiste una mancata corrispondenza della suite Cypher .
• Altri problemi SSL/TLS.

Procedura di risoluzione dei problemi

Usare gli strumenti seguenti per diagnosticare i problemi di TLS 1.2 locali:

• Eseguire il test del server SSL in Microsoft Remote Connectivity Analyzer.
• Eseguire lo script HealthChecker in Exchange Management Shell (EMS) in ogni server Exchange.

Per informazioni sulla configurazione di TLS, vedere Procedure consigliate per la configurazione TLS di Exchange Server e Preparazione per TLS 1.2.

Per informazioni su come verificare la presenza di certificati nell'archivio CA radice attendibile, vedere Visualizzare i certificati con lo snap-in MMC.

Per informazioni sui pacchetti di crittografia TLS supportati, vedere Suite di crittografia TLS supportate da Microsoft 365.

Inizio pagina

L'utente specificato dal contesto utente nel token non esiste

Problema

Si dispone di un utente locale che non può visualizzare le informazioni sulla disponibilità per un utente cloud. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

L'utente specificato dal contesto utente nel token non esiste. error_category="invalid_user". 401: Non autorizzato.

Si riceve lo stesso messaggio di errore se si esegue il cmdlet Di PowerShell Test-OAuthConnectivity .

L'errore può verificarsi se la cassetta postale utente locale e l'oggetto utente di posta elettronica corrispondente nell'ID Microsoft Entra non vengono sincronizzati. Fino a quando non vengono sincronizzati, l'oggetto mail-user in Microsoft Entra ID potrebbe non essere sottoposto a provisioning.

Risoluzione

Per risolvere il problema, usare Microsoft Entra Connect per sincronizzare l'utente locale e l'oggetto mail-user corrispondente in Microsoft Entra ID.

Inizio pagina

Il componente hostname del valore dell'attestazione audience non è valido

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Il componente hostname del valore dell'attestazione audience 'https://< hybrid.domain.com>' non è valido; error_category="invalid_resource"

L'errore può verificarsi per uno dei motivi seguenti.

Causa 1

L'offload SSL e l'autenticazione OAuth sono entrambi abilitati. L'offload SSL non funziona se l'autenticazione OAuth è abilitata.

Causa 2

Un dispositivo di rete davanti a Exchange Server blocca le richieste di disponibilità.

Soluzione

Soluzione alternativa per la causa 1

Selezionare una delle soluzioni alternative seguenti:

• Disabilitare l'offload SSL sia per Exchange Web Services (EWS) che per l'individuazione automatica nell'ambiente locale. Per altre informazioni, vedere Configurazione dell'offload SSL per l'individuazione automatica e configurazione dell'offload SSL per EWS e impostazioni SSL predefinite.

• Eseguire il cmdlet di PowerShell seguente per disabilitare l'autenticazione OAuth disabilitando il connettore cloud all'interno dell'organizzazione:

  Set-IntraOrganizationConnector "HybridIOC*" -Enabled $false
  

  Quando il connettore all'interno dell'organizzazione è disabilitato, l'autenticazione DAuth viene abilitata tramite la relazione dell'organizzazione. Per controllare la relazione dell'organizzazione, eseguire il cmdlet di PowerShell seguente:

  Get-OrganizationRelationship
  

  Per altre informazioni sulle impostazioni di relazione dell'organizzazione, vedere Demistificazione della disponibilità ibrida.

Risoluzione della causa 2

Configurare il dispositivo di rete davanti a Exchange per non bloccare le richieste di disponibilità.

Inizio pagina

Richiesta Web proxy non riuscita con stato HTTP 503: Servizio non disponibile

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Richiesta Web proxy non riuscita, eccezione interna: System.Net.WebException: La richiesta non è riuscita con stato HTTP 503: Servizio non disponibile...

Questo errore può verificarsi se è presente un servizio Microsoft Windows arrestato, un componente server, un pool di applicazioni IIS o un endpoint non configurato correttamente.

Procedura di risoluzione dei problemi

Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Assicurarsi che i servizi Windows richiesti da Exchange Server siano in esecuzione. Per controllare lo stato dei servizi, eseguire il cmdlet di PowerShell seguente in ogni server Exchange nell'organizzazione:

   Test-ServiceHealth
   

   Usare la console Servizi per avviare tutti i servizi arrestati richiesti da Exchange Server.

2. Verificare che i componenti di Exchange Server necessari siano attivi. Per controllare lo stato dei componenti, eseguire il cmdlet di PowerShell seguente in ogni server Exchange nell'organizzazione:

   Get-ServerComponentState <server name>
   

   Per attivare un componente inattivo, usare il cmdlet Di PowerShell Set-ServerComponentState .

3. Assicurarsi che i pool di applicazioni IIS seguenti per Exchange Web Services (EWS) e Individuazione automatica siano avviati:

   • MSExchangeServicesAppPool
   • MSExchangeSyncAppPool
   • MSExchangeAutodiscoverAppPool

4. Verificare se l'endpoint di individuazione automatica è valido. attenersi alla seguente procedura:

   1. Eseguire i cmdlet di PowerShell seguenti per ottenere l'URL dell'endpoint di individuazione automatica dai valori dei DiscoveryEndpoint parametri o TargetAutodiscoverEpr :

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

   2. Passare all'URL dell'endpoint di individuazione automatica in un Web browser o eseguire il Invoke-WebRequest -Uri "<endpoint URL>" -Verbose cmdlet di PowerShell per assicurarsi che l'URL sia valido. Preferibilmente, controllare l'URL da una rete esterna.

5. Verificare se l'URL EWS è valido seguendo questa procedura:

   1. Eseguire i cmdlet di PowerShell seguenti per ottenere l'URL EWS dal valore del TargetSharingEpr parametro nelle impostazioni dell'organizzazione:

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

   b. Passare all'URL EWS in un Web browser oppure eseguire il Invoke-WebRequest -Uri "<endpoint URL>" -Verbose cmdlet di PowerShell per assicurarsi che l'URL sia valido. Preferibilmente, controllare l'URL da una rete esterna.

6. Controllare i log IIS per le richieste di disponibilità che restituiscono il codice 503 Service Unavailabledi stato HTTP:

   1. Effettuare una richiesta di disponibilità da Exchange Online.

   2. Verificare la presenza di voci di codice 503 Service Unavailable di stato HTTP nei log iis nella cartella W3SVC1 per il sito Web predefinito in ogni server Exchange. Il percorso della cartella W3SVC1 è %SystemDrive%\inetpub\logs\LogFiles\W3SVC1. Queste voci consentono di identificare il server che presenta il problema.

   3. Se la richiesta di disponibilità non è registrata nella cartella W3SVC1 , verificare se la richiesta è registrata nei log degli errori nella cartella HTTPERR in ogni server Exchange. Il percorso della cartella HTTPERR è %SystemRoot%\System32\LogFiles\HTTPERR. Se la richiesta di disponibilità è registrata nei log HTTPERR , verificare la presenza di impostazioni IIS non configurate correttamente.

7. Controllare l'intestazione della risposta del server ricevuta quando ci si connette all'URL EWS locale per verificare che IIS (non un server Web diverso) ha inviato la risposta. A tale scopo, eseguire i comandi seguenti in una sessione di PowerShell non connessa a EWS locale (non eseguire i comandi in 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"]
   

   Ad esempio, se viene visualizzato "Microsoft-HTTPAPI/2.0" nell'output del comando anziché "Microsoft -IIS/10.0", è probabile che un servizio WEB Application Proxy (WAP) (non IIS) abbia risposto alla richiesta. Controllare se il servizio WAP è inattivo.

Inizio pagina

Richiesta Web proxy non riuscita con stato HTTP 504: timeout del gateway

LID: 43532

Problema

Si dispone di un utente cloud che non può visualizzare le informazioni sulla disponibilità per un utente locale. Quando si diagnostica il problema, viene visualizzato il messaggio di errore seguente:

Richiesta Web proxy non riuscita, eccezione interna: la richiesta non è riuscita con stato HTTP 504: Timeout gateway...

Questo errore può verificarsi se un agente ibrido nell'organizzazione è configurato in modo non corretto.

Risoluzione

Per risolvere il problema, seguire questa procedura. Dopo aver completato ogni passaggio, verificare se il problema di disponibilità è stato risolto.

1. Controllare il valore del TargetSharingEpr parametro nelle impostazioni dell'organizzazione. Il valore deve essere simile a https://<GUID>.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx. Per determinare il valore del TargetSharingEpr parametro, eseguire i cmdlet di PowerShell seguenti:

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

   Se il valore del TargetSharingEpr parametro non è corretto:

   1. Eseguire la Configurazione guidata ibrida (HCW) e selezionare Usa topologia ibrida classica di Exchange.

   2. Eseguire di nuovo HCW e selezionare Usa topologia ibrida moderna di Exchange. Questa procedura impone all'HCW di reimpostare il valore del TargetSharingEpr parametro.

2. Controllare lo stato del servizio ibrido Microsoft nel server in cui è installato l'agente ibrido. Se il servizio viene arrestato, avviarlo.

3. Controllare lo stato dell'agente ibrido. Se lo stato è Inattivo:

   1. Eseguire la Configurazione guidata ibrida (HCW) e selezionare Usa topologia ibrida classica di Exchange.

   2. Eseguire di nuovo HCW e selezionare Usa topologia ibrida moderna di Exchange. Questa procedura impone all'HCW di reinstallare l'agente ibrido.

   3. Installare il modulo PowerShell dell'agente ibrido e quindi eseguire il cmdlet Di PowerShell Get-HybridApplication per trovare l'URL interno a cui punta l'agente ibrido.

4. Passare all'URL interno trovato nel passaggio 3. Risolvere eventuali errori rilevati, ad esempio errori del certificato.

5. Configurare l'agente ibrido per indirizzare le richieste a un servizio di bilanciamento del carico anziché a un server che esegue Microsoft Exchange Server per escludere i problemi che potrebbero esistere in tale server.

6. Verificare che l'agente ibrido supporti le richieste di disponibilità e la migrazione delle cassette postali.

Inizio pagina