Dela via

Lösa problem med ledig/upptagen

  • Gäller för: Outlook for Microsoft 365, Outlook 2021, Outlook 2019, Outlook 2016, Outlook on the web, Outlook for Android, Outlook for iOS, Outlook for Mac

Om du vill felsöka ett fel som är relaterat till ledig/upptagen-information väljer du det tillämpliga felmeddelandet från innehållsförteckningen (TOC) överst i den här artikeln.

Om felsökningsstegen inte hjälper dig att lösa problemet kontaktar du Microsoft Support.

Ett fel uppstod när du verifierade säkerheten för meddelandet

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Automatisk upptäckt misslyckades för e-postadressen <smtp-adress> med felet System.Web.Services.Protocols.SoapHeaderException: Ett fel uppstod när du verifierade säkerheten för meddelandet på System.Web. Services.Protocols. SoapHttpClientProtocol. ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) på System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

Det här felet kan inträffa om WSSecurity-autentisering inte är aktiverat eller måste återställas, eller när du har förnyat federationscertifikat i Exchange Server.

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Om du vill uppdatera metadata i Microsoft Federation Gateway kör du följande kommando två gånger i det lokala Exchange Management Shell (EMS):

    Get-FederationTrust | Set-FederationTrust -RefreshMetadata

    Mer information finns i Ledig/upptagen-sökning slutar fungera i en lokal miljö eller i en Exchange Server-hybriddistribution.

  2. Följ dessa steg för att växla WSSecurity-autentisering:

    1. Följ proceduren i Användare från en federerad organisation kan inte se ledig/upptagen-information från en annan Exchange-organisation för att aktivera, eller återställa om den redan är aktiverad, WSSecurity-autentisering i både de virtuella katalogerna Autodiscover och EWS på alla lokala Exchange-servrar.

      Kommentarer

      • Utför det här steget även om utdata från PowerShell-cmdletarna Get-AutodiscoverVirtualDirectory och Get-WebServicesVirtualDirectory anger att WSSecurity-autentisering redan är aktiverat.

      • Proceduren påverkar endast ledig/upptagen för flera platser och påverkar inte andra klient-server-anslutningar.

    2. iisreset /noforce Kör kommandot i ett PowerShell- eller kommandotolkfönster på varje lokal Exchange-server för att starta om IIS.

    3. Starta om alla lokala Exchange-servrar.

  3. Sök efter och lös eventuella time-skew-varningar eller fel i systemhändelseloggen.

  4. TargetSharingEpr Ange parametervärdet i organisationsrelationen till den lokala externa URL:en för Exchange Web Services (EWS) genom att köra följande cmdlet i Exchange Online PowerShell:

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

    När du har angett TargetSharingEpr parametervärdet kringgår molnpostlådan Automatisk upptäckt och ansluter direkt till EWS-slutpunkten för den lokala postlådan.

    Obs! Standardvärdet för parametern TargetSharingEpr är tomt. Parametrarna TargetAutodiscoverEpr för automatisk upptäckt eller DiscoveryEndpoint innehåller vanligtvis den lokala externa EWS-URL:en (autodiscover-slutpunkt). Hämta parametervärdena TargetAutodiscoverEpr och DiscoveryEndpoint genom att köra följande PowerShell-cmdletar:

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

  5. Kontrollera att TargetApplicationUri parametervärdet i organisationsrelationen AccountNamespace matchar parametervärdet i den federerade organisationsidentifieraren. Du hittar TargetApplicationUri parametervärdet genom att köra PowerShell-cmdleten Test-OrganizationRelationship . Information om hur du hittar parametervärdet finns i AccountNamespaceAvmystifiera hybrid ledig/upptagen.

Tillbaka till början

Proxywebbbegäran misslyckades: Det går inte att ansluta till fjärrservern

Fråga

Du har molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare eller tvärtom. När du diagnostiserar problemet visas följande felmeddelande:

Proxywebbbegäran misslyckades. , inre undantag: System.Net.WebException: Det går inte att ansluta till fjärrservern; System.Net.Sockets.SocketException: Ett anslutningsförsök misslyckades eftersom den anslutna parten inte svarade korrekt efter en viss tidsperiod, eller så misslyckades anslutningen eftersom den anslutna värden inte svarade CUSTOMER_IP:443 /MICROSOFT_IP:443 på System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)

Det här felet kan inträffa om problem med nätverksanslutningen förhindrar inkommande eller utgående anslutningar mellan IP-adresser i Exchange Online och slutpunkter i Exchange Server.

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Kontrollera att brandväggen på varje lokal Exchange-server tillåter inkommande eller utgående anslutningar mellan Exchange Server-slutpunkter och Exchange Online IP-adresser. Om du vill identifiera brandväggsproblem gör du en ledig/upptagen-begäran från Exchange Online och kontrollerar sedan den lokala brandväggen, omvänd proxy och nätverksloggar. Mer information om hur du konfigurerar en brandvägg finns i Brandväggsöverväganden för federerade delegerings - och Microsoft 365-URL:er och IP-adressintervall.

  2. Kontrollera att begäranden från Exchange Online når de lokala klientåtkomstservrarna. Följ dessa steg på alla lokala klientåtkomstservrar:

    1. Skicka en ledig/upptagen-begäran från Exchange Online.

    2. Kontrollera IIS-loggarna i W3SVC1-mappen för standardwebbplatsen för att kontrollera att den lediga/upptagna begäran har loggats. W3SVC1-mappsökvägen är %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

    3. Kontrollera HTTP-proxyloggarna i följande mappar för att kontrollera att den lediga/upptagna begäran har loggats:

      • %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover

      • %ExchangeInstallPath%\Logging\HttpProxy\Ews

  3. Testa anslutningen från Exchange Online till den lokala EWS-slutpunkten (Exchange Web Services) genom att köra följande cmdlet i Exchange Online PowerShell:

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

    Kommentarer

    • Det här testet är användbart om du begränsar inkommande anslutningar från Internet så att endast Exchange Online IP-adresser kan ansluta till din lokala EWS-slutpunkt.

    • Om bara ett fåtal molnanvändare påverkas av det här problemet och deras postlådor finns på samma e-postserver i Exchange Online kontrollerar du om e-postservern kan ansluta till lokala slutpunkter. Det är möjligt att en lokal slutpunkt blockerar anslutningar från den utgående externa IP-adressen för den e-postservern.

    • När du uppmanas att ange autentiseringsuppgifter anger du autentiseringsuppgifterna för domänadministratören i formatet "domän\administratör".

Tillbaka till början

Automatisk upptäckt misslyckades för e-postadress: HTTP-status 404

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Automatisk upptäckt misslyckades för e-postadressanvändarens <SMTP-adress> med felet System.Net.WebException: Begäran misslyckades med HTTP-statuskoden 404 Not Found.

Det här felet kan inträffa om slutpunkter för automatisk upptäckt är icke-funktionella eller felkonfigurerade.

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Kontrollera om slutpunkten för automatisk upptäckt är giltig:

    1. Kör följande kommandon för att hämta URL:en för slutpunkten för automatisk upptäckt från parametern DiscoveryEndpoint eller TargetAutodiscoverEpr :

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

    2. Gå till URL:en för autodiscover-slutpunkten i en webbläsare. En giltig slutpunkt för automatisk upptäckt returnerar inte HTTP-statuskoden 404 Not Found.

  2. Kontrollera att domänen för den lokala användaren anges i molnanvändarens organisationsinställningar (anslutningsapp inom organisationen eller organisationsrelationen):

    1. Kör följande PowerShell-cmdletar i Exchange Online PowerShell:

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

      Kontrollera att domänen för den lokala användaren visas i utdata från något av kommandona. Om molnanvändare till user1@contoso.com exempel söker efter ledig/upptagen för den lokala användaren user2@contoso.rokontrollerar du att den lokala domänen contoso.ro visas.

    2. Om domänen för den lokala användaren inte finns i molnanvändarens organisationsinställningar lägger du till domänen genom att köra följande PowerShell-cmdlet:

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

  3. Kontrollera att SVC-hanterarmappningen finns i både de virtuella katalogerna Autodiscover och EWS under Standardwebbplats i IIS Manager. Mer information finns i FederationInformation kunde inte tas emot och Undantag har genererats av målet.

    Obs! Mappningen AutodiscoverDiscoveryHander (*.svc) används inte för federationsfri/upptagen-sökning.

Tillbaka till början

Undantagsproxywebbbegäran misslyckades

LOCK: 43532

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Undantagsproxywebbbegäran misslyckades. , inre undantag: Begäran misslyckades med HTTP-status 401: Obehörig diagnostik: 2000005; reason= "Användaren som anges av användarkontexten i token är tvetydig." ; error_category="invalid_user"

Det här felet kan inträffa om DEN lokala användarens UPN-, SMTP-adress eller SIP-adress används av en annan lokal postlåda.

Lösning

Du löser problemet genom att följa dessa steg:

  1. Sök efter lokala användarobjekt som har en duplicerad UPN-, SMTP-adress eller SIP-adress med hjälp av anpassade LDAP-frågor. Du kan köra LDAP-frågor med hjälp av LDP.exe eller MMC-snapin-modulen Active Directory-användare och -datorer.

    Om du till exempel vill visa alla användare som har user@corp.contoso.com som UPN, user@contoso.com som SMTP-adress eller user@contoso.com som SIP-adress använder du följande LDAP-fråga:

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

    Mer information om hur du använder LDP.exe eller Active Directory-användare och datorer för att hitta Active Directory-objekt finns i LDP-exempel.

  2. Ändra dubblettadressen eller ta bort det duplicerade användarobjektet.

Tillbaka till början

En befintlig anslutning tvångsavslutades av fjärrvärden

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Proxywebbbegäran misslyckades. , inre undantag: System.Net.WebException: Den underliggande anslutningen stängdes: Ett oväntat fel uppstod vid en mottagning. System.IO.IOException: Det går inte att läsa data från transportanslutningen: En befintlig anslutning stängdes med tvång av fjärrvärden. System.Net.Sockets.SocketException: En befintlig anslutning stängdes med tvång av fjärrvärden.

Det här felet kan inträffa om en lokal brandvägg blockerar en inkommande anslutning från en extern utgående IP-adress i Exchange Online.

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Kontrollera om ledig/upptagen-begäranden från Exchange Online når IIS på en Exchange-server. Gör en ledig/upptagen-begäran från Exchange Online och sök efter följande IIS-loggposter som gjordes vid tidpunkten för den lediga/upptagna begäran:

    • En post för automatisk upptäckt i mappen %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover som innehåller "ASAutoDiscover/CrossForest/EmailDomain".

      Obs! Om du manuellt anger parametern TargetSharingEpr i organisationsrelationen till den lokala externa EXCHANGE Web Services-URL:en (EWS), kringgås automatisk upptäckt och den här posten finns inte.

    • En EWS-post i mappen %ExchangeInstallPath%\Logging\HttpProxy\Ews som innehåller "ASProxy/CrossForest/EmailDomain".

    Obs! Tidsstämplar i IIS-loggar använder UTC-tid.

  2. Kontrollera att brandväggen på varje lokal Exchange-server tillåter inkommande eller utgående anslutningar mellan Exchange Server-slutpunkter och Exchange Online IP-adresser. Om du vill identifiera brandväggsproblem gör du lediga/upptagna begäranden från Exchange Online och kontrollerar sedan den lokala brandväggen, omvänd proxy och nätverksloggar. Mer information om hur du konfigurerar en brandvägg finns i Brandväggsöverväganden för federerade delegerings - och Microsoft 365-URL:er och IP-adressintervall.

  3. Om din organisation använder organisationsrelationer för att implementera ledig/upptagen kontrollerar du att ett federationscertifikat är installerat på varje Exchange-server. Kör följande kommandon i Exchange Management Shell (EMS):

    Test-FederationTrustCertificate
Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo | FL

    Om federationscertifikatet har installerats ska kommandoutdata inte innehålla några fel eller varningar.

  4. Följ dessa steg för att växla WSSecurity-autentisering:

    1. Följ proceduren i Användare från en federerad organisation kan inte se ledig/upptagen-information från en annan Exchange-organisation för att aktivera, eller återställa om den redan är aktiverad, WSSecurity-autentisering i både de virtuella katalogerna Autodiscover och EWS på alla lokala Exchange-servrar. Utför det här steget även om WSSecurity-autentisering redan är aktiverat.

    2. Återanvänd programpoolerna För automatisk upptäckt och EWS i IIS-hanteraren.

    3. iisreset /noforce Kör kommandot i ett PowerShell- eller kommandotolkfönster på varje lokal Exchange-server för att starta om IIS.

  5. Om bara ett fåtal molnanvändare påverkas av det här problemet och deras postlådor finns på samma e-postserver i Exchange Online kontrollerar du om e-postservern kan ansluta till lokala slutpunkter. Det är möjligt att en lokal slutpunkt blockerar anslutningar från den utgående IP-adressen för den e-postservern.

Tillbaka till början

Konfigurationsinformation för skog/domän hittades inte i Active Directory

LOCK: 47932

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare eller tvärtom. När du diagnostiserar problemet visas följande felmeddelande:

Det gick inte att hitta konfigurationsinformationen för skogs-/domändomänen <> i Active Directory.

Det här felet kan inträffa om organisationsinställningarna är felkonfigurerade.

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Kontrollera att domänen för en användare vars ledig/upptagen-information begärs finns i organisationsinställningarna för den användare som försöker visa ledig/upptagen-information. Välj någon av följande procedurer beroende på ledig/upptagen-riktningen.

    • Moln till lokal plats

      Följ dessa steg för en molnanvändare som försöker visa ledig/upptagen-information för en lokal användare:

      1. Anslut till Exchange Online PowerShell och kör sedan följande PowerShell-cmdletar för att hämta de federerade domänerna:

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

        Kontrollera att domänen för den lokala användaren visas i utdata från något av kommandona. Om molnanvändare till user1@contoso.com exempel söker efter ledig/upptagen för den lokala användaren user2@contoso.rokontrollerar du att den lokala domänen contoso.ro visas.

        Obs!

        Du kan också hitta domännamnen genom att köra (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses i Exchange Online PowerShell eller genom att köra (Get-FederatedOrganizationIdentifier).Domains i det lokala Exchange Management Shell (EMS).

      2. Om domänen för den lokala användaren inte finns i molnanvändarens organisationsinställningar lägger du till domänen genom att köra följande PowerShell-cmdlet:

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

    • Lokalt till molnet

      Följ dessa steg för en lokal användare som försöker visa ledig/upptagen-information för en molnanvändare:

      1. Kör följande PowerShell-cmdletar i EMS:

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

        Kontrollera om domänen för molnanvändaren är en matchning för någon av de domäner som anges i kommandoutdata. Om den lokala användaren user1@contoso.ro till exempel söker efter ledig/upptagen-information för molnanvändaren user2@contoso.comkontrollerar du att molndomänen contoso.com finns i utdata från något av kommandona.

      2. Om molnanvändarens domän inte finns i den lokala användarens organisationsinställningar lägger du till domänen. Kör följande kommando:

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

  2. Kontrollera att din Hybrid Exchange-distribution har en fullständig hybridkonfiguration. Om det behövs kör du hybridkonfigurationsguiden (HCW) igen och väljer Fullständig hybridkonfiguration i stället för Minimal hybridkonfiguration. En minimal hybridkonfiguration skapar inte en organisationsrelation (federationsförtroende) eller anslutningsappar inom organisationen.

Tillbaka till början

Proxywebbbegäran misslyckades: HTTP-status 401

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet hittar du något av följande felmeddelanden.

Felmeddelande 1

Proxywebbbegäran misslyckades. ,inre undantag: Begäran misslyckades med HTTP-status 401: Obehörig.

Felmeddelande 2

Automatisk upptäckt misslyckades för e-postadressen. ,inre undantag: Begäran misslyckades med HTTP-status 401: Obehörig.

Det här felet kan inträffa om en perimeterenhet framför Exchange Server har konfigurerats för att förautentisera (kräver användarnamn och lösenord) i stället för att skicka begäranden från Exchange Online direkt till Exchange Server. De virtuella katalogerna Autodiscover och EWS i Exchange-hybriddistributioner stöder inte förautentisering.

Exempel på perimeterenheter är omvända proxyservrar, brandväggar och Microsoft Threat Management Gateway (TMG).

Felmeddelande 1 anger att en EWS-begäran misslyckades.

Felmeddelande 2 anger att en begäran om automatisk upptäckt misslyckades.

Felsökningssteg

Använd följande steg för att felsöka problemet med ledig/upptagen oavsett vilket felmeddelande du fick. När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Kontrollera om förautentisering är aktiverat. Gör så här:

    1. Kör testet Ledig/upptagen i Analysverktyg för fjärranslutning för att kontrollera om förautentisering är aktiverat. Molnpostlådan är källpostlådan och den lokala postlådan är målpostlådan. När testet är klart kontrollerar du direktautentiseringsstatusen vid slutpunkten. Om du ser en röd bock ska du inaktivera förautentisering och testa igen. Om du ser en grön bockmarkering fortsätter du till nästa steg eftersom det kan vara en falsk positiv identifiering.

    2. Kontrollera om en ledig/upptagen-begäran från Exchange Online når IIS. Utför en ledig/upptagen-fråga och sök sedan i IIS-loggarna i Exchange Server efter någon av följande poster vid tidpunkten för frågan:

      • I mappen %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover söker du efter en post för automatisk upptäckt som har HTTP-statuskoden 401 Unauthorized och innehåller texten "ASAutoDiscover/CrossForest/EmailDomain".

        Obs! Om parametern TargetSharingEpr i organisationsrelationen anger en lokal extern EWS-URL kringgås automatisk upptäckt och den här posten visas inte.

      • I mappen %ExchangeInstallPath%\Logging\HttpProxy\Ews söker du efter en EWS-post som har HTTP-statuskoden 401 Unauthorized och innehåller texten "ASProxy/CrossForest/EmailDomain".

      Obs! Tidsstämplar i IIS-loggar använder UTC-tid. Vissa poster som har HTTP-statuskoden 401 Unauthorized är normala.

      De angivna posterna anger att den lediga/upptagna begäran nådde IIS och vanligtvis utesluter förautentiseringsproblem. Om du inte hittar de angivna posterna kontrollerar du dina omvända proxy- och brandväggsloggar för att förstå var den lediga/upptagna begäran fastnade.

  2. Kontrollera att du har aktiverat WSSecurity (Exchange Server 2010) eller OAuth-autentisering (Exchange Server 2013 och senare versioner) på de virtuella katalogerna EWS och Autodiscover. Kontrollera också att du har aktiverat standardinställningarna för autentisering i IIS för de virtuella katalogerna Autodiscover och EWS. Mer information finns i Standardinställningar för autentisering för virtuella Exchange-kataloger och Standardinställningar för virtuella Exchange-kataloger.

  3. Följ lösningsstegen i Ett fel uppstod när du verifierade säkerheten för meddelandet. Om WSSecurity har konfigurerats kontrollerar du att du utför steget som växlar WSSecurity. Om OAuth-autentisering har konfigurerats i stället för WSSecurity växlar du OAuth-autentisering på de virtuella katalogerna Autodiscover och EWS genom att köra följande kommandon:

    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. Kontrollera att du har ett uppdaterat federationsförtroende. Kör följande kommando i Exchange Online PowerShell för att hämta information om federationsförtroende för din Exchange-organisation:

    Get-FederationTrust

    Kommandots utdata bör innehålla följande information:

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

    Obs! Förtroendet WindowsLiveId är en konsumentinstans av Microsoft Federation Gateway. Förtroendet MicrosoftOnline är en affärsinstans av Microsoft Federation Gateway.

    För ett uppdaterat federationsförtroende kontrollerar du att ApplicationIdentifier är och inte 292841, och att ApplicationUri är outlook.com och inte outlook.live.com260563 . Om du har ett inaktuellt federationsförtroende kontaktar du Microsoft Support.

Tillbaka till början

Automatisk upptäckt misslyckades för e-postadress: InvalidUser

LOCK: 33676

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Svaret från tjänsten Autodiscover vid misslyckades påhttps://Autodiscover/Autodiscover.svc/WSSecurity grund av ett fel i användarinställningen "ExternalEwsUrl". Felmeddelande: InvalidUser.

Felmeddelandet kan visas när du kör testet Ledig/upptagen i analysverktyg för fjärranslutning.

Det här felet kan inträffa om molnpostlådan eller slutpunkten för automatisk upptäckt är felkonfigurerad.

Felsökningssteg

  1. Kontrollera att molnanvändaren har en sekundär SMTP-adress som innehåller domänen onmicrosoft.com genom att köra följande kommando:

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

    En användare som har den primära SMTP-adressen user1@contoso.com bör till exempel ha en sekundär SMTP-adress som liknar user1@contoso.mail.onmicrosoft.com.

    Om molnanvändaren hanteras från Exchange Server lägger du till den sekundära SMTP-adressen till Exchange Server och synkroniserar sedan identitetsdata mellan din lokala miljö och Microsoft Entra-ID.

  2. Kör följande kommandon för att ange TargetSharingEpr parametervärdet i organisationsrelationen till den lokala externa URL:en för Exchange Web Services (EWS):

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

    När du har angett TargetSharingEpr parametervärdet kringgår molnpostlådan Automatisk upptäckt och ansluter direkt till EWS-slutpunkten för den lokala postlådan.

Tillbaka till början

Anroparen har inte åtkomst till ledig/upptagen-data

LOCK: 47652, 44348, 40764

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare eller tvärtom. När du diagnostiserar problemet visas följande felmeddelande:

Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException: Anroparen har inte åtkomst till ledig/upptagen-data.

Det här felet kan inträffa om postlådan för den användare vars ledig/upptagen-information begärs är felkonfigurerad.

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Kontrollera kalenderbehörigheterna för den användare vars ledig/upptagen-information begärs genom att köra följande kommando:

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

    Värdet AccessRights för Default användaren i kommandots utdata ska vara AvailabilityOnly eller LimitedDetails. Om värdet AccessRights är Nonekör du följande PowerShell-cmdlet för att ange värdet till antingen AvailabilityOnly eller LimitedDetails:

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

  2. Använd tillämplig metod för att kontrollera organisationsrelationen:

    • Om en molnanvändare inte kan visa ledig/upptagen-information för en lokal användare:

      Kontrollera att den lokala organisationsrelationen anger den molndomän som har åtkomst till den lokala ledig/upptagen-informationen. Ett exempel på en molndomän är contoso.mail.onmicrosoft.com. Information om hur du ändrar organisationsrelationen i Exchange Server finns i Använda PowerShell för att ändra organisationsrelationen. Kontrollera också att e-postadressen Från för molnanvändaren har samma molndomän, till exempel lucine.homsi@contoso.mail.onmicrosoft.com.

    • Om en lokal användare inte kan visa ledig/upptagen-information för en molnanvändare:

      Kontrollera att molnorganisationens relation anger den lokala domän som har åtkomst till ledig/upptagen-information i molnet. Ett exempel på en lokal domän är contoso.com. Information om hur du ändrar organisationsrelationen i Exchange Online finns i Använda Exchange Online PowerShell för att ändra organisationsrelationen. Kontrollera också att från-e-postadressen för den lokala användaren har samma lokala domän, till exempel lucine.homsi@contoso.com.

Tillbaka till början

Ett fel uppstod vid bearbetning av säkerhetstoken i meddelandet

LOCK: 59916

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

ProxyWebRequestProcessingException ErrorProxyRequestProcessingFailed
Proxywebbbegäran misslyckades. , inre undantag: Ett fel uppstod vid bearbetning av säkerhetstoken i meddelandet.

Det här felet kan inträffa om certifikaten eller metadata i Microsoft Federation Gateway är ogiltiga.

Felsökningssteg

  1. Kontrollera förfallodatum och tumavtryck för lokala federationsförtroendecertifikat genom att köra följande PowerShell-cmdletar:

    Get-FederationTrust | FL
Test-FederationTrust
Test-FederationTrustCertificate

  2. Om du vill uppdatera metadata i Microsoft Federation Gateway kör du följande kommando två gånger i det lokala Exchange Management Shell (EMS):

    Get-FederationTrust | Set-FederationTrust -RefreshMetadata

    Mer information finns i Ledig/upptagen-sökning slutar fungera.

Tillbaka till början

Begäran mellan organisationer tillåts inte eftersom beställaren kommer från en annan organisation

LOCK: 39660

Fråga

Du har ett hybridnätsscenario där en molnanvändare i en icke-berusad Exchange Online-klientorganisation inte kan visa ledig/upptagen-information för en molnanvändare i en annan Exchange Online-klientorganisation som blir hybrid. När du diagnostiserar problemet visas följande felmeddelande:

Begäran mellan organisationer för SMTP-adressen> för postlådan <tillåts inte eftersom beställaren kommer från en annan organisation
Mottagare: <SMTP-adress>
Undantagstyp: CrossOrganizationProxyNotAllowedForExternalOrganization
Undantagsmeddelande: Begäran mellan organisationer för <SMTP-adress> tillåts inte eftersom beställaren kommer från en annan organisation.

En användare lucine@adatum.com i en icke-berusad Exchange Online-klientorganisation kan till exempel inte visa ledig/upptagen för en molnanvändare chanok@contoso.com i en hybridklientorganisation. Molnanvändaren chanok@contoso.com har en proxy-e-postadress chanok@contoso.mail.onmicrosoft.com. Den icke-hybrida klientorganisationen har två organisationsrelationer: contoso.com (lokalt) och contoso.mail.onmicrosoft.com (moln). Automatisk upptäckt för contoso.com punkter till Exchange Server och Automatisk upptäckt för contoso.mail.onmicrosoft.com punkter till Exchange Online. Användaren i den icke-berusade klientorganisationen får felmeddelandet när han eller hon frågar efter ledig/upptagen-information för chanok@contoso.com, eftersom Automatisk upptäckt för contoso.com punkter inte pekar på Exchange Online.

Obs!

Motsvarande lokala hybridnätsscenario finns i Hybrid mesh.

Lösning

För att lösa det här problemet kan din organisation använda någon av följande metoder:

  • Användare i den icke-kompatibla Exchange Online-klientorganisationen bör fråga en molnanvändares lediga/upptagna enhet i en hybridklientorganisation med hjälp av den e-postadress som Automatisk upptäckt pekar på Exchange Online. Till exempel lucine@adatum.com frågor om ledig/upptagen-information för chanok@contoso.mail.onmicrosoft.com. Om du vill fråga efter ledig/upptagen-information måste användare i den icke-berusade Exchange Online-klientorganisationen veta vilka användare i hybridklientorganisationen som finns i molnet och för var och en av dessa användare den e-postadress som automatisk upptäckt pekar på Exchange Online.

  • En administratör för den icke-berusade Exchange Online-klienten bör ange den externa e-postadressen för varje molnanvändare i hybridklientorganisationen till den e-postadress som Automatisk upptäckt pekar på Exchange Online. En administratör i den icke-berusade Exchange Online-klientorganisationen anger till exempel mål-e-postadressen chanok@contoso.com för i hybridklientorganisationen till chanok@contoso.mail.onmicrosoft.com. För att göra den här ändringen måste administratören veta vilka användare i hybridklientorganisationen som finns i molnet och för var och en av dessa användare den e-postadress som Automatisk upptäckt pekar på Exchange Online. Mer information om synkronisering mellan klientorganisationer av e-postadresser för användare finns i Vad är synkronisering mellan klientorganisationer.

Mer information

En användare kan stöta på ett liknande problem i följande scenario:

  • Användaren finns i en icke-berusad Exchange Server-klientorganisation.
  • Användaren försöker visa ledig/upptagen för en lokal användare i en hybridklientorganisation.
  • Automatisk upptäckt för hybridklientorganisationen pekar på Exchange Online.

En användare i en icke-berusad Exchange Server-klientorganisation kan till exempel inte visa ledig/upptagen-informationen för den lokala användaren chanok@contoso.com i en hybridklient eftersom Automatisk upptäckt för contoso.com pekar på Exchange Online (autodiscover-s.outlook.com).

Tillbaka till början

Begäran misslyckades med HTTP-status 401: Obehörig (signeringscertifikat saknas)

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

System.Net.WebException: Begäran misslyckades med HTTP-status 401: Obehörig.

Om du kör cmdleten Test-OAuthConnectivity visas följande felmeddelande i kommandots utdata:

Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException: Signeringscertifikat saknas.

Du kan exempelvis använda följande kommandon:

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

Parametervärdet TargetUri är den lokala url:en för automatisk upptäckt av tjänsten. Ett exempel på den URL:en är https://mail.contoso.com/Autodiscover/Autodiscover.svc.

Det här felet kan inträffa om autentiseringskonfigurationen har ett ogiltigt OAuth-certifikat.

Lösning

Du löser problemet genom att följa dessa steg:

  1. Kör följande PowerShell-cmdlet i Exchange Management Shell (EMS) för att hämta tumavtrycket för det OAuth-certifikat som används av autentiseringskonfigurationen:

    Get-AuthConfig | FL CurrentCertificateThumbprint

    Om kommandots utdata inte returnerar ett certifikattumavtryck går du till steg 3. Annars fortsätter du till nästa steg.

  2. Kör följande PowerShell-cmdlet för att kontrollera om certifikatet som identifierades i steg 1 finns i Exchange Server:

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

    Om Exchange Server inte returnerar något certifikat går du till steg 3 för att skapa ett nytt certifikat.

    Om Exchange Server returnerar ett certifikat, men tumavtrycket skiljer sig från tumavtrycket som du fick i steg 1, går du till steg 4. I steg 4 anger du tumavtrycket för certifikatet som Exchange Server returnerade.

  3. Kör följande PowerShell-cmdlet för att skapa ett nytt OAuth-certifikat:

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

    Obs!

    Om du uppmanas att ersätta SMTP-certifikatet ska du inte acceptera uppmaningen.

    I steg 4 anger du tumavtrycket för det nya certifikatet som du skapade i det här steget.

  4. Kör följande PowerShell-cmdletar för att uppdatera autentiseringskonfigurationen så att det angivna certifikatet används:

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

    Obs!

    Om du får en varning om att giltighetsdatumet är mindre än 48 timmar från och med nu väljer du att fortsätta.

  5. Kör följande PowerShell-cmdlet för att ta bort referenser till det tidigare certifikatet:

    Set-AuthConfig -ClearPreviousCertificate

Tillbaka till början

Programmet saknar ett länkat konto för RBAC-roller, eller så har det länkade kontot inga RBAC-rolltilldelningar, eller så är kontot för anropande användare inaktiverat

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

System.Web.Services.Protocols.SoapException: Programmet saknar ett länkat konto för RBAC-roller, eller så har det länkade kontot inga RBAC-rolltilldelningar eller så är det anropande användarkontot inaktiverat.

Felsökningssteg

Använd följande steg för att felsöka de problem som nämns i felmeddelandet. När du har slutfört steg 1 och 2 kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Kontrollera att posten "Exchange Online-ApplicationAccount" finns i listan över Exchange Server-partnerprogram. Kontrollera genom att köra följande PowerShell-cmdlet i Exchange Management Console (EMS):

    Get-PartnerApplication | FL LinkedAccount

    Kontoposten bör visas som <root domain FQDN>/Users/Exchange Online-ApplicationAccount. Om posten visas går du till steg 2.

    Om kontoposten inte visas lägger du till kontot genom att följa dessa steg:

    1. Kör följande PowerShell-cmdletar för att hitta kontot i den lokala Active Directory:

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

      Om kontot visas i Active Directory går du till steg 1b.

      Om kontot inte visas i Active Directory kan det ha tagits bort. Använd ADRestore för att kontrollera kontostatusen och återställa den, om den tas bort. Om du har återställt kontot med hjälp av ADRestore går du till steg 1b.

      Om du inte kan återställa kontot med hjälp av ADRestore följer du proceduren som beskrivs i Active Directory och domäner för Exchange Server. Om den proceduren inte återställer kontot skapar du kontot manuellt i Active Directory och fortsätter sedan till steg 1b.

    2. Kör följande PowerShell-cmdlet för att lägga till Active Directory-kontot i listan över Exchange Server-partnerprogram:

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

    3. Starta om alla lokala Exchange-servrar eller starta om IIS genom att köra iisreset /noforce kommandot i ett PowerShell- eller kommandotolksfönster på varje server.

  2. Kör följande PowerShell-cmdlet i EMS för att kontrollera tilldelningarna för rollbaserad åtkomstkontroll (RBAC):

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

    Kommandots utdata kan till exempel visa följande rolltilldelningar:

    Skärmbild av utdata från kommandot rolltilldelningar.

  3. Sök i följande loggar efter de problem som anges i felmeddelandet:

    • Exchange Web Services-loggar (EWS) som finns i mappen %ExchangeInstallPath%\Logging\Ews
    • Programhändelseloggar
    • Systemhändelseloggar

  4. Sök i loggarna som visas i steg 3 efter ett felmeddelande som refererar till AuthzInitializeContextFromSid. Om du ser felmeddelandet kan du läsa följande resurser:

Tillbaka till början

De angivna och lagrade lösenorden matchar inte

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Soap-felfel har tagits emot. De angivna och lagrade lösenorden matchar inte.

Du ser samma felmeddelande när du kör följande cmdlet för att kontrollera om molnanvändaren kan hämta en delegeringstoken för den lokala användarpostlådan:

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

Orsak

Det finns en inkonsekvens i Azure-autentiseringsuppgifterna för specifika molnanvändare.

Lösning

Du löser problemet genom att följa dessa steg:

  1. Återställ molnanvändarens lösenord. Välj antingen samma eller ett annat lösenord.

  2. Uppdatera användarens huvudnamn (UPN) för molnanvändaren för att använda domänen onmicrosoft.com och återställ sedan UPN till dess tidigare värde. Om till exempel UPN för molnanvändaren är user@contoso.comändrar du det till det tillfälliga UPN, user@contoso.mail.onmicrosoft.comoch återställer sedan UPN till user@contoso.com. Om du vill göra detta använder du antingen Azure AD PowerShell eller MSOL-tjänsten.

    • Använda Azure AD PowerShell

      Kör följande PowerShell-cmdletar:

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

    • Använda MSOL-tjänsten

      Kör följande PowerShell-cmdletar:

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

  3. Kontrollera att värdet för ImmutableId det lokala användarobjektet är null. ImmutableId Kontrollera värdet för det lokala användarobjektet genom att köra följande kommando i Exchange Management Shell (EMS):

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

    Använd någon av följande metoder, beroende på ImmutableId värdet.

    • ImmutableId-värdet är null

      Om värdet ImmutableId är null växlar du dess värde:

      1. ImmutableId Ange för fjärrpostlådeobjektet till UPN för molnanvändaren genom att köra följande PowerShell-cmdlet i EMS:

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

        Till exempel: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

      2. Synkronisera ändringen till molnet genom att köra följande PowerShell-cmdletar i EMS:

        Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

        Kontrollera att värdet ImmutableId har uppdaterats genom att köra följande PowerShell-cmdlet i Exchange Online PowerShell:

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

      3. ImmutableId Återställ fjärrpostlådeobjektets objekt till null genom att köra följande PowerShell-cmdlet i EMS:

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

      4. Synkronisera ändringen till molnet genom att köra följande PowerShell-cmdlet i EMS:

        Start-ADSyncSyncCycle -PolicyType Delta

        Kontrollera att värdet ImmutableId har uppdaterats genom att köra följande PowerShell-cmdlet i Exchange Online PowerShell:

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

    • ImmutableId-värdet är inte null

      Om värdet ImmutableId inte är null kör du följande kommando i EMS för att ange ImmutableId värdet till null:

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

      Du kan kontrollera att värdet har uppdaterats genom att ImmutableId köra följande PowerShell-cmdlet i Exchange Online PowerShell:

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

Tillbaka till början

Lösenordet måste ändras eller så har lösenordet för kontot upphört att gälla

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet hittar du något av följande felmeddelanden.

Felmeddelande 1

Lösenordet för kontot har upphört att gälla

Felmeddelande 2

Lösenordet måste ändras

Du ser samma felmeddelande när du kör följande cmdlet för att kontrollera om molnanvändaren kan hämta en delegeringstoken för den lokala användarpostlådan:

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

Det här felet kan inträffa om det finns en inkonsekvens i Azure-autentiseringsuppgifterna för specifika molnanvändare.

Åtgärd

Välj den lösning som matchar felmeddelandet.

Lösning för felmeddelande 1

Åtgärda problemet genom att använda antingen Azure AD PowerShell eller MSOL-tjänsten.

  • Använda Azure AD PowerShell

    Kör följande PowerShell-cmdletar:

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

  • Använda MSOL-tjänsten

    Kör följande PowerShell-cmdletar:

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

Lösning för felmeddelande 2

Åtgärda problemet genom att köra följande PowerShell-cmdletar:

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

Mer information finns i Kan inte se ledig/upptagen-information efter migrering från Exchange on-premises.

Tillbaka till början

Etablering krävs innan federerat konto kan loggas in

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Etablering krävs innan federerat konto kan loggas in. ErrorWin32InteropError

Du får också samma felmeddelande när du kör följande cmdlet för att kontrollera om molnanvändaren kan hämta en delegeringstoken för den lokala användarpostlådan:

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

Det här felet kan inträffa om det finns en inkonsekvens i konfigurationen av federerade användare i Microsoft Entra-ID.

Åtgärd

Obs!

Om problemet påverkar de flesta eller alla molnanvändare i din organisation kontaktar du Microsoft Support.

Åtgärda problemet genom att uppdatera användarens huvudnamn (UPN) för molnanvändaren för att använda domänen onmicrosoft.com och sedan växla tillbaka den till dess tidigare värde (federerad domän). Om till exempel UPN för molnanvändaren är user@contoso.comväxlar du det till det tillfälliga UPN user@contoso.mail.onmicrosoft.com :t och sedan tillbaka till user@contoso.com. Det gör du genom att använda någon av följande metoder (Azure AD PowerShell eller MSOL-tjänsten):

  • Använda Azure AD PowerShell

    Kör följande PowerShell-cmdletar:

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

  • Använda MSOL-tjänsten

    Kör följande PowerShell-cmdletar:

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

Tillbaka till början

Tidsgränsen för begäran översågs

LOCK: 43404

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Tidsgränsen för begäran översågs
Det gick inte att bearbeta begäran i tid. Tidsgränsen uppnåddes under "Waiting-For-Request-Completion".
Microsoft.Exchange.InfoWorker.Common.Availability.TimeoutExpiredException: Begäran kunde inte bearbetas i tid. Tidsgränsen uppnåddes under "Waiting-For-Request-Completion".
Namnet på den server där undantaget uppstod: <servernamn>.

Du får också samma felmeddelande om du kör följande cmdlet för att kontrollera om molnanvändaren kan hämta en delegeringstoken för den lokala användarpostlådan:

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

Det här felet kan inträffa om det finns nätverksproblem eller tillfälliga problem. Felmeddelandet är allmänt.

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Om du vill utesluta tillfälliga problem kontrollerar du att molnanvändaren konsekvent får samma felmeddelande under upprepade försök att hämta den lokala användarens ledig/upptagen-information.

  2. Kontrollera om du kan hämta en delegeringstoken när du kör var och en av följande cmdletar:

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

    Obs! Kör cmdleten Test-FederationTrust på alla lokala Exchange-servrar.

  3. Kontrollera att Exchange Server har utgående Internetåtkomst till båda följande resurser:

    • Microsoft Federation Gateway (eller en auktoriseringsserver, om du använder OAuth)

    • Tillgänglighets-URL:en för Microsoft 365: https://outlook.office365.com/ews/exchange.asmx

    Mer information finns i Url:er och IP-adressintervall för Microsoft 365 och Brandväggsöverväganden för federerad delegering.

  4. Kontrollera att systemkontot i Exchange Server har internetåtkomst till följande URL:er. Följ dessa steg på varje Exchange-server:

    1. Kör följande PsExec-kommando för att starta en PowerShell-session som startar en webbläsare från systemkontot:

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

    2. Testa webbläsaråtkomst (ingen OAuth) från systemkontot till följande URL:er för Microsoft Federation Gateway:

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

        Webbläsaren bör visa en XML-sida.

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

        Webbläsaren bör uppmana dig att ladda ned filen.

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

        Webbläsaren bör visa en lista över åtgärder som stöds av ManageDelegation2.

    3. Testa webbläsaråtkomst (OAuth) från systemkontot till följande URL:er för Microsoft-auktoriseringsservern:

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

        Webbläsaren bör visa en inloggningsprompt.

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

        Webbläsaren bör visa inloggningsfelet "Tyvärr, men vi har problem med att logga in dig".

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

        Webbläsaren bör visa HTTP-statuskoden 400 Bad Requesteller inloggningsfelmeddelandet "Tyvärr, men vi har problem med att logga in dig".

  5. Hämta information om en ledig/upptagen-begäran genom att kontrollera loggarna för Exchange Web Services (EWS):

    1. Skicka en ledig/upptagen-begäran från Exchange Online.

    2. Leta upp posten i EWS-loggarna och kontrollera värdet i time-taken kolumnen. EWS-loggarna finns i mappen %ExchangeInstallPath%\Logging\Ews .

    3. Kontrollera IIS-loggarna i W3SVC1-mappen på standardwebbplatsen för att kontrollera att den lediga/upptagna begäran har loggats. W3SVC1-mappsökvägen är %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

Tillbaka till början

Det angivna medlemsnamnet är ogiltigt eller tomt

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

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>Det angivna medlemsnamnet är ogiltigt eller tomt. </psf:text></psf:internalerror></psf:error></S:Detail></S:Fault> Microsoft.Exchange.Net.WSTrust.SoapFaultException: Soap fault exception received. på Microsoft.Exchange.Net.WSTrust.SecurityTokenService.EndIssueToken(IAsyncResult asyncResult) på Microsoft.Exchange.InfoWorker.Common.Availability.ExternalAuthenticationRequest.Complete(IAsyncResult asyncResult)

Felet kan inträffa av någon av följande orsaker:

  • En inkonsekvens i Microsoft Entra-ID för användare som begär en delegeringstoken
  • En inkonsekvens i konfigurationen av federerade användare i Active Directory Federation Services (AD FS)

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Uppdatera användarens huvudnamn (UPN) för molnanvändaren för att använda domänen onmicrosoft.com och återställ sedan UPN till dess tidigare värde. Om till exempel UPN för molnanvändaren är user@contoso.comändrar du det till det tillfälliga UPN och user@contoso.mail.onmicrosoft.comåterställer sedan UPN till user@contoso.com. Det gör du genom att använda någon av följande metoder (Azure AD PowerShell eller MSOL-tjänsten):

    • Använda Azure AD PowerShell

      Kör följande PowerShell-cmdletar:

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

    • Använda MSOL-tjänsten

      Kör följande PowerShell-cmdletar:

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

  2. Kontrollera AD FS-regler, slutpunkter och loggar.

  3. Sök efter ett fel som är relaterat till ImmutableID molnanvändarens i kommandoutdata för följande PowerShell-cmdlet:

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

    Kommandots utdata kan till exempel innehålla följande felmeddelande:

    "E-postadressen "XGuNpVunD0afQeVNfyoUIQ==" stämmer inte. Använd det här formatet: användarnamn, @-tecknet följt av domännamnet. Till exempel eller tonysmith@contoso.comtony.smith@contoso.com.
    + CategoryInfo: NotSpecified: (:) [Test-OrganizationRelationship], FormatException"

    Om du får ett liknande felmeddelande använder du någon av följande metoder för att kontrollera att ImmutableId värdet är null (tomt värde):

    • Om molnanvändaren inte synkroniseras lokalt kontrollerar du ImmutableId värdet genom att köra följande PowerShell-cmdlet i Exchange Online PowerShell:

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

      Om värdet ImmutableId inte är null kör du följande PowerShell-cmdlet i Exchange Online PowerShell:

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

    • Om molnanvändaren synkroniseras lokalt kontrollerar du ImmutableId värdet för det lokala användarobjektet genom att köra följande kommando i Exchange Management Shell (EMS):

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

      Använd någon av följande metoder, beroende på ImmutableId värdet:

      • ImmutableId-värdet är null

        Om värdet ImmutableId är null växlar du dess värde:

        1. ImmutableId Ange för fjärrpostlådeobjektet till UPN för molnanvändaren genom att köra följande PowerShell-cmdlet i EMS:

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

          Till exempel: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

        2. Synkronisera ändringen till molnet genom att köra följande PowerShell-cmdletar i EMS:

          Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

          Kontrollera att värdet ImmutableId har uppdaterats genom att köra följande PowerShell-cmdlet i Exchange Online PowerShell:

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

        3. ImmutableId Återställ fjärrpostlådeobjektets objekt till null genom att köra följande PowerShell-cmdlet i EMS:

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

        4. Synkronisera ändringen till molnet genom att köra följande PowerShell-cmdlet i EMS:

          Start-ADSyncSyncCycle -PolicyType Delta

          Kontrollera att värdet ImmutableId har uppdaterats. Det gör du genom att köra följande PowerShell-cmdlet i Exchange Online PowerShell:

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

      • ImmutableId-värdet är inte null

        Om värdet ImmutableId inte är null kör du följande kommando i EMS för att ange ImmutableId värdet till null:

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

        Kontrollera att värdet ImmutableId har uppdaterats genom att köra följande PowerShell-cmdlet i Exchange Online PowerShell:

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

  4. Kontrollera inställningarna för organisationsrelationen. Mer information finns i Avmystifiera hybridfri/upptagen.

  5. Om felmeddelandet genereras för en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare följer du dessa steg:

    1. Kör följande cmdlet i PowerShell:

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

    2. Återskapa federationsförtroendet. Mer information finns i Ta bort ett federationsförtroende och Konfigurera ett federationsförtroende.

Tillbaka till början

Resultatuppsättningen innehåller för många kalenderposter

LOCK: 54796

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en annan molnanvändare. När du diagnostiserar problemet visas följande felmeddelande:

Undantag: Resultatuppsättningen innehåller för många kalenderposter. Tillåten storlek = 1000; den faktiska storleken = 5009.

Det här felet uppstår om antalet kalenderposter i en enda tidsslot överskrider 1 000 objekt. En enskild ledig/upptagen-begäran kan inte hämta fler än 1 000 objekt.

Åtgärd

Ta bort några av kalenderobjekten från tidsintervallet för att inte överskrida gränsen på 1 000 objekt som kan hämtas i en enda ledig/upptagen-begäran.

Mer information finns i Du kan inte visa ledig/upptagen-information i en annan användares kalender i Exchange Online.

Tillbaka till början

Arbetstidens starttid måste vara mindre än eller lika med sluttiden

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en rumslista. När du diagnostiserar problemet visas följande felmeddelande:

Undantag: Microsoft.Exchange.InfoWorker.Common.InvalidParameterException: Arbetstidens starttid måste vara mindre än eller lika med sluttiden.
Microsoft.Exchange.InfoWorker.Common.MeetingSuggestions.AttendeeWorkHours.Validate(TimeSpan startTime, TimeSpan endTime).

Det här felet kan inträffa om en eller flera av följande kalenderinställningar för en rumspostlåda i en rumslista är ogiltiga:

  • WorkingHoursStartTime
  • WorkingHoursEndTime
  • WorkingHoursTimeZone

Arbetstidens starttid måste vara mindre än eller lika med arbetstidens sluttid och arbetstidens tidszon måste anges.

Lösning

Du löser problemet genom att följa dessa steg:

  1. Kör följande PowerShell-cmdlet för att kontrollera kalenderinställningarna för varje postlåda i rumslistan för att identifiera den rumspostlåda som har ogiltiga inställningar:

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

  2. Kör följande PowerShell-cmdlet för att ange de obligatoriska parametervärdena för en rumspostlåda:

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

    Mer information finns i Set-MailboxCalendarConfiguration.

Tillbaka till början

Begäran misslyckades med HTTP-status 401: Obehörig (token har en ogiltig signatur)

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

System.Net.WebException: Begäran misslyckades med HTTP-status 401: Obehörig.

När du kör följande PowerShell-cmdlet för att testa OAuth-autentisering:

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

Du får följande kommandoutdata:

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".

Obs! Parametervärdet TargetUri i kommandot Test-OAuthConnectivity är en extern URL för Exchange Web Services (EWS), till exempel https://mail.contoso.com/ews/exchange.asmx.

Det här felet kan inträffa om inställningarna för Microsoft-auktoriseringsservern är ogiltiga.

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Uppdatera auktoriseringsmetadata på den angivna Microsoft-auktoriseringsservern som är betrodd av Exchange. Kör följande PowerShell-cmdlet i EMS (lokalt):

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

    Vänta ungefär 15 minuter tills kommandot börjar gälla helt eller starta om IIS genom att köra iisreset /noforce kommandot i ett PowerShell- eller kommandotolkfönster på varje Exchange Server.

  2. Kontrollera inställningarna för Microsoft-auktoriseringsservern i Exchange-organisationen genom att köra följande PowerShell-cmdlet i EMS:

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

    Följande kommandoutdata är ett exempel på giltiga inställningar:

    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

    Om inställningarna för Microsoft-auktoriseringsservern inte är giltiga kan du prova att köra guiden Hybridkonfiguration igen för att återställa inställningarna för Microsoft-auktoriseringsservern till giltiga värden.

Tillbaka till början

Begäran misslyckades med HTTP-status 401: Obehörig (nyckeln hittades inte)

Fråga

Du har en lokal användare som inte kan visa ledig/upptagen-information för en molnanvändare. När du diagnostiserar problemet visas följande felmeddelande:

System.Net.WebException: Begäran misslyckades med HTTP-status 401: Obehörig.

När du kör följande PowerShell-cmdlet i EMS för att testa OAuth-autentisering:

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

Du får följande kommandoutdata:

System.Net.WebException: Fjärrservern returnerade ett fel: (401) Obehörig.
Fel: Det gick inte att hämta token från autentiseringsservern. Felkod: "invalid_client". Beskrivning: "AADSTS70002:
Det gick inte att verifiera autentiseringsuppgifterna. AADSTS50012: Klientkontroll innehåller en ogiltig signatur. [Orsak – Nyckeln hittades inte., Tumavtryck för nyckeln som används av klienten: "<tumavtryck>".

Det här felet kan inträffa om OAuth-certifikatet i Exchange Server inte finns i Exchange Online.

Åtgärd

Åtgärda problemet med hjälp av följande steg:

  1. Kontrollera om ditt lokala Exchange Server OAuth-certifikat finns i Exchange Online-organisationen:

    1. Kör följande PowerShell-cmdlet i Exchange Management Shell (EMS) för att hämta OAuth-certifikatet i Exchange Server:

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

      Kommandots utdata innehåller värdet Thumbprint .

    2. Kör följande PowerShell-cmdletar för att hämta Exchange Online OAuth-certifikatet med hjälp av MSOL-tjänsten:

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

      Value Om parametervärdet i kommandoutdata är tomt finns inget OAuth-certifikat i Exchange Online. I så fall går du till steg 3 för att ladda upp det lokala certifikatet till Exchange Online.

      Value Om parametervärdet inte är tomt sparar du värdet i en fil som har tillägget ".cer". Öppna filen i Microsoft Certificate Manager-verktyget för att visa OAuth-certifikatet för Exchange Online. Thumbprint Jämför värdet i Exchange Online-certifikatet med tumavtrycket för det lokala certifikatet som du fick i steg 1a. Om tumavtrycksvärdena matchar går du till steg 4. Om tumavtrycksvärdena inte matchar väljer du något av följande alternativ:

      • Gå till steg 2 för att ersätta det befintliga lokala certifikatet med Exchange Online-certifikatet.

      • Gå till steg 3 för att ersätta det befintliga Exchange Online-certifikatet med det lokala certifikatet.

  2. Ersätt det befintliga lokala certifikatet med Exchange Online-certifikatet:

    1. Kör följande PowerShell-cmdlet för att uppdatera det lokala certifikatets tumavtryck:

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

      Om du får ett meddelande om att certifikatets giltighetsdatum är mindre än 48 timmar från och med nu godkänner du uppmaningen att fortsätta.

    2. Kör följande PowerShell-cmdlet för att publicera det lokala certifikatet:

      Set-AuthConfig -PublishCertificate  

    3. Kör följande PowerShell-cmdlet för att ta bort referenser till det tidigare certifikatet:

      Set-AuthConfig -ClearPreviousCertificate 

    4. Gå till steg 4.

  3. Exportera det lokala auktoriseringscertifikatet och ladda sedan upp certifikatet till Exchange Online-organisationen.

  4. Kör följande PowerShell-cmdlet för att kontrollera om SPN i den lokala autentiseringskonfigurationen är 00000002-0000-0ff1-ce00-000000000000:

    Get-AuthConfig | FL ServiceName

    Om SPN-värdet är annorlunda uppdaterar du SPN genom att köra följande PowerShell-cmdlet:

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

Tillbaka till början

Proxywebbbegäran misslyckades: Svaret är inte välformulerad XML

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Proxywebbbegäran misslyckades., inre undantag: Svaret är inte välformulerad XML

Om du kör testet Synkronisering, Meddelande, Tillgänglighet och Automatiska svar för den lokala användaren visas följande felmeddelande:

Svaret som togs emot från tjänsten innehöll inte giltig XML

Dessa fel kan inträffa av någon av följande orsaker:

  • Problem med externa Exchange Web Services (EWS)
  • Felkonfiguration av nätverksenheter, till exempel en omvänd proxy eller brandvägg

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Kontrollera om en ledig/upptagen-begäran från Exchange Online kan nå IIS på en Exchange-server. Utför en ledig/upptagen-fråga och sök sedan i IIS-loggarna efter poster som har HTTP-statuskod 200 OK eller 401 Unauthorized vid tidpunkten för frågan. Dessa poster anger att den lediga/upptagna begäran nådde IIS. Obs! Tidsstämplar i IIS-loggar använder UTC-tid.

    Om du inte hittar dessa poster kontrollerar du den omvända proxyn och brandväggsloggarna för att avgöra var den lediga/upptagna begäran fastnade.

  2. Utför en ledig/upptagen-fråga och sök sedan i Exchange Server-programloggen i Windows Loggboken efter poster som gjordes vid tidpunkten för frågan för att begränsa orsaken till problemet.

Tillbaka till början

Det går inte att ansluta till fjärrservern

Fråga

Du har en lokal användare som inte kan visa ledig/upptagen-information för en molnanvändare. När du diagnostiserar problemet visas följande felmeddelande:

Det gick inte att kommunicera med https://login.microsoftonline.com/extSTS.srf., inre undantag: Det går inte att ansluta till fjärrservern.

Det här felet kan inträffa om en eller flera Exchange-servrar inte kan ansluta till en URL för Microsoft Federation Gateway.

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Kör följande PowerShell-cmdletar i Exchange Management Shell (EMS) för att kontrollera om du kan hämta en delegeringstoken:

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

  2. Kontrollera att dina lokala Exchange-servrar har utgående Internetåtkomst till båda följande resurser:

    • Microsoft Federation Gateway eller Microsoft-auktoriseringsservern om du använder OAuth-autentisering.

    • Tillgänglighets-URL:en för Microsoft 365: https://outlook.office365.com/ews/exchange.asmx.

    Mer information finns i Url:er och IP-adressintervall för Microsoft 365 och Brandväggsöverväganden för federerad delegering.

  3. Kontrollera att systemkontot i Exchange Server har Internetåtkomst till följande URL:er. Följ dessa steg på alla Exchange-servrar i din organisation:

    1. Kör följande PsExec-kommando för att starta en PowerShell-session som startar en webbläsare från systemkontot:

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

    2. Testa webbläsaråtkomst (ingen OAuth-autentisering) från systemkontot till följande URL:er för Microsoft Federation Gateway:

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

        Webbläsaren bör visa en XML-sida.

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

        Webbläsaren bör uppmana dig att ladda ned filen.

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

        Webbläsaren bör visa en lista över åtgärder som stöds av ManageDelegation2.

    3. Testa webbläsaråtkomst (OAuth-autentisering) från systemkontot till följande URL:er för Microsoft-auktoriseringsservern:

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

        Webbläsaren bör visa en inloggningsprompt.

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

        Webbläsaren bör visa felmeddelandet "Tyvärr, men vi har problem med att logga in dig".

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

        Webbläsaren bör visa HTTP-statuskoden 400 Bad Request eller inloggningsfelmeddelandet "Tyvärr, men vi har problem med att logga in dig".

Tillbaka till början

Automatisk upptäckt misslyckades för e-postadress: Fjärrnamnet kunde inte matchas

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Automatisk upptäckt misslyckades för e-postadressanvändarens <e-postadress> med felet System.Net.WebException: Fjärrnamnet kunde inte matchas: "<Lokalt värdnamn>".

Det här felet kan inträffa om den lokala slutpunkts-URL:en för automatisk upptäckt eller de offentliga DNS-inställningarna är felaktiga.

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Kör följande PowerShell-cmdletar i Exchange Online PowerShell för att hämta värdet för parametern TargetAutodiscoverEpr :

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

    Om värdet för det lokala värdnamnet i felmeddelandet till exempel är mail.contoso.comär url:en för https://autodiscover.contoso.com/autodiscover/autodiscover.svcautomatisk upptäcktsslutpunkt sannolikt .

    TargetAutodiscoverEpr Om parametervärdet är korrekt går du till steg 3. Annars går du till steg 2.

  2. Uppdatera URL:en för slutpunkten för automatisk upptäckt med någon av följande metoder:

    • Kör hybridkonfigurationsguiden (HCW) för att återställa standardslutpunkten för automatisk upptäckt.

    • Uppdatera antingen parametern DiscoveryEndpoint eller parametern TargetAutodiscoverEpr manuellt genom att köra någon av följande PowerShell-cmdletar:

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

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

  3. Kontrollera att det lokala värdnamnet i felmeddelandet (till exempel : mail.contoso.com) kan matchas i offentlig DNS. DNS-posten för värdnamnet ska peka på den lokala tjänsten för automatisk upptäckt på slutpunktens URL för automatisk upptäckt.

    Obs! Om du inte kan åtgärda problemet och du vill ha en tillfällig lösning kör du någon av följande PowerShell-cmdletar för att manuellt uppdatera TargetSharingEpr parametervärdet till url:en för externa Exchange Web Services (EWS). Den externa EWS-URL:en bör likna https://<EWS hostname>/ews/exchange.asmx och kunna matchas i DNS.

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

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

    Obs!

    Om du anger TargetSharingEpr parametervärdet kringgår molnpostlådan automatisk upptäckt och ansluter direkt till EWS-slutpunkten.

Tillbaka till början

Det gick inte att hämta ASURL. Fel 8004010F

Fråga

Du har en lokal användare som inte kan visa ledig/upptagen-information för en molnanvändare. När du diagnostiserar problemet visas följande felmeddelande:

Det gick inte att hämta ASURL. Fel 8004010F.

Det här är ett allmänt fel som är relaterat till tjänsten Automatisk upptäckt.

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Kontrollera att Automatisk upptäckt för den berörda användaren returnerar ANVÄNDARENs URL för Exchange Web Services (EWS).

  2. Kör autokonfigurationstestet för e-post i den berörda användarens Outlook-klient för att se till att Automatisk upptäckt returnerar EWS-URL:en för användaren.

  3. Kontrollera att ledig/upptagen fungerar mellan lokala användare som finns på olika Exchange-servrar.

  4. Om du har lastbalanserare kontrollerar du om lastbalanserarna orsakade problemet. Det gör du genom att ändra Windows Hosts-filen (på den dator där användarens Outlook-klient är installerad) för att kringgå lastbalanserarna och peka på en specifik klientåtkomstserver.

  5. Om ledig/upptagen fungerar mellan lokala användare kontrollerar du om alla lokala Exchange-servrar har utgående åtkomst till Url:er och IP-adressintervall för Microsoft 365.

  6. Kontrollera om varje Exchange-server kan hämta en delegeringstoken. Det gör du genom att köra följande PowerShell-cmdlet i EMS på alla lokala Exchange-servrar:

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

    Om kommandot inte kan hämta en delegeringstoken kontrollerar du om servern kan ansluta till Office 365 på proxy- eller brandväggsnivå.

Tillbaka till början

Proxywebbbegäran misslyckades: Objektet flyttades

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Proxywebbbegäran misslyckades. , inre undantag: System.Net.WebException: Begäran misslyckades med felmeddelandet: Objektet flyttades.

Det här felet kan inträffa om TargetSharingEpr parametervärdet i organisationsinställningarna är inställt på en felaktig SLUTpunkts-URL för Exchange Web Services (EWS).

Du kan köra följande PowerShell-cmdletar för att hämta TargetSharingEpr parametervärdet från organisationsinställningarna (anslutningsapp inom organisationen eller organisationsrelation):

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

Kontrollera att TargetSharingEpr parametervärdet inte matchas i offentlig DNS.

Obs! Hybridkonfigurationsguiden (HCW) anger inget värde för parametern TargetSharingEpr om du inte väljer Använd Exchange Modern Hybrid Technology för att installera en hybridagent. I det scenariot anger HCW -parametern TargetSharingEpr till ett externt slutpunktsvärde https://<GUID>.resource.mailboxmigration.his.msappproxy.net/ews/exchange.asmxför EWS-URL:en som liknar . Du kan också ange TargetSharingEpr parametervärdet manuellt. Om värdet är inställt på TargetSharingEpr en slutpunkt kringgår Outlook automatisk upptäckt och ansluter direkt till slutpunkten.

Åtgärd

Åtgärda problemet genom att köra något av följande kommandon för att manuellt uppdatera TargetSharingEpr parametervärdet till en extern EWS-URL som löses i DNS:

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

Tillbaka till början

Begäran avbröts: Det gick inte att skapa en säker SSL/TLS-kanal

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare eller vice versa. När du diagnostiserar problemet visas följande felmeddelande:

Begäran avbröts: Det gick inte att skapa en säker SSL/TLS-kanal.

Orsak 1: Molnanvändare kan inte visa ledig/upptagen-information för en lokal användare

Problemet kan uppstå om TLS 1.2 är felkonfigurerat eller inaktiverat i en lokal slutpunkt som Microsoft 365 ansluter till, till exempel Exchange Server eller en brandvägg.

Orsak 2: Lokal användare kan inte visa ledig/upptagen-information för en molnanvändare

Problemet kan också inträffa av någon av följande orsaker:

Felsökningssteg

Använd följande verktyg för att diagnostisera lokala TLS 1.2-problem:

Information om TLS-konfiguration finns i Metodtips för Exchange Server TLS-konfiguration och Förbereda för TLS 1.2.

Information om hur du söker efter certifikat i det betrodda rotcertifikatutfärdararkivet finns i Visa certifikat med MMC-snapin-modulen.

Information om TLS-chiffersviter som stöds finns i TLS-chiffersviter som stöds av Microsoft 365.

Tillbaka till början

Användaren som anges av användarkontexten i token finns inte

Fråga

Du har en lokal användare som inte kan visa ledig/upptagen-information för en molnanvändare. När du diagnostiserar problemet visas följande felmeddelande:

Användaren som anges av användarkontexten i token finns inte. error_category="invalid_user". 401: Obehörig.

Du får samma felmeddelande om du kör PowerShell-cmdleten Test-OAuthConnectivity .

Felet kan inträffa om den lokala användarpostlådan och motsvarande e-postanvändarobjekt i Microsoft Entra-ID inte synkroniseras. Tills de har synkroniserats kan e-postanvändarobjektet i Microsoft Entra-ID vara oetablerat.

Åtgärd

Åtgärda problemet genom att använda Microsoft Entra Connect för att synkronisera den lokala användaren och motsvarande e-postanvändarobjekt i Microsoft Entra-ID.

Tillbaka till början

Värdnamnskomponenten i målgruppens anspråksvärde är ogiltig

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Värdnamnskomponenten i målgruppens anspråksvärde "https://< hybrid.domain.com>" är ogiltig; error_category="invalid_resource"

Felet kan inträffa av någon av följande orsaker.

Orsak 1

Både SSL-avlastning och OAuth-autentisering är aktiverade. SSL-avlastning fungerar inte om OAuth-autentisering är aktiverat.

Orsak 2

En nätverksenhet framför Exchange Server blockerar ledig/upptagen-begäranden.

Lösning

Lösning för orsak 1

Välj någon av följande lösningar:

  • Inaktivera SSL-avlastning för både Exchange Web Services (EWS) och Automatisk upptäckt i den lokala miljön. Mer information finns i Konfigurera SSL-avlastning för automatisk upptäckt och konfigurera SSL-avlastning för EWS och standardinställningar för SSL.

  • Kör följande PowerShell-cmdlet för att inaktivera OAuth-autentisering genom att inaktivera molnanslutningsappen inom organisationen:

    Set-IntraOrganizationConnector "HybridIOC*" -Enabled $false

    När anslutningsappen inom organisationen är inaktiverad aktiveras DAuth-autentisering via organisationsrelationen. Kontrollera organisationsrelationen genom att köra följande PowerShell-cmdlet:

    Get-OrganizationRelationship

    Mer information om inställningarna för organisationsrelationer finns i Avmystifiera Hybrid Ledig/Upptagen.

Lösning för orsak 2

Konfigurera nätverksenheten framför Exchange för att inte blockera ledig/upptagen-begäranden.

Tillbaka till början

Proxywebbbegäran misslyckades med HTTP-status 503: Tjänsten är inte tillgänglig

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Proxywebbbegäran misslyckades, inre undantag: System.Net.WebException: Begäran misslyckades med HTTP-status 503: Tjänsten är inte tillgänglig...

Det här felet kan inträffa om det finns en stoppad Microsoft Windows-tjänst, serverkomponent, IIS-programpool eller en felkonfigurerad slutpunkt.

Felsökningssteg

När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. Kontrollera att De Windows-tjänster som Exchange Server kräver körs. Kontrollera statusen för tjänsterna genom att köra följande PowerShell-cmdlet på varje Exchange-server i din organisation:

    Test-ServiceHealth

    Använd tjänstkonsolen för att starta alla stoppade tjänster som krävs av Exchange Server.

  2. Kontrollera att nödvändiga Exchange Server-komponenter är aktiva. Kontrollera status för komponenter genom att köra följande PowerShell-cmdlet på varje Exchange-server i din organisation:

    Get-ServerComponentState <server name>

    Om du vill aktivera en inaktiv komponent använder du PowerShell-cmdleten Set-ServerComponentState .

  3. Kontrollera att följande IIS-programpooler för Exchange Web Services (EWS) och Automatisk upptäckt har startats:

    • MSExchangeServicesAppPool
    • MSExchangeSyncAppPool
    • MSExchangeAutodiscoverAppPool

  4. Testa om slutpunkten för automatisk upptäckt är giltig. Gör så här:

    1. Kör följande PowerShell-cmdletar för att hämta url:en för slutpunkten för automatisk upptäckt från parametervärdena DiscoveryEndpoint eller TargetAutodiscoverEpr :

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

    2. Gå till URL:en för automatisk upptäckt av slutpunkt i en webbläsare eller kör PowerShell-cmdleten Invoke-WebRequest -Uri "<endpoint URL>" -Verbose för att kontrollera att URL:en är giltig. Kontrollera helst URL:en från ett externt nätverk.

  5. Testa om EWS-URL:en är giltig genom att följa dessa steg:

    1. Kör följande PowerShell-cmdletar för att hämta EWS-URL:en från TargetSharingEpr parametervärdet i organisationsinställningarna:

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

    b. Gå till EWS-URL:en i en webbläsare eller kör PowerShell-cmdleten Invoke-WebRequest -Uri "<endpoint URL>" -Verbose för att kontrollera att URL:en är giltig. Kontrollera helst URL:en från ett externt nätverk.

  6. Kontrollera IIS-loggarna för ledig/upptagen-begäranden som returnerar HTTP-statuskod 503 Service Unavailable:

    1. Skicka en ledig/upptagen-begäran från Exchange Online.

    2. Sök efter HTTP-statuskodposter 503 Service Unavailable i IIS-loggarna i W3SVC1-mappen för standardwebbplatsen på varje Exchange-server. W3SVC1-mappsökvägen är %SystemDrive%\inetpub\logs\LogFiles\W3SVC1. Dessa poster kan hjälpa dig att identifiera den server som har problemet.

    3. Om den lediga/upptagna begäran inte är inloggad i mappen W3SVC1 kontrollerar du om begäran loggas i felloggarna i HTTPERR-mappen på varje Exchange-server. HTTPERR-mappsökvägen är %SystemRoot%\System32\LogFiles\HTTPERR. Om den lediga/upptagna begäran loggas i HTTPERR-loggarna kontrollerar du om det finns felkonfigurerade IIS-inställningar.

  7. Kontrollera huvudet för serversvaret som du får när du ansluter till den lokala EWS-URL:en för att kontrollera att IIS (inte en annan webbserver) skickade svaret. Det gör du genom att köra följande kommandon i en PowerShell-session som inte är ansluten till lokal EWS (kör inte kommandona i Exchange Management Shell):

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

    Om du till exempel ser "Microsoft-HTTPAPI/2.0" i kommandoutdata i stället för "Microsoft -IIS/10.0" är det troligt att en WAP-tjänst (Web Application Proxy) (inte IIS) svarade på begäran. Kontrollera om WAP-tjänsten är nere.

Tillbaka till början

Proxywebbbegäran misslyckades med HTTP-status 504: Tidsgräns för gateway

LOCK: 43532

Fråga

Du har en molnanvändare som inte kan visa ledig/upptagen-information för en lokal användare. När du diagnostiserar problemet visas följande felmeddelande:

Proxywebbbegäran misslyckades, inre undantag: Begäran misslyckades med HTTP-status 504: Gateway-timeout...

Det här felet kan inträffa om en hybridagent i din organisation har konfigurerats felaktigt.

Åtgärd

Åtgärda problemet genom att följa stegen nedan. När du har slutfört varje steg kontrollerar du om problemet med ledig/upptagen har åtgärdats.

  1. TargetSharingEpr Kontrollera parametervärdet i organisationsinställningarna. Värdet bör likna https://<GUID>.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx. Kör följande PowerShell-cmdletar för att fastställa värdet för parametern TargetSharingEpr :

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

    TargetSharingEpr Om parametervärdet är felaktigt:

    1. Kör guiden Hybridkonfiguration (HCW) och välj Använd klassisk Exchange-hybridtopologi.

    2. Kör HCW igen och välj Använd exchange modern hybridtopologi. Den här proceduren tvingar HCW att återställa TargetSharingEpr parametervärdet.

  2. Kontrollera status för Microsoft Hybrid Service på den server där hybridagenten är installerad. Om tjänsten stoppas startar du den.

  3. Kontrollera hybridagentens status. Om statusen är Inaktiv:

    1. Kör guiden Hybridkonfiguration (HCW) och välj Använd klassisk Exchange-hybridtopologi.

    2. Kör HCW igen och välj Använd exchange modern hybridtopologi. Den här proceduren tvingar HCW att installera om hybridagenten.

    3. Installera PowerShell-modulen Hybrid Agent och kör sedan PowerShell-cmdleten Get-HybridApplication för att hitta den interna URL som hybridagenten pekar på.

  4. Bläddra till den interna URL som du hittade i steg 3. Lös eventuella fel som du hittar, till exempel certifikatfel.

  5. Konfigurera hybridagenten för att dirigera begäranden till en lastbalanserare i stället för en server som kör Microsoft Exchange Server för att utesluta problem som kan finnas på servern.

  6. Kontrollera att hybridagenten stöder ledig/upptagen-begäranden och postlådemigrering.

Tillbaka till början