Resolver erros de disponibilidade

Para resolver um erro relacionado com informações de disponibilidade, selecione a mensagem de erro aplicável no índice na parte superior deste artigo.

Se os passos de resolução de problemas não o ajudarem a resolver o problema, contacte o Suporte da Microsoft.

Ocorreu um erro ao verificar a segurança da mensagem

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

Falha na deteção automática do endereço <de e-mail smtp address> com o erro System.Web.Services.Protocols.SoapHeaderException: Ocorreu um erro ao verificar a segurança da mensagem em System.Web. Services.Protocols. SoapHttpClientProtocol. ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) em System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

Este erro pode ocorrer se a autenticação WSSecurity não estiver ativada ou tiver de ser reposta ou após renovar os certificados de federação no Exchange Server.

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Para atualizar metadados no Gateway de Federação da Microsoft, execute o seguinte comando duas vezes na Shell de Gestão do Exchange (EMS) no local:

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Para obter mais informações, veja Pesquisas de disponibilidade deixam de funcionar num ambiente em vários locais ou numa implementação híbrida do Exchange Server.

2. Siga estes passos para ativar/desativar a autenticação WSSecurity:

   1. Siga o procedimento em Os utilizadores de uma organização federada não conseguem ver as informações de disponibilidade de outra organização do Exchange para ativar ou repor, se já estiver ativada, a autenticação WSSecurity nos diretórios virtuais de Deteção Automática e EWS em todos os servidores exchange no local.

      Notas

      • Execute este passo mesmo que a saída dos cmdlets Get-AutodiscoverVirtualDirectory do PowerShell e Get-WebServicesVirtualDirectory indique que a autenticação WSSecurity já está ativada.

      • O procedimento afeta apenas a disponibilidade em vários locais e não afetará outras ligações cliente-servidor.

   2. Execute o comando numa janela do iisreset /noforce PowerShell ou da Linha de Comandos em cada servidor Exchange no local para reiniciar o IIS.

   3. Reinicie todos os servidores exchange no local.

3. Verifique e resolva quaisquer avisos ou erros de distorção de tempo no registo de eventos do Sistema.

4. Defina o valor do TargetSharingEpr parâmetro na relação da organização para o URL dos Serviços Web do Exchange (EWS) externos no local ao executar o seguinte cmdlet no PowerShell do Exchange Online:

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

   Depois de definir o valor do TargetSharingEpr parâmetro, a caixa de correio na nuvem ignora a Deteção Automática e liga-se diretamente ao ponto final do EWS da caixa de correio no local.

   Nota: o valor predefinido do TargetSharingEpr parâmetro está em branco. Os parâmetros TargetAutodiscoverEpr de Deteção Automática ou DiscoveryEndpoint , normalmente, contêm o URL externo do EWS no local (ponto final de Deteção Automática). Para obter os valores de TargetAutodiscoverEpr parâmetro e DiscoveryEndpoint , execute os seguintes cmdlets do PowerShell:

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

5. Confirme que o valor do TargetApplicationUri parâmetro na relação da organização corresponde ao valor do AccountNamespace parâmetro no identificador da organização federada. Para localizar o valor do TargetApplicationUri parâmetro, execute o cmdlet Test-OrganizationRelationship do PowerShell. Para localizar o valor do AccountNamespace parâmetro, veja Desmistificar a disponibilidade híbrida.

Voltar ao início

Falha no pedido Web do proxy: não é possível ligar ao servidor remoto

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local ou vice-versa. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

O pedido Web do proxy falhou. , exceção interna: System.Net.WebException: Não é possível ligar ao servidor remoto; System.Net.Sockets.SocketException: Uma tentativa de ligação falhou porque a parte ligada não respondeu corretamente após um período de tempo ou a ligação estabelecida falhou porque o anfitrião ligado não respondeu CUSTOMER_IP:443 / MICROSOFT_IP:443 em System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)

Este erro pode ocorrer se os problemas de conectividade de rede impedirem ligações de entrada ou saída entre endereços IP no Exchange Online e pontos finais no Exchange Server.

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Verifique se a firewall em cada servidor Exchange no local permite ligações de entrada ou saída entre pontos finais do Exchange Server e endereços IP do Exchange Online. Para identificar problemas de firewall, faça um pedido de disponibilidade a partir do Exchange Online e, em seguida, verifique a firewall no local, o proxy inverso e os registos de rede. Para obter mais informações sobre como configurar uma firewall, veja Considerações sobre a firewall para delegação federada e intervalos de URLs e endereços IP do Microsoft 365.

2. Verifique se os pedidos do Exchange Online chegam aos servidores de Acesso de Cliente no local. Siga estes passos em todos os servidores de Acesso de Cliente no local:

   1. Faça um pedido de disponibilidade a partir do Exchange Online.

   2. Verifique os registos do IIS na pasta W3SVC1 do site predefinido para verificar se o pedido de disponibilidade está registado. O caminho da pasta W3SVC1 é %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

   3. Verifique os registos de proxy HTTP nas seguintes pastas para verificar se o pedido de disponibilidade está registado:

      • %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover

      • %ExchangeInstallPath%\Logging\HttpProxy\Ews

3. Teste a conectividade do Exchange Online para o ponto final do Exchange Web Services (EWS) no local ao executar o seguinte cmdlet no Exchange Online PowerShell:

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

   Notas

   • Este teste é útil se restringir as ligações de entrada da Internet para permitir que apenas os endereços IP do Exchange Online se liguem ao ponto final do EWS no local.

   • Se apenas alguns utilizadores da nuvem forem afetados por este problema e as respetivas caixas de correio estiverem alojadas no mesmo servidor de correio no Exchange Online, verifique se esse servidor de e-mail pode ligar-se a pontos finais no local. É possível que um ponto final no local bloqueie as ligações do endereço IP externo de saída desse servidor de correio.

   • Quando lhe forem pedidas credenciais, introduza as credenciais de administrador de domínio no formato "domínio\administrador".

Voltar ao início

Falha na Deteção Automática para o endereço de e-mail: estado HTTP 404

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

Falha na deteção automática do endereço <de e-mail do endereço de e-mail endereço> SMTP com o erro System.Net.WebException: O pedido falhou com o código 404 Not Foundde estado HTTP .

Este erro pode ocorrer se os pontos finais da Deteção Automática não estiverem funcional ou estiverem configurados incorretamente.

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Verifique se o ponto final da Deteção Automática é válido:

   1. Execute os seguintes comandos para obter o URL do ponto final da Deteção Automática a DiscoveryEndpoint partir do parâmetro ou TargetAutodiscoverEpr :

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

   2. Navegue para o URL do ponto final de Deteção Automática num browser. Um ponto final de Deteção Automática válido não devolverá o código 404 Not Foundde estado HTTP .

2. Certifique-se de que o domínio do utilizador no local está especificado nas definições da organização (conector intra-organização ou relação de organização) do utilizador da cloud:

   1. Execute os seguintes cmdlets do PowerShell no PowerShell do Exchange Online:

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

      Verifique se o domínio do utilizador no local está listado na saída de qualquer um dos comandos. Por exemplo, se o utilizador user1@contoso.com da cloud procurar o utilizador no local user2@contoso.rolivre/ocupado, verifique se o domínio contoso.ro no local está listado.

   2. Se o domínio do utilizador no local não existir nas definições da organização do utilizador da cloud, adicione o domínio ao executar o seguinte cmdlet do PowerShell:

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

3. Confirme que o mapeamento do processador SVC existe nos diretórios virtuais de Deteção Automática e EWS em Web Site Predefinido no Gestor do IIS. Para obter mais informações, veja FederationInformation couldn't be received and Exception has been thrown by the target(Não foi possível receber a FederationInformation) e Exception has been thrown by the target (Exceção foi emitida pelo destino).

   Nota: o AutodiscoverDiscoveryHander mapeamento (*.svc) não é utilizado para pesquisa de federação livre/ocupada.

Voltar ao início

O pedido Web do proxy de exceção falhou

TAMPA: 43532

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

O pedido Web do Proxy de Exceções falhou. , exceção interna: o pedido falhou com o estado HTTP 401: Diagnósticos não autorizados: 2000005; reason= "O utilizador especificado pelo contexto de utilizador no token é ambíguo." ; error_category="invalid_user"

Este erro pode ocorrer se o endereço UPN, o endereço SMTP ou o endereço SIP do utilizador no local forem utilizados por outra caixa de correio no local.

Resolução

Para corrigir o problema, siga estes passos:

1. Procure objetos de utilizador no local que tenham um UPN duplicado, endereço SMTP ou endereço SIP através de consultas LDAP personalizadas. Pode executar consultas LDAP com LDP.exe ou o snap-in MMC Utilizadores e Computadores do Active Directory.

   Por exemplo, para mostrar todos os utilizadores que têm user@corp.contoso.com como UPN, user@contoso.com como o endereço SMTP ou user@contoso.com como endereço SIP, utilize a seguinte consulta LDAP:

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

   Para obter mais informações sobre como utilizar LDP.exe ou Utilizadores e Computadores do Active Directory para localizar objetos do Active Directory, veja Exemplos de LDP.

2. Altere o endereço duplicado ou elimine o objeto de utilizador duplicado.

Voltar ao início

Uma ligação existente foi forçada a fechar pelo anfitrião remoto

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

O pedido Web do proxy falhou. , exceção interna: System.Net.WebException: A ligação subjacente foi fechada: ocorreu um erro inesperado numa receção. System.IO.IOException: Não é possível ler dados da ligação de transporte: uma ligação existente foi forçada a fechar pelo anfitrião remoto. System.Net.Sockets.SocketException: uma ligação existente foi forçada a fechar pelo anfitrião remoto.

Este erro pode ocorrer se uma firewall no local bloquear uma ligação de entrada a partir de um endereço IP de saída externo no Exchange Online.

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Verifique se os pedidos de disponibilidade do Exchange Online chegam ao IIS num servidor Exchange. Faça um pedido de disponibilidade a partir do Exchange Online e procure as seguintes entradas de registo do IIS efetuadas no momento do pedido de disponibilidade:

   • Uma entrada de Deteção Automática na pasta %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover que contém "ASAutoDiscover/CrossForest/EmailDomain".

     Nota: se definir manualmente o TargetSharingEpr parâmetro na relação da organização para o URL dos Serviços Web do Exchange (EWS) externos no local, a Deteção Automática será ignorada e esta entrada não existirá.

   • Uma entrada EWS na pasta %ExchangeInstallPath%\Logging\HttpProxy\Ews que contém "ASProxy/CrossForest/EmailDomain".

   Nota: os carimbos de data/hora nos registos do IIS utilizam a hora UTC.

2. Verifique se a firewall em cada servidor Exchange no local permite ligações de entrada ou saída entre pontos finais do Exchange Server e endereços IP do Exchange Online. Para identificar problemas de firewall, faça pedidos de disponibilidade a partir do Exchange Online e, em seguida, verifique a firewall no local, o proxy inverso e os registos de rede. Para obter mais informações sobre como configurar uma firewall, veja Considerações sobre a firewall para delegação federada e intervalos de URLs e endereços IP do Microsoft 365.

3. Se a sua organização utilizar relações organizacionais para implementar a disponibilidade, certifique-se de que está instalado um certificado de federação em cada servidor Exchange. Execute os seguintes comandos na Shell de Gestão do Exchange (EMS):

   Test-FederationTrustCertificate
   Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo | FL
   

   Se o certificado de federação estiver instalado, a saída do comando não deve conter erros ou avisos.

4. Siga estes passos para ativar/desativar a autenticação WSSecurity:

   1. Siga o procedimento em Os utilizadores de uma organização federada não conseguem ver as informações de disponibilidade de outra organização do Exchange para ativar ou repor, se já estiver ativada, a autenticação WSSecurity nos diretórios virtuais de Deteção Automática e EWS em todos os servidores exchange no local. Execute este passo mesmo que a autenticação WSSecurity já esteja ativada.

   2. Recicle os conjuntos aplicacionais Deteção Automática e EWS no Gestor do IIS.

   3. Execute o comando numa janela do iisreset /noforce PowerShell ou da Linha de Comandos em cada servidor Exchange no local para reiniciar o IIS.

5. Se apenas alguns utilizadores da nuvem forem afetados por este problema e as respetivas caixas de correio estiverem alojadas no mesmo servidor de correio no Exchange Online, verifique se esse servidor de e-mail pode ligar-se a pontos finais no local. É possível que um ponto final no local bloqueie as ligações do endereço IP de saída desse servidor de correio.

Voltar ao início

Não foi possível encontrar informações de configuração para a floresta/domínio no Active Directory

TAMPA: 47932

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local ou vice-versa. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

Não foi possível encontrar informações de configuração para o domínio de floresta/domínio <> no Active Directory.

Este erro pode ocorrer se as definições da organização estiverem configuradas incorretamente.

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Verifique se o domínio de um utilizador cujas informações de disponibilidade são pedidas existe nas definições da organização do utilizador que está a tentar ver as informações de disponibilidade. Selecione um dos seguintes procedimentos consoante a direção de disponibilidade.

   • Cloud para o local

     Para um utilizador da cloud que tente ver as informações de disponibilidade de um utilizador no local, siga estes passos:

     1. Ligue-se ao PowerShell do Exchange Online e, em seguida, execute os seguintes cmdlets do PowerShell para obter os domínios federados:

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

        Verifique se o domínio do utilizador no local está listado na saída de qualquer um dos comandos. Por exemplo, se o utilizador user1@contoso.com da cloud procurar o utilizador no local user2@contoso.rolivre/ocupado, verifique se o domínio contoso.ro no local está listado.

        Nota

        Também pode encontrar os nomes de domínio ao executar (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses no PowerShell do Exchange Online ou ao executar (Get-FederatedOrganizationIdentifier).Domains na Shell de Gestão do Exchange (EMS) no local.

     2. Se o domínio do utilizador no local não existir nas definições da organização do utilizador da cloud, adicione o domínio ao executar o seguinte cmdlet do PowerShell:

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

   • No local para a cloud

     Para um utilizador no local que tente ver as informações de disponibilidade de um utilizador na cloud, siga estes passos:

     1. No EMS, execute os seguintes cmdlets do PowerShell:

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

        Verifique se o domínio do utilizador da cloud corresponde a um dos domínios listados na saída do comando. Por exemplo, se o utilizador user1@contoso.ro no local procurar informações de disponibilidade para o utilizador user2@contoso.comda cloud, verifique se o domínio contoso.com da cloud está presente na saída de qualquer um dos comandos.

     2. Se o domínio do utilizador da cloud não existir nas definições da organização do utilizador no local, adicione o domínio. Execute o seguinte comando:

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

2. Certifique-se de que a implementação híbrida do Exchange tem uma configuração híbrida completa. Se for necessário, execute novamente o Assistente de Configuração Híbrida (HCW) e selecione Configuração Híbrida Completa em vez de Configuração Híbrida Mínima. Uma configuração híbrida mínima não cria uma relação de organização (confiança de federação) ou conectores intra-organização.

Voltar ao início

O pedido Web do proxy falhou: estado HTTP 401

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará uma das seguintes mensagens de erro.

Mensagem de erro 1

O pedido Web do proxy falhou. ,exceção interna: o pedido falhou com o estado HTTP 401: Não autorizado.

Mensagem de erro 2

Falha na deteção automática do endereço de e-mail. ,exceção interna: o pedido falhou com o estado HTTP 401: Não autorizado.

Este erro pode ocorrer se um dispositivo de perímetro à frente do Exchange Server estiver configurado para pré-autenticar (exigir nome de utilizador e palavra-passe) em vez de passar pedidos do Exchange Online diretamente para o Exchange Server. Os diretórios virtuais de Deteção Automática e EWS em implementações híbridas do Exchange não suportam a pré-autenticação.

Exemplos de dispositivos de perímetro incluem proxies inversos, firewalls e Microsoft Threat Management Gateway (TMG).

A mensagem de erro 1 indica que um pedido EWS falhou.

A mensagem de erro 2 indica que um pedido de Deteção Automática falhou.

Passos de resolução do problema

Para resolver o problema de disponibilidade independentemente da mensagem de erro que recebeu, utilize os seguintes passos. Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Verifique se a pré-autenticação está ativada. Siga estes passos:

   1. Execute o teste De Disponibilidade no Analisador de Conectividade Remota para verificar se a pré-autenticação está ativada. A caixa de correio na nuvem é a Caixa de Correio de Origem e a caixa de correio no local é a Caixa de Correio de Destino. Após a conclusão do teste, verifique o estado de autenticação pass-through no ponto final. Se vir uma marca de verificação vermelha, desative a pré-autenticação e teste novamente. Se vir uma marca de verificação verde, avance para o passo seguinte porque pode ser um falso positivo.

   2. Verifique se um pedido de disponibilidade do Exchange Online chega ao IIS. Execute uma consulta de disponibilidade e, em seguida, pesquise nos registos do IIS no Exchange Server qualquer uma das seguintes entradas no momento da consulta:

      • Na pasta %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover , procure uma entrada de Deteção Automática que tenha o código 401 Unauthorized de estado HTTP e contenha o texto "ASAutoDiscover/CrossForest/EmailDomain".

        Nota: se o TargetSharingEpr parâmetro na relação da organização especificar um URL externo do EWS no local, a Deteção Automática será ignorada e esta entrada não será apresentada.

      • Na pasta %ExchangeInstallPath%\Logging\HttpProxy\Ews , procure uma entrada EWS que tenha o código 401 Unauthorized de estado HTTP e contenha o texto "ASProxy/CrossForest/EmailDomain".

      Nota: os carimbos de data/hora nos registos do IIS utilizam a hora UTC. Algumas entradas com o código 401 Unauthorized de estado HTTP são normais.

      As entradas especificadas indicam que o pedido de disponibilidade chegou ao IIS e, normalmente, exclui problemas de pré-autenticação. Se não encontrar as entradas especificadas, verifique os registos do proxy inverso e da firewall para compreender onde o pedido de disponibilidade ficou bloqueado.

2. Confirme que ativou a autenticação WSSecurity (Exchange Server 2010) ou OAuth (Exchange Server 2013 e versões posteriores) nos diretórios virtuais EWS e Autodiscover. Além disso, verifique se ativou as predefinições de autenticação no IIS para os diretórios virtuais de Deteção Automática e EWS. Para obter mais informações, veja Predefinições de autenticação para diretórios virtuais do Exchange e Predefinições para diretórios virtuais do Exchange.

3. Siga os passos de resolução em Ocorreu um erro ao verificar a segurança da mensagem. Se o WSSecurity estiver configurado, certifique-se de que executa o passo que ativa o WSSecurity. Se a autenticação OAuth estiver configurada em vez de WSSecurity, ative a autenticação OAuth nos diretórios virtuais de Deteção Automática e EWS ao executar os seguintes comandos:

   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. Verifique se tem uma confiança de federação atualizada. Execute o seguinte comando no PowerShell do Exchange Online para obter as informações de fidedignidade de federação para a sua organização do Exchange:

   Get-FederationTrust
   

   A saída do comando deve conter as seguintes informações:

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

   Nota: a WindowsLiveId confiança é uma instância de consumidor do Gateway de Federação da Microsoft. A MicrosoftOnline confiança é uma instância empresarial do Gateway de Federação da Microsoft.

   Para uma confiança de federação atualizada, certifique-se de que ApplicationIdentifier é e não 292841, e que ApplicationUri é outlook.com e não outlook.live.com260563 . Se tiver uma confiança de federação desatualizada, contacte o Suporte da Microsoft.

Voltar ao início

Falha na Deteção Automática para o endereço de e-mail: InvalidUser

TAMPA: 33676

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

A resposta do serviço de Deteção Automática em "https://Autodiscover/Autodiscover.svc/WSSecurity" falhou devido a um erro na definição do utilizador "ExternalEwsUrl". Mensagem de erro: InvalidUser.

A mensagem de erro pode aparecer quando executar o teste De Disponibilidade no Analisador de Conectividade Remota.

Este erro pode ocorrer se a caixa de correio na nuvem ou o ponto final de Deteção Automática estiverem configurados incorretamente.

Passos de resolução do problema

1. Verifique se o utilizador da cloud tem um endereço SMTP secundário que inclui o onmicrosoft.com domínio ao executar o seguinte comando:

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

   Por exemplo, um utilizador que tenha o endereço user1@contoso.com SMTP principal deve ter um endereço SMTP secundário semelhante a user1@contoso.mail.onmicrosoft.com.

   Se o utilizador da cloud for gerido a partir do Exchange Server, adicione o endereço SMTP secundário ao Exchange Server e, em seguida, sincronize os dados de identidade entre o seu ambiente no local e o Microsoft Entra ID.

2. Execute os seguintes comandos para definir o valor do TargetSharingEpr parâmetro na relação da organização para o URL dos Serviços Web do Exchange (EWS) externos no local:

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

   Depois de definir o valor do TargetSharingEpr parâmetro, a caixa de correio na nuvem ignora a Deteção Automática e liga-se diretamente ao ponto final do EWS da caixa de correio no local.

Voltar ao início

O autor da chamada não tem acesso a dados de disponibilidade

TAMPA: 47652, 44348, 40764

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local ou vice-versa. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException: o autor da chamada não tem acesso a dados de disponibilidade.

Este erro pode ocorrer se a caixa de correio do utilizador cujas informações de disponibilidade são pedidas estiver configurada incorretamente.

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Verifique as permissões de calendário do utilizador cujas informações de disponibilidade são pedidas ao executar o seguinte comando:

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

   O AccessRights valor para o Default utilizador na saída do comando deve ser AvailabilityOnly ou LimitedDetails. Se o AccessRights valor for None, execute o seguinte cmdlet do PowerShell para definir esse valor como ou LimitedDetailsAvailabilityOnly :

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

2. Utilize o método aplicável para verificar a relação da organização:

   • Se um utilizador da cloud não conseguir ver as informações de disponibilidade de um utilizador no local:

     Verifique se a relação da organização no local especifica o domínio da cloud que pode aceder às informações de disponibilidade no local. Um domínio de cloud de exemplo é contoso.mail.onmicrosoft.com. Para obter informações sobre como modificar a relação da organização no Exchange Server, veja Utilizar o PowerShell para modificar a relação da organização. Verifique também se o endereço de e-mail Do do utilizador da cloud tem o mesmo domínio na cloud, por exemplo lucine.homsi@contoso.mail.onmicrosoft.com.

   • Se um utilizador no local não conseguir ver as informações de disponibilidade de um utilizador na cloud:

     Verifique se a relação da organização na cloud especifica o domínio no local que pode aceder às informações de disponibilidade da cloud. Um exemplo de domínio no local é contoso.com. Para obter informações sobre como modificar a relação da organização no Exchange Online, consulte Utilizar o PowerShell do Exchange Online para modificar a relação da organização. Verifique também se o endereço de e-mail Do do utilizador no local tem o mesmo domínio no local, por exemplo lucine.homsi@contoso.com.

Voltar ao início

Ocorreu um erro ao processar os tokens de segurança na mensagem

TAMPA: 59916

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

ProxyWebRequestProcessingException ErrorProxyRequestProcessingFailed
O pedido Web do proxy falhou. , exceção interna: ocorreu um erro ao processar os tokens de segurança na mensagem.

Este erro pode ocorrer se os certificados ou metadados no Gateway de Federação da Microsoft forem inválidos.

Passos de resolução do problema

1. Verifique a data de expiração e os thumbprints dos certificados de fidedignidade de federação no local ao executar os seguintes cmdlets do PowerShell:

   Get-FederationTrust | FL
   Test-FederationTrust
   Test-FederationTrustCertificate
   

2. Para atualizar metadados no Gateway de Federação da Microsoft, execute o seguinte comando duas vezes na Shell de Gestão do Exchange (EMS) no local:

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Para obter mais informações, consulte Pesquisas de disponibilidade deixam de funcionar.

Voltar ao início

O pedido entre organizações não é permitido porque o requerente é de uma organização diferente

TAMPA: 39660

Problema

Tem um cenário de malha híbrida no qual um utilizador da cloud num inquilino não híbrido do Exchange Online não consegue ver as informações de disponibilidade de um utilizador na cloud noutro inquilino do Exchange Online que fica híbrido. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

O pedido entre organizações para o endereço> SMTP da caixa <de correio não é permitido porque o requerente é de uma organização diferente
Destinatário: <endereço SMTP>
Tipo de Exceção: CrossOrganizationProxyNotAllowedForExternalOrganization
Mensagem de Exceção: o pedido entre organizações para <o endereço> SMTP não é permitido porque o requerente é de uma organização diferente.

Por exemplo, um utilizador lucine@adatum.com num inquilino não híbrido do Exchange Online não consegue ver a disponibilidade de um utilizador chanok@contoso.com na cloud num inquilino híbrido. O utilizador chanok@contoso.com da cloud tem um endereço chanok@contoso.mail.onmicrosoft.comde e-mail proxy . O inquilino não hierárquico tem duas relações organizacionais: contoso.com (no local) e contoso.mail.onmicrosoft.com (cloud). Deteção Automática para contoso.com pontos para o Exchange Server e Deteção Automática para contoso.mail.onmicrosoft.com pontos para o Exchange Online. O utilizador no inquilino não hierárquico recebe a mensagem de erro ao consultar as informações de disponibilidade para chanok@contoso.com, porque a Deteção Automática de contoso.com pontos não aponta para o Exchange Online.

Nota

Para o cenário de malha híbrida no local equivalente, veja Malha híbrida.

Solução

Para resolver este problema, a sua organização pode utilizar um dos seguintes métodos:

• Os utilizadores no inquilino do Exchange Online não híbrido devem consultar a disponibilidade de um utilizador na nuvem num inquilino híbrido através do endereço de e-mail para o qual a Deteção Automática aponta para o Exchange Online. Por exemplo, lucine@adatum.com consulta informações de disponibilidade para chanok@contoso.mail.onmicrosoft.com. Para consultar com êxito informações de disponibilidade, os utilizadores no inquilino do Exchange Online não híbrido têm de saber que utilizadores no inquilino híbrido estão alojados na nuvem e, para cada um desses utilizadores, o endereço de e-mail para o qual a Deteção Automática aponta para o Exchange Online.

• Um administrador do inquilino do Exchange Online não hierárquico deve definir o endereço de e-mail externo de cada utilizador na cloud no inquilino híbrido para o endereço de e-mail para o qual a Deteção Automática aponta para o Exchange Online. Por exemplo, um administrador no inquilino do Exchange Online não hibrid define o endereço de e-mail de destino de chanok@contoso.com no inquilino híbrido como chanok@contoso.mail.onmicrosoft.com. Para efetuar esta alteração, o administrador tem de saber que utilizadores no inquilino híbrido estão alojados na nuvem e, para cada um desses utilizadores, o endereço de e-mail para o qual a Deteção Automática aponta para o Exchange Online. Para obter mais informações sobre a sincronização entre inquilinos de endereços de e-mail de utilizador, veja O que é a sincronização entre inquilinos.

Mais informações

Um utilizador pode encontrar um problema semelhante no seguinte cenário:

• O utilizador está num inquilino do Exchange Server não hierárquico.
• O utilizador tenta ver a disponibilidade de um utilizador no local num inquilino híbrido.
• A Deteção Automática do inquilino híbrido aponta para o Exchange Online.

Por exemplo, um utilizador num inquilino do Exchange Server não hierárquico não consegue ver as informações de disponibilidade do utilizador chanok@contoso.com no local num inquilino híbrido porque a Deteção Automática de pontos para contoso.com o Exchange Online (autodiscover-s.outlook.com).

Voltar ao início

O pedido falhou com o estado HTTP 401: Não autorizado (certificado de assinatura em falta)

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

System.Net.WebException: o pedido falhou com o estado HTTP 401: Não autorizado.

Se executar o cmdlet Test-OAuthConnectivity , verá a seguinte mensagem de erro na saída do comando:

Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException: certificado de assinatura em falta.

Por exemplo, execute o seguinte comando:

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

O TargetUri valor do parâmetro é o URL do serviço de Deteção Automática no local. Um exemplo desse URL é https://mail.contoso.com/Autodiscover/Autodiscover.svc.

Este erro pode ocorrer se a configuração de autenticação tiver um certificado OAuth inválido.

Resolução

Para corrigir o problema, siga estes passos:

1. Execute o seguinte cmdlet do PowerShell na Shell de Gestão do Exchange (EMS) para obter o thumbprint do certificado OAuth utilizado pela configuração de autenticação:

   Get-AuthConfig | FL CurrentCertificateThumbprint
   

   Se a saída do comando não devolver um thumbprint do certificado, avance para o passo 3. Caso contrário, avance para o passo seguinte.

2. Execute o seguinte cmdlet do PowerShell para verificar se o certificado identificado no passo 1 existe no Exchange Server:

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

   Se o Exchange Server não devolver nenhum certificado, avance para o passo 3 para criar um novo certificado.

   Se o Exchange Server devolver um certificado, mas o thumbprint for diferente do thumbprint que obteve no passo 1, avance para o passo 4. No passo 4, especifique o thumbprint do certificado devolvido pelo Exchange Server.

3. Execute o seguinte cmdlet do PowerShell para criar um novo certificado 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 lhe for pedido para substituir o certificado SMTP, não aceite o pedido.

   No passo 4, especifique o thumbprint do novo certificado que criou neste passo.

4. Execute os seguintes cmdlets do PowerShell para atualizar a configuração de autenticação para utilizar o certificado especificado:

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

   Nota

   Se for avisado de que a data efetiva é inferior a 48 horas, opte por continuar.

5. Execute o seguinte cmdlet do PowerShell para remover quaisquer referências ao certificado anterior:

   Set-AuthConfig -ClearPreviousCertificate
   

Voltar ao início

Falta uma conta associada da aplicação para funções RBAC ou a conta associada não tem atribuições de funções RBAC ou a conta de utilizadores de chamadas está desativada

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

System.Web.Services.Protocols.SoapException: falta uma conta associada para funções RBAC na aplicação ou a conta associada não tem atribuições de funções RBAC ou a conta de utilizadores de chamadas está desativada.

Passos de resolução do problema

Para resolver os problemas mencionados na mensagem de erro, utilize os seguintes passos. Depois de concluir os passos 1 e 2, verifique se o problema de disponibilidade foi corrigido.

1. Certifique-se de que a entrada "Exchange Online-ApplicationAccount" existe na lista de aplicações parceiras do Exchange Server. Para verificar, execute o seguinte cmdlet do PowerShell na Consola de Gestão do Exchange (EMS):

   Get-PartnerApplication | FL LinkedAccount
   

   A entrada da conta deve aparecer como <root domain FQDN>/Users/Exchange Online-ApplicationAccount. Se a entrada estiver listada, avance para o passo 2.

   Se a entrada da conta não estiver listada, adicione a conta ao seguir estes passos:

   1. Execute os seguintes cmdlets do PowerShell para localizar a conta no Active Directory no local:

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

      Se a conta estiver listada no Active Directory, avance para o passo 1b.

      Se a conta não estiver listada no Active Directory, poderá ter sido eliminada. Utilize o ADRestore para verificar o estado da conta e restaurá-lo, caso seja eliminado. Se tiver restaurado a conta com o ADRestore, avance para o passo 1b.

      Se não conseguir restaurar a conta com o ADRestore, siga o procedimento abordado no Active Directory e domínios do Exchange Server. Se esse procedimento não restaurar a conta, crie manualmente a conta no Active Directory e, em seguida, continue para o passo 1b.

   2. Execute o seguinte cmdlet do PowerShell para adicionar a conta do Active Directory à lista de aplicações parceiras do Exchange Server:

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

   3. Reinicie todos os servidores exchange no local ou reinicie o IIS ao executar o comando numa janela do iisreset /noforce PowerShell ou da Linha de Comandos em cada servidor.

2. Execute o seguinte cmdlet do PowerShell no EMS para verificar as atribuições de controlo de acesso baseado em funções (RBAC):

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

   Por exemplo, a saída do comando pode listar as seguintes atribuições de funções:

   

3. Procure nos seguintes registos os problemas indicados na mensagem de erro:

   • Registos do Exchange Web Services (EWS) localizados na pasta %ExchangeInstallPath%\Logging\Ews
   • Registos de eventos da aplicação
   • Registos de eventos do sistema

4. Procure nos registos listados no passo 3 uma mensagem de erro que referencia AuthzInitializeContextFromSid. Se encontrar essa mensagem de erro, veja os seguintes recursos:

   • Algumas aplicações e APIs requerem acesso a informações de autorização em objetos de conta

   • As verificações de acesso falham devido a AuthZ

Voltar ao início

As palavras-passe introduzidas e armazenadas não correspondem

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

Foi recebida uma exceção de falha soap. As palavras-passe introduzidas e armazenadas não correspondem.

Verá a mesma mensagem de erro ao executar o seguinte cmdlet para verificar se o utilizador da cloud pode obter um token de delegação para a caixa de correio de utilizador no local:

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

Causa

Existe uma inconsistência nas credenciais do Azure para utilizadores específicos da cloud.

Resolução

Para corrigir o problema, siga estes passos:

1. Reponha a palavra-passe do utilizador da cloud. Escolha a mesma palavra-passe ou uma palavra-passe diferente.

2. Atualize o nome principal de utilizador (UPN) do utilizador da cloud para utilizar o onmicrosoft.com domínio e, em seguida, reverta o UPN para o respetivo valor anterior. Por exemplo, se o UPN do utilizador da cloud for user@contoso.com, altere-o para o UPN temporário e, em seguida, user@contoso.mail.onmicrosoft.comreverta o UPN para user@contoso.com. Para tal, utilize o Azure AD PowerShell ou o serviço MSOL.

   • Utilizar o Azure AD PowerShell

     Execute os seguintes cmdlets do PowerShell:

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

   • Utilizar o serviço MSOL

     Execute os seguintes cmdlets do PowerShell:

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

3. Confirme que o ImmutableId valor do objeto de utilizador no local é nulo. Verifique o valor do ImmutableId objeto de utilizador no local ao executar o seguinte comando na Shell de Gestão do Exchange (EMS):

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

   Utilize um dos seguintes métodos, consoante o ImmutableId valor.

   • O valor ImmutableId é nulo

     Se o ImmutableId valor for nulo, alterne o respetivo valor:

     1. Defina o ImmutableId objeto da caixa de correio remota para o UPN do utilizador da nuvem ao executar o seguinte cmdlet do PowerShell no EMS:

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

        Por exemplo: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

     2. Sincronize a alteração à cloud ao executar os seguintes cmdlets do PowerShell no EMS:

        Import-Module ADSync
        Start-ADSyncSyncCycle -PolicyType Delta
        

        Para verificar se o ImmutableId valor foi atualizado, execute o seguinte cmdlet do PowerShell no PowerShell do Exchange Online:

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

     3. Reverta o ImmutableId objeto da caixa de correio remota para nulo ao executar o seguinte cmdlet do PowerShell no EMS:

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

     4. Sincronize a alteração à cloud ao executar o seguinte cmdlet do PowerShell no EMS:

        Start-ADSyncSyncCycle -PolicyType Delta
        

        Para verificar se o ImmutableId valor foi atualizado, execute o seguinte cmdlet do PowerShell no PowerShell do Exchange Online:

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

   • O valor ImmutableId não é nulo

     Se o ImmutableId valor não for nulo, execute o seguinte comando no EMS para definir o ImmutableId valor como nulo:

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

     Pode verificar se o ImmutableId valor foi atualizado ao executar o seguinte cmdlet do PowerShell no PowerShell do Exchange Online:

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

Voltar ao início

A palavra-passe tem de ser alterada ou a palavra-passe da conta expirou

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontra uma das seguintes mensagens de erro.

Mensagem de erro 1

A palavra-passe da conta expirou

Mensagem de erro 2

A palavra-passe tem de ser alterada

Verá a mesma mensagem de erro ao executar o seguinte cmdlet para verificar se o utilizador da cloud pode obter um token de delegação para a caixa de correio de utilizador no local:

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

Este erro poderá ocorrer se existir uma inconsistência nas credenciais do Azure para utilizadores específicos da cloud.

Resolução

Selecione a resolução que corresponde à mensagem de erro.

Resolução para a mensagem de erro 1

Para corrigir o problema, utilize o Azure AD PowerShell ou o serviço MSOL.

• Utilizar o Azure AD PowerShell

  Execute os seguintes cmdlets do PowerShell:

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

• Utilizar o serviço MSOL

  Execute os seguintes cmdlets do PowerShell:

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

Resolução para a mensagem de erro 2

Para corrigir o problema, execute os seguintes cmdlets do PowerShell:

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

Para obter mais informações, consulte Não é possível ver informações de disponibilidade após a migração do Exchange no local.

Voltar ao início

É necessário aprovisionar antes de a conta federada poder iniciar sessão

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

É necessário aprovisionar antes de a conta federada poder iniciar sessão. ErrorWin32InteropError

Também recebe a mesma mensagem de erro quando executa o seguinte cmdlet para verificar se o utilizador da cloud pode obter um token de delegação para a caixa de correio de utilizador no local:

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

Este erro pode ocorrer se existir uma inconsistência na configuração de utilizadores federados no ID do Microsoft Entra.

Resolução

Nota

Se o problema afetar a maioria ou todos os utilizadores da cloud na sua organização, contacte o Suporte da Microsoft.

Para corrigir o problema, atualize o nome principal de utilizador (UPN) do utilizador da cloud para utilizar o domínio e, em seguida, mude-o novamente para o onmicrosoft.com respetivo valor anterior (domínio federado). Por exemplo, se o UPN do utilizador da cloud for user@contoso.com, mude-o para o UPN user@contoso.mail.onmicrosoft.com temporário e, em seguida, volte a user@contoso.com. Para tal, utilize uma das seguintes abordagens (Azure AD PowerShell ou serviço MSOL):

• Utilizar o Azure AD PowerShell

  Execute os seguintes cmdlets do PowerShell:

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

• Utilizar o serviço MSOL

  Execute os seguintes cmdlets do PowerShell:

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

Voltar ao início

O pedido excedeu o limite de tempo

TAMPA: 43404

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

O pedido excedeu o limite de tempo
Não foi possível processar o pedido a tempo. O tempo limite ocorreu durante "Waiting-For-Request-Completion".
Microsoft.Exchange.InfoWorker.Common.Availability.TimeoutExpiredException: não foi possível processar o pedido a tempo. O tempo limite ocorreu durante "Waiting-For-Request-Completion".
Nome do servidor onde a exceção teve origem: <nome> do servidor.

Também receberá a mesma mensagem de erro se executar o seguinte cmdlet para verificar se o utilizador da cloud pode obter um token de delegação para a caixa de correio de utilizador no local:

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

Este erro pode ocorrer se existirem problemas de rede ou transitórios. A mensagem de erro é genérica.

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Para excluir problemas transitórios, verifique se o utilizador da cloud recebe consistentemente a mesma mensagem de erro durante as tentativas repetidas de obter as informações de disponibilidade do utilizador no local.

2. Verifique se pode obter um token de delegação quando executar cada um dos seguintes cmdlets:

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

   Nota: execute o cmdlet Test-FederationTrust em todos os servidores exchange no local.

3. Verifique se o Exchange Server tem acesso de saída à Internet para ambos os recursos seguintes:

   • O Gateway de Federação da Microsoft (ou um servidor de autorização, se utilizar o OAuth)

   • O URL de disponibilidade do Microsoft 365: https://outlook.office365.com/ews/exchange.asmx

   Para obter mais informações, veja Intervalos de URLs e endereços IP do Microsoft 365 eConsiderações de Firewall para Delegação Federada.

4. Certifique-se de que a conta de sistema no Exchange Server tem acesso à Internet aos seguintes URLs. Siga estes passos em cada servidor Exchange:

   1. Execute o seguinte comando PsExec para iniciar uma sessão do PowerShell que inicia um browser a partir da conta do sistema:

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

   2. Teste o acesso ao browser (sem OAuth) da conta de sistema para os seguintes URLs do Gateway de Federação da Microsoft:

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

        O browser deve apresentar uma página xml.

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

        O browser deverá pedir-lhe para transferir o ficheiro.

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

        O browser deve apresentar uma lista de operações suportadas pela ManageDelegation2.

   3. Teste o acesso ao browser (OAuth) a partir da conta de sistema para os seguintes URLs do servidor de autorização da Microsoft:

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

        O browser deverá apresentar um pedido de início de sessão.

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

        O browser deverá apresentar o erro de início de sessão " Lamentamos, mas estamos com problemas em iniciar sessão".

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

        O browser deve apresentar o código 400 Bad Requestde estado HTTP ou a mensagem de erro de início de sessão: "Pedimos desculpa, mas estamos com problemas em iniciar sessão".

5. Obtenha os detalhes de um pedido de disponibilidade ao verificar os registos dos Serviços Web Exchange (EWS):

   1. Faça um pedido de disponibilidade a partir do Exchange Online.

   2. Localize a entrada nos registos do EWS e verifique o valor na time-taken coluna. Os registos EWS estão localizados na pasta %ExchangeInstallPath%\Logging\Ews .

   3. Verifique os registos do IIS na pasta W3SVC1 do site predefinido para verificar se o pedido de disponibilidade está registado. O caminho da pasta W3SVC1 é %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

Voltar ao início

O nome de membro especificado é inválido ou está vazio

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

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>O nome de membro especificado é inválido ou está vazio. </psf:text></psf:internalerror></psf:error></S:Detail></S:Fault> Microsoft.Exchange.Net.WSTrust.SoapFaultException: Exceção de falha soap recebida. em Microsoft.Exchange.Net.WSTrust.SecurityTokenService.EndIssueToken(IAsyncResult asyncResult) em Microsoft.Exchange.InfoWorker.Common.Availability.ExternalAuthenticationRequest.Complete(IAsyncResult asyncResult)

O erro pode ocorrer por um dos seguintes motivos:

• Uma inconsistência no ID do Microsoft Entra para os utilizadores que pedem um token de delegação
• Uma inconsistência na configuração de utilizadores federados nos Serviços de Federação do Active Directory (AD FS)

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Atualize o nome principal de utilizador (UPN) do utilizador da cloud para utilizar o onmicrosoft.com domínio e, em seguida, reverta o UPN para o respetivo valor anterior. Por exemplo, se o UPN do utilizador da cloud for user@contoso.com, altere-o para o UPN temporário e, em seguida, user@contoso.mail.onmicrosoft.comreverta o UPN para user@contoso.com. Para tal, utilize um dos seguintes métodos (Azure AD PowerShell ou serviço MSOL):

   • Utilizar o Azure AD PowerShell

     Execute os seguintes cmdlets do PowerShell:

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

   • Utilizar o serviço MSOL

     Execute os seguintes cmdlets do PowerShell:

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

2. Verifique as regras, pontos finais e registos do AD FS.

3. Procure um erro relacionado com o ImmutableID do utilizador da cloud na saída do comando do seguinte cmdlet do PowerShell:

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

   Por exemplo, a saída do comando pode conter a seguinte mensagem de erro:

   "O endereço de e-mail "XGuNpVunD0afQeVNfyoUIQ==" não está correto. Utilize este formato: nome de utilizador, o sinal @, seguido do nome de domínio. Por exemplo, tonysmith@contoso.com ou tony.smith@contoso.com.
   + CategoryInfo: NotSpecified: (:) [Test-OrganizationRelationship], FormatException"

   Se receber uma mensagem de erro semelhante, utilize um dos seguintes métodos para se certificar de que o ImmutableId valor é nulo (valor vazio):

   • Se o utilizador da cloud não estiver sincronizado no local, verifique o ImmutableId valor ao executar o seguinte cmdlet do PowerShell no PowerShell do Exchange Online:

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

     Se o ImmutableId valor não for nulo, execute o seguinte cmdlet do PowerShell no PowerShell do Exchange Online:

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

   • Se o utilizador da cloud for sincronizado a partir do local, verifique o valor do ImmutableId objeto de utilizador no local ao executar o seguinte comando na Shell de Gestão do Exchange (EMS):

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

     Utilize um dos seguintes métodos, consoante o ImmutableId valor:

     • O valor ImmutableId é nulo

       Se o ImmutableId valor for nulo, alterne o respetivo valor:

       1. Defina o ImmutableId objeto da caixa de correio remota para o UPN do utilizador da nuvem ao executar o seguinte cmdlet do PowerShell no EMS:

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

          Por exemplo: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

       2. Sincronize a alteração à cloud ao executar os seguintes cmdlets do PowerShell no EMS:

          Import-Module ADSync
          Start-ADSyncSyncCycle -PolicyType Delta
          

          Para verificar se o ImmutableId valor foi atualizado, execute o seguinte cmdlet do PowerShell no PowerShell do Exchange Online:

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

       3. Reverta o ImmutableId objeto da caixa de correio remota para nulo ao executar o seguinte cmdlet do PowerShell no EMS:

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

       4. Sincronize a alteração à cloud ao executar o seguinte cmdlet do PowerShell no EMS:

          Start-ADSyncSyncCycle -PolicyType Delta
          

          Verifique se o ImmutableId valor foi atualizado. Para tal, execute o seguinte cmdlet do PowerShell no PowerShell do Exchange Online:

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

     • O valor ImmutableId não é nulo

       Se o ImmutableId valor não for nulo, execute o seguinte comando no EMS para definir o ImmutableId valor como nulo:

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

       Para verificar se o ImmutableId valor foi atualizado, execute o seguinte cmdlet do PowerShell no PowerShell do Exchange Online:

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

4. Verifique as definições de relação da organização. Para obter mais informações, veja Desmistificar a Disponibilidade Híbrida.

5. Se a mensagem de erro for gerada para um utilizador da cloud que não consegue ver as informações de disponibilidade de um utilizador no local, siga estes passos:

   1. Execute o seguinte cmdlet no PowerShell:

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

   2. Recrie a confiança de federação. Para obter mais informações, veja Remover uma confiança de federação e Configurar uma confiança de federação.

Voltar ao início

O conjunto de resultados contém demasiadas entradas de calendário

TAMPA: 54796

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de outro utilizador da cloud. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

Exceção: o conjunto de resultados contém demasiadas entradas de calendário. O tamanho permitido = 1000; o tamanho real = 5009.

Este erro ocorre se o número de entradas de calendário num único horário exceder 1000 itens. Um único pedido de disponibilidade não consegue obter mais de 1000 itens.

Resolução

Remova alguns dos itens de calendário do horário para não exceder o limite de 1000 itens que podem ser obtidos num único pedido de disponibilidade.

Para obter mais informações, consulte Não pode ver informações de disponibilidade no Calendário de outro utilizador no Exchange Online.

Voltar ao início

A hora de início das horas de trabalho tem de ser menor ou igual à hora de fim

Problema

Tem um utilizador na nuvem que não consegue ver as informações de disponibilidade de uma lista de salas. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

Exceção: Microsoft.Exchange.InfoWorker.Common.InvalidParameterException: a hora de início das horas de trabalho tem de ser menor ou igual à hora de fim.
Microsoft.Exchange.InfoWorker.Common.MeetingSuggestions.AttendeeWorkHours.Validate(TimeSpan startTime, TimeSpan endTime).

Este erro poderá ocorrer se uma ou mais das seguintes definições de calendário para uma caixa de correio de sala numa lista de salas forem inválidas:

• WorkingHoursStartTime
• WorkingHoursEndTime
• WorkingHoursTimeZone

A hora de início das horas de trabalho tem de ser menor ou igual à hora de fim das horas de trabalho e o fuso horário das horas de trabalho tem de ser definido.

Resolução

Para corrigir o problema, siga estes passos:

1. Execute o seguinte cmdlet do PowerShell para verificar as definições de calendário de cada caixa de correio na lista de salas para identificar a caixa de correio da sala que tem definições inválidas:

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

2. Execute o seguinte cmdlet do PowerShell para definir os valores de parâmetros necessários para uma caixa de correio de sala:

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

   Para obter mais informações, consulte Set-MailboxCalendarConfiguration.

Voltar ao início

O pedido falhou com o estado HTTP 401: Não autorizado (o token tem uma assinatura inválida)

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

System.Net.WebException: o pedido falhou com o estado HTTP 401: Não autorizado.

Quando executa o seguinte cmdlet do PowerShell para testar a autenticação OAuth:

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

Recebe o seguinte resultado do comando:

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: o TargetUri valor do parâmetro no comando Test-OAuthConnectivity é um URL externo dos Serviços Web exchange (EWS), como https://mail.contoso.com/ews/exchange.asmx.

Este erro poderá ocorrer se as definições do servidor de autorização da Microsoft forem inválidas.

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Atualize os metadados de autorização no servidor de autorização da Microsoft especificado que é considerado fidedigno pelo Exchange. Execute o seguinte cmdlet do PowerShell no EMS (no local):

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

   Aguarde cerca de 15 minutos para que o comando entre totalmente em vigor ou reinicie o IIS ao executar o iisreset /noforce comando numa janela do PowerShell ou da Linha de Comandos em cada Exchange Server.

2. Verifique as definições do servidor de autorização da Microsoft na sua organização do Exchange ao executar o seguinte cmdlet do PowerShell no EMS:

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

   O seguinte resultado do comando é um exemplo de definições válidas:

   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 as definições do servidor de autorização da Microsoft não forem válidas, tente executar novamente o Assistente de Configuração Híbrida para repor as definições do servidor de autorização da Microsoft para valores válidos.

Voltar ao início

O pedido falhou com o estado HTTP 401: Não autorizado (a chave não foi encontrada)

Problema

Tem um utilizador no local que não consegue ver as informações de disponibilidade de um utilizador na cloud. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

System.Net.WebException: o pedido falhou com o estado HTTP 401: Não autorizado.

Quando executa o seguinte cmdlet do PowerShell no EMS para testar a autenticação OAuth:

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

Recebe o seguinte resultado do comando:

System.Net.WebException: o servidor remoto devolveu um erro: (401) Não autorizado.
Erro: Não é possível obter o token do Servidor de Autenticação. Código de erro: "invalid_client". Descrição: 'AADSTS70002:
Erro ao validar as credenciais. AADSTS50012: a asserção de cliente contém uma assinatura inválida. [Reason - The key was not found., Thumbprint of key used by client: '<thumbprint>'.

Este erro pode ocorrer se o certificado OAuth no Exchange Server não existir no Exchange Online.

Resolução

Para corrigir o problema, utilize os seguintes passos:

1. Determine se o certificado OAuth do Exchange Server no local existe na sua organização do Exchange Online:

   1. Execute o seguinte cmdlet do PowerShell na Shell de Gestão do Exchange (EMS) para obter o certificado OAuth no Exchange Server:

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

      A saída do comando contém o Thumbprint valor.

   2. Execute os seguintes cmdlets do PowerShell para obter o certificado OAuth do Exchange Online com o serviço MSOL:

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

      Se o valor do Value parâmetro na saída do comando estiver vazio, não existe um certificado OAuth no Exchange Online. Nesse caso, avance para o passo 3 para carregar o certificado no local para o Exchange Online.

      Se o valor do Value parâmetro não estiver vazio, guarde o valor num ficheiro que tenha uma extensão ".cer". Abra o ficheiro na ferramenta Microsoft Certificate Manager para ver o certificado OAuth do Exchange Online. Compare o Thumbprint valor no certificado do Exchange Online com o thumbprint do certificado no local que obteve no passo 1a. Se os valores do thumbprint corresponderem, avance para o passo 4. Se os valores do thumbprint não corresponderem, escolha uma das seguintes opções:

      • Vá para o passo 2 para substituir o certificado no local existente pelo certificado do Exchange Online.

      • Vá para o passo 3 para substituir o certificado do Exchange Online existente pelo certificado no local.

2. Substitua o certificado no local existente pelo certificado do Exchange Online:

   1. Execute o seguinte cmdlet do PowerShell para atualizar o thumbprint do certificado no local:

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

      Se for notificado de que a data efetiva do certificado é inferior a 48 horas a partir de agora, aceite o pedido para continuar.

   2. Execute o seguinte cmdlet do PowerShell para publicar o certificado no local:

      Set-AuthConfig -PublishCertificate  
      

   3. Execute o seguinte cmdlet do PowerShell para remover quaisquer referências ao certificado anterior:

      Set-AuthConfig -ClearPreviousCertificate 
      

   4. Vá para o passo 4.

3. Exporte o certificado de autorização no local e, em seguida, carregue o certificado para a sua organização do Exchange Online.

4. Execute o seguinte cmdlet do PowerShell para verificar se o SPN na configuração de autenticação no local é 00000002-0000-0ff1-ce00-000000000000:

   Get-AuthConfig | FL ServiceName
   

   Se o valor SPN for diferente, atualize o SPN ao executar o seguinte cmdlet do PowerShell:

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

Voltar ao início

O pedido Web do proxy falhou: A resposta não está bem formada para XML

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

O pedido Web do proxy falhou., exceção interna: A resposta não é um XML bem formado

Se executar o teste de Sincronização, Notificação, Disponibilidade e Respostas Automáticas para o utilizador no local, receberá a seguinte mensagem de erro:

A resposta recebida do serviço não continha XML válido

Estes erros podem ocorrer por qualquer um dos seguintes motivos:

• Problema dos Serviços Web exchange externos (EWS)
• Configuração incorreta de dispositivos de rede, como um proxy inverso ou uma firewall

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Verifique se um pedido de disponibilidade do Exchange Online pode aceder ao IIS num servidor Exchange. Execute uma consulta de disponibilidade e, em seguida, pesquise nos registos do IIS entradas que tenham o código 200 OK de estado HTTP ou 401 Unauthorized no momento da consulta. Essas entradas indicam que o pedido de disponibilidade atingiu o IIS. Nota: os carimbos de data/hora nos registos do IIS utilizam a hora UTC.

   Se não encontrar essas entradas, verifique os registos do proxy inverso e da firewall para determinar onde o pedido de disponibilidade ficou bloqueado.

2. Execute uma consulta de disponibilidade e, em seguida, procure entradas no Visualizador de Eventos do Windows no Registo de Eventos do Exchange Server no momento da consulta para ajudar a restringir a causa do problema.

Voltar ao início

Não é possível ligar ao servidor remoto

Problema

Tem um utilizador no local que não consegue ver as informações de disponibilidade de um utilizador na cloud. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

Falha ao comunicar com https://login.microsoftonline.com/extSTS.srf., exceção interna: não é possível ligar ao servidor remoto.

Este erro poderá ocorrer se um ou mais servidores do Exchange não conseguirem ligar a um URL do Gateway de Federação da Microsoft.

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Execute os seguintes cmdlets do PowerShell na Shell de Gestão do Exchange (EMS) para verificar se pode obter um token de delegação:

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

2. Verifique se os servidores exchange no local têm acesso de saída à Internet a ambos os recursos seguintes:

   • O Gateway de Federação da Microsoft ou o servidor de autorização da Microsoft se utilizar a autenticação OAuth.

   • O URL de disponibilidade do Microsoft 365: https://outlook.office365.com/ews/exchange.asmx.

   Para obter mais informações, veja Intervalos de URLs e endereços IP do Microsoft 365 e Considerações de firewall para delegação federada.

3. Verifique se a conta do Sistema no Exchange Server tem acesso à Internet aos seguintes URLs. Siga estes passos em todos os Servidores Exchange na sua organização:

   1. Execute o seguinte comando PsExec para iniciar uma sessão do PowerShell que inicia um browser a partir da conta do Sistema:

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

   2. Teste o acesso ao browser (sem autenticação OAuth) da conta do Sistema para os seguintes URLs do Gateway de Federação da Microsoft:

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

        O browser deve apresentar uma página xml.

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

        O browser deverá pedir-lhe para transferir o ficheiro.

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

        O browser deve apresentar uma lista de operações suportadas pela ManageDelegation2.

   3. Teste o acesso ao browser (autenticação OAuth) da conta do Sistema para os seguintes URLs do servidor de autorização da Microsoft:

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

        O browser deverá apresentar um pedido de início de sessão.

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

        O browser deve apresentar a mensagem de erro de início de sessão: "Pedimos desculpa, mas estamos a ter problemas para iniciar sessão.".

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

        O browser deve apresentar o código 400 Bad Request de estado HTTP ou a mensagem de erro de início de sessão: "Pedimos desculpa, mas estamos a ter problemas para iniciar sessão."

Voltar ao início

Falha na deteção automática do endereço de e-mail: não foi possível resolver o nome remoto

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

Falha na Deteção Automática do endereço> de e-mail do endereço <de e-mail do utilizador com o erro System.Net.WebException: Não foi possível resolver o nome remoto: "<nome> do anfitrião no local".

Este erro poderá ocorrer se o URL do ponto final da Deteção Automática no local ou as definições de DNS público estiverem incorretas.

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Execute os seguintes cmdlets do PowerShell no PowerShell do Exchange Online para obter o valor do TargetAutodiscoverEpr parâmetro:

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

   Por exemplo, se o valor do nome do anfitrião no local na mensagem de erro for , é mail.contoso.comprovável que o URL do ponto final da Deteção Automática seja https://autodiscover.contoso.com/autodiscover/autodiscover.svc.

   Se o valor do TargetAutodiscoverEpr parâmetro estiver correto, avance para o passo 3. Caso contrário, avance para o passo 2.

2. Atualize o URL do ponto final da Deteção Automática com um dos seguintes métodos:

   • Execute o Assistente de Configuração Híbrida (HCW) para restaurar o ponto final de Deteção Automática predefinido.

   • Atualize manualmente o DiscoveryEndpoint parâmetro ou o TargetAutodiscoverEpr parâmetro ao executar um dos seguintes cmdlets do PowerShell:

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

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

3. Confirme que o nome do anfitrião no local na mensagem de erro (por exemplo: mail.contoso.com) é resolvível no DNS público. A entrada DNS para o nome do anfitrião deve apontar para o serviço de Deteção Automática no local no URL do ponto final da Deteção Automática.

   Nota: se não conseguir corrigir o problema e quiser uma solução temporária, execute um dos seguintes cmdlets do PowerShell para atualizar manualmente o valor do TargetSharingEpr parâmetro para o URL externo dos Serviços Web exchange (EWS). O URL do EWS externo deve assemelhar-se https://<EWS hostname>/ews/exchange.asmx e ser resolvível no DNS.

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

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

   Nota

   Se definir o valor do TargetSharingEpr parâmetro, a caixa de correio na nuvem ignora a Deteção Automática e liga-se diretamente ao ponto final do EWS.

Voltar ao início

Falha ao obter o ASURL. Erro 8004010F

Problema

Tem um utilizador no local que não consegue ver as informações de disponibilidade de um utilizador na cloud. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

Falha ao obter o ASURL. Erro 8004010F.

Este é um erro geral relacionado com o serviço de Deteção Automática.

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Certifique-se de que a Deteção Automática para o utilizador afetado devolve o URL dos Serviços Web exchange (EWS) para o utilizador.

2. Execute o teste de configuração automática de e-mail no cliente do Outlook do utilizador afetado para se certificar de que a Deteção Automática devolve o URL do EWS para o utilizador.

3. Certifique-se de que a disponibilidade funciona entre utilizadores no local alojados em diferentes servidores do Exchange.

4. Se tiver balanceadores de carga, verifique se os balanceadores de carga causaram o problema. Para tal, modifique o ficheiro Anfitriões do Windows (no computador que tem o cliente outlook do utilizador instalado) para ignorar os balanceadores de carga e apontar para um servidor de Acesso de Cliente específico.

5. Se a disponibilidade funcionar entre utilizadores no local, verifique se todos os servidores exchange no local têm acesso de saída aos URLs do Microsoft 365 e aos intervalos de endereços IP.

6. Verifique se cada servidor Exchange pode obter um token de delegação. Para tal, execute o seguinte cmdlet do PowerShell no EMS em todos os servidores exchange no local:

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

   Se o comando não conseguir obter um token de delegação, verifique se o servidor consegue ligar ao Office 365 ao nível do proxy ou da firewall.

Voltar ao início

O pedido Web do proxy falhou: objeto movido

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

O pedido Web do proxy falhou. , exceção interna: System.Net.WebException: O pedido falhou com a mensagem de erro: Objeto movido.

Este erro poderá ocorrer se o valor do TargetSharingEpr parâmetro nas definições da organização estiver definido como um URL de ponto final do Exchange Web Services (EWS) incorreto.

Pode executar os seguintes cmdlets do PowerShell para obter o valor do parâmetro a TargetSharingEpr partir das definições da organização (conector intra-organização ou relação organização):

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

Verifique se o valor do TargetSharingEpr parâmetro não é resolvido no DNS público.

Nota: o Assistente de Configuração Híbrida (HCW) não define um valor para o parâmetro, TargetSharingEpr a menos que selecione Utilizar Tecnologia Híbrida Moderna do Exchange para instalar um Agente Híbrido. Nesse cenário, o HCW define o TargetSharingEpr parâmetro para um valor de ponto final do URL do EWS externo semelhante https://<GUID>.resource.mailboxmigration.his.msappproxy.net/ews/exchange.asmxa . Também pode definir o valor do TargetSharingEpr parâmetro manualmente. Se o TargetSharingEpr valor estiver definido para um ponto final, o Outlook ignora a Deteção Automática e liga-se diretamente a esse ponto final.

Resolução

Para corrigir o problema, execute um dos seguintes comandos para atualizar manualmente o valor do TargetSharingEpr parâmetro para um URL EWS externo que seja resolvido no DNS:

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

Voltar ao início

O pedido foi abortado: não foi possível criar um canal seguro SSL/TLS

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local ou vice-versa. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

O pedido foi abortado: não foi possível criar um canal seguro SSL/TLS.

Causa 1: O utilizador da cloud não consegue ver as informações de disponibilidade de um utilizador no local

O problema poderá ocorrer se o TLS 1.2 estiver configurado incorretamente ou desativado num ponto final no local ao qual o Microsoft 365 se liga, como o Exchange Server ou uma firewall.

Causa 2: o utilizador no local não consegue ver as informações de disponibilidade de um utilizador na cloud

O problema também pode ocorrer por qualquer um dos seguintes motivos:

• O certificado do Microsoft 365 (outlook.office365.com) está em falta no arquivo de autoridades de certificação (AC) de raiz fidedigna.
• Existe um erro de correspondência do conjunto Cypher .
• Outros problemas de SSL/TLS.

Passos de resolução do problema

Utilize as seguintes ferramentas para diagnosticar problemas do TLS 1.2 no local:

• Execute o teste do servidor SSL no Microsoft Remote Connectivity Analyzer.
• Execute o script HealthChecker na Shell de Gestão do Exchange (EMS) em cada servidor Exchange.

Para obter informações sobre a configuração do TLS, veja Melhores práticas de configuração do TLS do Exchange Server e Preparar para o TLS 1.2.

Para obter informações sobre como verificar a existência de certificados no arquivo de AC de raiz fidedigna, veja Ver certificados com o snap-in MMC.

Para obter informações sobre os conjuntos de cifras TLS suportados, veja Conjuntos de cifras TLS suportados pelo Microsoft 365.

Voltar ao início

O utilizador especificado pelo contexto de utilizador no token não existe

Problema

Tem um utilizador no local que não consegue ver as informações de disponibilidade de um utilizador na cloud. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

O utilizador especificado pelo contexto de utilizador no token não existe. error_category="invalid_user". 401: Não autorizado.

Receberá a mesma mensagem de erro se executar o cmdlet Test-OAuthConnectivity do PowerShell.

O erro poderá ocorrer se a caixa de correio do utilizador no local e o objeto de utilizador de correio correspondente no Microsoft Entra ID não estiverem sincronizados. Até serem sincronizados, o objeto mail-user no ID do Microsoft Entra poderá não ser aprovisionado.

Resolução

Para corrigir o problema, utilize o Microsoft Entra Connect para sincronizar o utilizador no local e o objeto de utilizador de correio correspondente no Microsoft Entra ID.

Voltar ao início

O componente de nome de anfitrião do valor de afirmação de audiência é inválido

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

O componente de nome de anfitrião do valor de afirmação de audiência "https://< hybrid.domain.com>" é inválido; error_category="invalid_resource"

O erro pode ocorrer por qualquer um dos seguintes motivos.

Causa 1

A descarga de SSL e a autenticação OAuth estão ambas ativadas. A descarga de SSL não funciona se a autenticação OAuth estiver ativada.

Causa 2

Um dispositivo de rede à frente do Exchange Server está a bloquear pedidos de disponibilidade.

Solução

Solução para a Causa 1

Selecione uma das seguintes soluções:

• Desative a descarga de SSL para os Serviços Web exchange (EWS) e a Deteção Automática no ambiente no local. Para obter mais informações, veja Configuring SSL offloading for the Autodiscover and Configuring SSL offloading for EWS (Configurar a descarga de SSL para a Deteção Automática) e Configuring SSL offloading for EWS (Configurar a descarga de SSL para o EWS) e as predefinições de SSL.

• Execute o seguinte cmdlet do PowerShell para desativar a autenticação OAuth ao desativar o conector intra-organização da cloud:

  Set-IntraOrganizationConnector "HybridIOC*" -Enabled $false
  

  Quando o conector intra-organização está desativado, a autenticação DAuth é ativada através da relação da organização. Para verificar a relação da organização, execute o seguinte cmdlet do PowerShell:

  Get-OrganizationRelationship
  

  Para obter mais informações sobre as definições de relações da organização, veja Desmistificar a Disponibilidade Híbrida.

Resolução para a Causa 2

Configure o dispositivo de rede à frente do Exchange para não bloquear pedidos de disponibilidade.

Voltar ao início

O pedido Web do proxy falhou com o estado HTTP 503: Serviço indisponível

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

O pedido Web do proxy falhou, exceção interna: System.Net.WebException: O pedido falhou com o estado HTTP 503: Serviço Indisponível...

Este erro poderá ocorrer se existir um serviço Do Microsoft Windows parado, um componente de servidor, um conjunto aplicacional do IIS ou um ponto final configurado incorretamente.

Passos de resolução do problema

Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Certifique-se de que os serviços do Windows de que o Exchange Server necessita estão em execução. Para verificar o estado dos serviços, execute o seguinte cmdlet do PowerShell em cada servidor Exchange na sua organização:

   Test-ServiceHealth
   

   Utilize a consola dos Serviços para iniciar quaisquer serviços parados que sejam exigidos pelo Exchange Server.

2. Verifique se os componentes do Exchange Server necessários estão ativos. Para verificar o estado dos componentes, execute o seguinte cmdlet do PowerShell em cada servidor Exchange na sua organização:

   Get-ServerComponentState <server name>
   

   Para ativar um componente inativo, utilize o cmdlet Do PowerShell Set-ServerComponentState .

3. Certifique-se de que os seguintes conjuntos aplicacionais do IIS para Serviços Web exchange (EWS) e Deteção Automática foram iniciados:

   • MSExchangeServicesAppPool
   • MSExchangeSyncAppPool
   • MSExchangeAutodiscoverAppPool

4. Teste se o ponto final de Deteção Automática é válido. Siga estes passos:

   1. Execute os seguintes cmdlets do PowerShell para obter o URL do ponto final de Deteção Automática a partir dos valores de DiscoveryEndpoint parâmetro ou TargetAutodiscoverEpr :

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

   2. Navegue para o URL do ponto final da Deteção Automática num browser ou execute o cmdlet do Invoke-WebRequest -Uri "<endpoint URL>" -Verbose PowerShell para se certificar de que o URL é válido. De preferência, verifique o URL de uma rede externa.

5. Teste se o URL do EWS é válido ao seguir estes passos:

   1. Execute os seguintes cmdlets do PowerShell para obter o URL do EWS a TargetSharingEpr partir do valor do parâmetro nas definições da organização:

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

   b. Navegue para o URL do EWS num browser ou execute o cmdlet do Invoke-WebRequest -Uri "<endpoint URL>" -Verbose PowerShell para se certificar de que o URL é válido. De preferência, verifique o URL de uma rede externa.

6. Verifique se existem pedidos de disponibilidade nos registos do IIS que devolvem o código 503 Service Unavailablede estado HTTP:

   1. Faça um pedido de disponibilidade a partir do Exchange Online.

   2. Verifique se existem entradas de código 503 Service Unavailable de estado HTTP nos registos do IIS na pasta W3SVC1 para o site predefinido em cada servidor Exchange. O caminho da pasta W3SVC1 é %SystemDrive%\inetpub\logs\LogFiles\W3SVC1. Essas entradas podem ajudar a identificar o servidor que tem o problema.

   3. Se o pedido de disponibilidade não estiver registado na pasta W3SVC1 , verifique se o pedido é registado nos registos de erros na pasta HTTPERR em cada servidor Exchange. O caminho da pasta HTTPERR é %SystemRoot%\System32\LogFiles\HTTPERR. Se o pedido de disponibilidade estiver registado nos registos HTTPERR , verifique se existem definições do IIS configuradas incorretamente.

7. Verifique o cabeçalho da resposta do servidor que recebe quando se liga ao URL do EWS no local para verificar se o IIS (não um servidor Web diferente) enviou a resposta. Para tal, execute os seguintes comandos numa sessão do PowerShell que não esteja ligada ao EWS no local (não execute os comandos na Shell de Gestão do Exchange):

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

   Por exemplo, se vir "Microsoft-HTTPAPI/2.0" na saída do comando em vez de "Microsoft -IIS/10.0", é provável que um serviço do Proxy de Aplicações Web (WAP) (e não IIS) tenha respondido ao pedido. Verifique se o serviço WAP está inativo.

Voltar ao início

O pedido Web do proxy falhou com o estado HTTP 504: Tempo limite do gateway

TAMPA: 43532

Problema

Tem um utilizador na cloud que não consegue ver as informações de disponibilidade de um utilizador no local. Quando diagnosticar o problema, encontrará a seguinte mensagem de erro:

O pedido Web do proxy falhou, exceção interna: o pedido falhou com o estado HTTP 504: Tempo Limite do Gateway...

Este erro poderá ocorrer se um Agente Híbrido na sua organização estiver configurado incorretamente.

Resolução

Para corrigir o problema, utilize os seguintes passos. Depois de concluir cada passo, verifique se o problema de disponibilidade foi corrigido.

1. Verifique o valor do TargetSharingEpr parâmetro nas definições da organização. O valor deve assemelhar-se https://<GUID>.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmxa . Para determinar o valor do TargetSharingEpr parâmetro, execute os seguintes cmdlets do PowerShell:

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

   Se o valor do TargetSharingEpr parâmetro estiver incorreto:

   1. Execute o Assistente de Configuração Híbrida (HCW) e selecione Utilizar Topologia Híbrida Clássica do Exchange.

   2. Execute novamente o HCW e selecione Utilizar Topologia Híbrida Moderna do Exchange. Este procedimento força o HCW a repor o valor do TargetSharingEpr parâmetro.

2. Verifique o estado do Serviço Híbrido da Microsoft no servidor onde o Agente Híbrido está instalado. Se o serviço estiver parado, inicie-o.

3. Verifique o estado do Agente Híbrido. Se o estado for Inativo:

   1. Execute o Assistente de Configuração Híbrida (HCW) e selecione Utilizar Topologia Híbrida Clássica do Exchange.

   2. Execute novamente o HCW e selecione Utilizar Topologia Híbrida Moderna do Exchange. Este procedimento força o HCW a reinstalar o Agente Híbrido.

   3. Instale o módulo do PowerShell do Agente Híbrido e, em seguida, execute o cmdlet Do PowerShell Get-HybridApplication para localizar o URL interno para o qual o Agente Híbrido aponta.

4. Navegue para o URL interno que encontrou no passo 3. Resolva os erros que encontrar, como erros de certificado.

5. Configure o Agente Híbrido para direcionar pedidos para um balanceador de carga em vez de um servidor que esteja a executar o Microsoft Exchange Server para excluir problemas que possam existir nesse servidor.

6. Verifique se o Agente Híbrido suporta pedidos de disponibilidade e migração de caixas de correio.

Início da página