Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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.
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.
Seguire questa procedura per attivare/disattivare l'autenticazione WSSecurity:
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 eGet-WebServicesVirtualDirectory
indicare che l'autenticazione WSSecurity è già abilitata.La procedura interessa solo la disponibilità cross-premise e non influisce sulle altre connessioni client-server.
Eseguire il
iisreset /noforce
comando in una finestra di PowerShell o del prompt dei comandi in ogni server Exchange locale per riavviare IIS.Riavviare tutti i server Exchange locali.
Controllare e risolvere eventuali avvisi o errori di asimmetria del tempo nel registro eventi di sistema.
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 parametriTargetAutodiscoverEpr
di individuazione automatica oDiscoveryEndpoint
contengono in genere l'URL esterno EWS locale (endpoint di individuazione automatica). Per ottenere i valori deiTargetAutodiscoverEpr
parametri eDiscoveryEndpoint
, eseguire i cmdlet di PowerShell seguenti:Get-OrganizationRelationship | FL TargetAutodiscoverEpr Get-IntraOrganizationConnector | FL DiscoveryEndpoint
Assicurarsi che il valore del
TargetApplicationUri
parametro nella relazione organizzativa corrisponda al valore delAccountNamespace
parametro nell'identificatore dell'organizzazione federata. Per trovare il valore delTargetApplicationUri
parametro, eseguire il cmdlet Di PowerShell Test-OrganizationRelationship . Per trovare il valore delAccountNamespace
parametro, vedere Demistificazione della disponibilità ibrida.
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.
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.
Verificare che le richieste provenienti da Exchange Online raggiungano i server Accesso client locali. Seguire questa procedura in tutti i server Accesso client locali:
Effettuare una richiesta di disponibilità da Exchange Online.
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
.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
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".
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 Found
di 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.
Controllare se l'endpoint di individuazione automatica è valido:
Eseguire i comandi seguenti per ottenere l'URL dell'endpoint di individuazione automatica dal
DiscoveryEndpoint
parametro oTargetAutodiscoverEpr
:Get-IntraOrganizationConnector | FL DiscoveryEndpoint Get-OrganizationRelationship | FL TargetAutodiscoverEpr
Passare all'URL dell'endpoint di individuazione automatica in un Web browser. Un endpoint di individuazione automatica valido non restituirà il codice
404 Not Found
di stato HTTP.
Assicurarsi che il dominio dell'utente locale sia specificato nelle impostazioni dell'organizzazione (connettore all'interno dell'organizzazione o relazione organizzativa) dell'utente cloud:
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'utenteuser2@contoso.ro
locale, verificare che il dominiocontoso.ro
locale sia elencato.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>"}
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.
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:
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 ouser@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.
Modificare l'indirizzo duplicato o eliminare l'oggetto utente duplicato.
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.
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.
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.
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.
Seguire questa procedura per attivare/disattivare l'autenticazione WSSecurity:
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.
Riciclare i pool di applicazioni EWS e individuazione automatica in Gestione IIS.
Eseguire il
iisreset /noforce
comando in una finestra di PowerShell o del prompt dei comandi in ogni server Exchange locale per riavviare IIS.
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.
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.
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:
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'utenteuser2@contoso.ro
locale, verificare che il dominiocontoso.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.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:
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'utenteuser2@contoso.com
cloud, verificare che il dominiocontoso.com
cloud sia presente nell'output di entrambi i comandi.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>"}
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.
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.
Verificare se la preautenticazione è abilitata. attenersi alla seguente procedura:
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.
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à.
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.
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
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. IlMicrosoftOnline
trust è un'istanza aziendale del gateway federativo Microsoft.Per un trust federativo aggiornato, assicurarsi che sia
ApplicationIdentifier
260563
e non292841
e che siaApplicationUri
outlook.com
e nonoutlook.live.com
. Se si dispone di un trust federativo obsoleto, contattare il supporto tecnico Microsoft.
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
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 auser1@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.
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.
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.
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'utenteDefault
nell'output del comando deve essereAvailabilityOnly
oLimitedDetails
. Se ilAccessRights
valore èNone
, eseguire il cmdlet di PowerShell seguente per impostare tale valoreAvailabilityOnly
su oLimitedDetails
:Set-MailboxFolderPermission -Identity <mailbox ID>:\Calendar -AccessRights <access rights value>
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 esempiolucine.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 esempiolucine.homsi@contoso.com
.
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
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
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ù.
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.com
di 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à perchanok@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 suchanok@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
).
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:
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.
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.
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.
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.
Eseguire il cmdlet di PowerShell seguente per rimuovere tutti i riferimenti al certificato precedente:
Set-AuthConfig -ClearPreviousCertificate
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.
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:
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.
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"
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.
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:
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
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:
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:
Reimpostare la password dell'utente cloud. Scegliere la stessa password o una password diversa.
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 euser@contoso.mail.onmicrosoft.com
quindi ripristinare l'UPN suuser@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>
Assicurarsi che il
ImmutableId
valore dell'oggetto utente locale sia Null. Controllare ilImmutableId
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: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
.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
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
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 ilImmutableId
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
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.
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>
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.
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.
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.
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.
Assicurarsi che l'account di sistema in Exchange Server abbia accesso a Internet agli URL seguenti. Seguire questa procedura in ogni server Exchange:
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"
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.
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 Request
di stato HTTP o il messaggio di errore di accesso"Sorry, but we're having trouble sign you in".
Ottenere i dettagli di una richiesta di disponibilità controllando i log di Exchange Web Services (EWS):
Effettuare una richiesta di disponibilità da Exchange Online.
Trovare la voce nei log EWS e controllare il valore nella
time-taken
colonna. I log EWS si trovano nella cartella %ExchangeInstallPath%\Logging\Ews .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
.
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.
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 euser@contoso.mail.onmicrosoft.com
quindi ripristinare l'UPN suuser@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>
Controllare le regole, gli endpoint e i log di AD FS.
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
otony.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: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
.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
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
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 ilImmutableId
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
Controllare le impostazioni delle relazioni dell'organizzazione. Per altre informazioni, vedere Demistificazione della disponibilità ibrida.
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:
Eseguire i cmdlet di PowerShell seguenti:
Test-FederationTrust -UserIdentity <on-premises user> -Verbose -Debug
Ricreare il trust federativo. Per altre informazioni, vedere Rimuovere un trust federativo e Configurare un trust federativo.
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.
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:
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*
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.
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.asmx
esempio .
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.
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.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.
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:
Determinare se il certificato OAuth di Exchange Server locale esiste nell'organizzazione di Exchange Online:
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 .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 ilThumbprint
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.
Sostituire il certificato locale esistente con il certificato Exchange Online:
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.
Eseguire il cmdlet di PowerShell seguente per pubblicare il certificato locale:
Set-AuthConfig -PublishCertificate
Eseguire il cmdlet di PowerShell seguente per rimuovere tutti i riferimenti al certificato precedente:
Set-AuthConfig -ClearPreviousCertificate
Andare al passaggio 4.
Esportare il certificato di autorizzazione locale e quindi caricare il certificato nell'organizzazione exchange online.
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"
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.
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 o401 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.
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.
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.
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
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.
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:
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"
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.
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".
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.
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 siahttps://autodiscover.contoso.com/autodiscover/autodiscover.svc
.Se il valore del
TargetAutodiscoverEpr
parametro è corretto, andare al passaggio 3. In caso contrario, andare al passaggio 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 ilTargetAutodiscoverEpr
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>
Assicurarsi che il nome host locale nel messaggio di errore ,ad esempio ,
mail.contoso.com
sia 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 similehttps://<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.
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.
Assicurarsi che l'individuazione automatica per l'utente interessato restituisca l'URL di Exchange Web Services (EWS) per l'utente.
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.
Assicurarsi che la disponibilità funzioni tra gli utenti locali ospitati in server Exchange diversi.
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.
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.
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.
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>
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.
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.
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à.
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.
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.
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 .
Assicurarsi che i pool di applicazioni IIS seguenti per Exchange Web Services (EWS) e Individuazione automatica siano avviati:
- MSExchangeServicesAppPool
- MSExchangeSyncAppPool
- MSExchangeAutodiscoverAppPool
Verificare se l'endpoint di individuazione automatica è valido. attenersi alla seguente procedura:
Eseguire i cmdlet di PowerShell seguenti per ottenere l'URL dell'endpoint di individuazione automatica dai valori dei
DiscoveryEndpoint
parametri oTargetAutodiscoverEpr
:Get-IntraOrganizationConnector | FL DiscoveryEndpoint Get-OrganizationRelationship | FL TargetAutodiscoverEpr
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.
Verificare se l'URL EWS è valido seguendo questa procedura:
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.Controllare i log IIS per le richieste di disponibilità che restituiscono il codice
503 Service Unavailable
di stato HTTP:Effettuare una richiesta di disponibilità da Exchange Online.
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.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.
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.
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.
Controllare il valore del
TargetSharingEpr
parametro nelle impostazioni dell'organizzazione. Il valore deve essere simile ahttps://<GUID>.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx
. Per determinare il valore delTargetSharingEpr
parametro, eseguire i cmdlet di PowerShell seguenti:Get-IntraOrganizationConnector | FL TargetSharingEpr Get-OrganizationRelationship | FL TargetSharingEpr
Se il valore del
TargetSharingEpr
parametro non è corretto:Eseguire la Configurazione guidata ibrida (HCW) e selezionare Usa topologia ibrida classica di Exchange.
Eseguire di nuovo HCW e selezionare Usa topologia ibrida moderna di Exchange. Questa procedura impone all'HCW di reimpostare il valore del
TargetSharingEpr
parametro.
Controllare lo stato del servizio ibrido Microsoft nel server in cui è installato l'agente ibrido. Se il servizio viene arrestato, avviarlo.
Controllare lo stato dell'agente ibrido. Se lo stato è Inattivo:
Eseguire la Configurazione guidata ibrida (HCW) e selezionare Usa topologia ibrida classica di Exchange.
Eseguire di nuovo HCW e selezionare Usa topologia ibrida moderna di Exchange. Questa procedura impone all'HCW di reinstallare l'agente ibrido.
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.
Passare all'URL interno trovato nel passaggio 3. Risolvere eventuali errori rilevati, ad esempio errori del certificato.
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.