Beheben von Frei/Gebucht-Fehlern

Um einen Fehler zu beheben, der sich auf Frei/Gebucht-Informationen bezieht, wählen Sie die entsprechende Fehlermeldung aus dem Inhaltsverzeichnis (ToC) am Anfang dieses Artikels aus.

Wenn die Schritte zur Problembehandlung ihnen nicht helfen, das Problem zu beheben, wenden Sie sich an den Microsoft-Support.

Fehler beim Überprüfen der Sicherheit für die Nachricht

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Fehler bei der AutoErmittlung für die SMTP-Adresse> der E-Mail-Adresse <mit Dem Fehler System.Web.Services.Protocols.SoapHeaderException: Fehler beim Überprüfen der Sicherheit für die Nachricht bei System.Web. Services.Protocols. SoapHttpClientProtocol. ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

Dieser Fehler kann auftreten, wenn die WSSecurity-Authentifizierung nicht aktiviert ist oder zurückgesetzt werden muss oder nachdem Sie Verbundzertifikate in Exchange Server erneuert haben.

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Um Metadaten im Microsoft-Verbundgateway zu aktualisieren, führen Sie den folgenden Befehl zweimal in der lokalen Exchange-Verwaltungsshell (EMS) aus:

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Weitere Informationen finden Sie unter Frei/Gebucht-Suche funktioniert nicht mehr in einer standortübergreifenden Umgebung oder in einer Exchange Server-Hybridbereitstellung.

2. Führen Sie die folgenden Schritte aus, um die WSSecurity-Authentifizierung umzuschalten:

   1. Befolgen Sie das Verfahren unter Benutzer aus einer Verbundorganisation können die Frei/Gebucht-Informationen einer anderen Exchange-Organisation nicht sehen , um die WSSecurity-Authentifizierung sowohl in der AutoErmittlung als auch in den virtuellen EWS-Verzeichnissen auf allen lokalen Exchange-Servern zu aktivieren oder zurückzusetzen, falls sie bereits aktiviert ist.

      Hinweise

      • Führen Sie diesen Schritt auch dann aus, wenn die Ausgabe der PowerShell-Cmdlets Get-AutodiscoverVirtualDirectory angibt Get-WebServicesVirtualDirectory , dass die WSSecurity-Authentifizierung bereits aktiviert ist.

      • Die Prozedur wirkt sich nur auf standortübergreifende Frei/Gebucht-Vorgänge und nicht auf andere Client-Server-Verbindungen aus.

   2. Führen Sie den iisreset /noforce Befehl in einem PowerShell- oder Eingabeaufforderungsfenster auf jedem lokalen Exchange-Server aus, um IIS neu zu starten.

   3. Starten Sie alle lokalen Exchange-Server neu.

3. Überprüfen Sie, ob Warnungen oder Fehler mit Zeitschiefe im Systemereignisprotokoll vorliegen, und beheben Sie sie.

4. Legen Sie den TargetSharingEpr Parameterwert in der Organisationsbeziehung auf die lokale url der externen Exchange-Webdienste (EWS) fest, indem Sie das folgende Cmdlet in Exchange Online PowerShell ausführen:

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

   Nachdem Sie den TargetSharingEpr Parameterwert festgelegt haben, umgeht das Cloudpostfach die AutoErmittlung und stellt eine direkte Verbindung mit dem EWS-Endpunkt des lokalen Postfachs her.

   Hinweis: Der Standardwert des TargetSharingEpr Parameters ist leer. Die AutoErmittlungsparameter TargetAutodiscoverEpr oder DiscoveryEndpoint enthalten in der Regel die lokale externe EWS-URL (AutoErmittlungsendpunkt). Führen Sie die folgenden PowerShell-Cmdlets aus, um die TargetAutodiscoverEpr Parameterwerte und DiscoveryEndpoint abzurufen:

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

5. Stellen Sie sicher, dass der TargetApplicationUri Parameterwert in der Organisationsbeziehung mit dem AccountNamespace Parameterwert im Bezeichner der Verbundorganisation übereinstimmt. Um den TargetApplicationUri Parameterwert zu ermitteln, führen Sie das PowerShell-Cmdlet Test-OrganizationRelationship aus. Informationen zum Ermitteln des AccountNamespace Parameterwerts finden Sie unter Entmystifizieren von Hybrid-Frei/Gebucht-Umgebungen.

Zurück zum Anfang

Fehler bei der Proxywebanforderung: Verbindung mit dem Remoteserver kann nicht hergestellt werden

Problem

Sie verfügen über Einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann oder umgekehrt. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Fehler bei der Proxywebanforderung. , innere Ausnahme: System.Net.WebException: Verbindung mit dem Remoteserver kann nicht hergestellt werden; System.Net.Sockets.SocketException: Ein Verbindungsversuch ist fehlgeschlagen, weil die verbundene Partei nach einem bestimmten Zeitraum nicht ordnungsgemäß reagiert hat, oder die hergestellte Verbindung ist fehlgeschlagen, weil der verbundene Host nicht CUSTOMER_IP:443 / MICROSOFT_IP:443 bei System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult asyncResult)

Dieser Fehler kann auftreten, wenn Netzwerkkonnektivitätsprobleme eingehende oder ausgehende Verbindungen zwischen IP-Adressen in Exchange Online und Endpunkten in Exchange Server verhindern.

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Stellen Sie sicher, dass die Firewall auf jedem lokalen Exchange-Server eingehende oder ausgehende Verbindungen zwischen Exchange Server-Endpunkten und Exchange Online-IP-Adressen zulässt. Um Firewallprobleme zu identifizieren, stellen Sie eine Frei/Gebucht-Anforderung von Exchange Online, und überprüfen Sie dann die lokale Firewall, den Reverseproxy und die Netzwerkprotokolle. Weitere Informationen zum Konfigurieren einer Firewall finden Sie unter Firewallüberlegungen für die Verbunddelegierung und Microsoft 365-URLs und IP-Adressbereiche.

2. Stellen Sie sicher, dass Anforderungen von Exchange Online die lokalen Clientzugriffsserver erreichen. Führen Sie die folgenden Schritte auf allen lokalen Clientzugriffsservern aus:

   1. Stellen Sie eine Frei/Gebucht-Anforderung von Exchange Online.

   2. Überprüfen Sie die IIS-Protokolle im Ordner W3SVC1 auf die Standardwebsite, um zu überprüfen, ob die Frei/Gebucht-Anforderung protokolliert wird. Der W3SVC1-Ordnerpfad ist %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

   3. Überprüfen Sie die HTTP-Proxyprotokolle in den folgenden Ordnern, um sicherzustellen, dass die Frei/Gebucht-Anforderung protokolliert wird:

      • %ExchangeInstallPath%\Logging\HttpProxy\AutoDiscover

      • %ExchangeInstallPath%\Logging\HttpProxy\Ews

3. Testen Sie die Konnektivität zwischen Exchange Online und dem lokalen EWS-Endpunkt (Exchange Web Services), indem Sie das folgende Cmdlet in Exchange Online PowerShell ausführen:

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

   Hinweise

   • Dieser Test ist nützlich, wenn Sie eingehende Verbindungen aus dem Internet so einschränken, dass nur Exchange Online-IP-Adressen eine Verbindung mit Ihrem lokalen EWS-Endpunkt herstellen können.

   • Wenn nur wenige Cloudbenutzer von diesem Problem betroffen sind und ihre Postfächer auf demselben E-Mail-Server in Exchange Online gehostet werden, überprüfen Sie, ob dieser E-Mail-Server eine Verbindung mit lokalen Endpunkten herstellen kann. Es ist möglich, dass ein lokaler Endpunkt Verbindungen von der ausgehenden externen IP-Adresse dieses E-Mail-Servers blockiert.

   • Wenn Sie zur Eingabe von Anmeldeinformationen aufgefordert werden, geben Sie Ihre Domänenadministratoranmeldeinformationen im Format "Domäne\Administrator" ein.

Zurück zum Anfang

Fehler bei der AutoErmittlung für E-Mail-Adresse: HTTP-Status 404

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Fehler bei der AutoErmittlung für die SMTP-Adresse des E-Mail-Adressbenutzers <> mit Dem Fehler System.Net.WebException: Fehler bei der Anforderung mit HTTP-Statuscode 404 Not Found.

Dieser Fehler kann auftreten, wenn AutoErmittlungsendpunkte nicht funktionsfähig oder falsch konfiguriert sind.

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Überprüfen Sie, ob der AutoErmittlungsendpunkt gültig ist:

   1. Führen Sie die folgenden Befehle aus, um die Url des AutoErmittlungsendpunkts aus dem DiscoveryEndpoint Parameter oder TargetAutodiscoverEpr abzurufen:

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

   2. Navigieren Sie in einem Webbrowser zur Url des AutoErmittlungsendpunkts. Ein gültiger AutoErmittlungsendpunkt gibt keinen HTTP-Statuscode 404 Not Foundzurück.

2. Stellen Sie sicher, dass die Domäne des lokalen Benutzers in den Organisationseinstellungen (organisationsinterner Connector oder Organisationsbeziehung) des Cloudbenutzers angegeben ist:

   1. Führen Sie die folgenden PowerShell-Cmdlets in Exchange Online PowerShell aus:

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

      Vergewissern Sie sich, dass die Domäne des lokalen Benutzers in der Ausgabe eines der beiden Befehle aufgeführt ist. Wenn ein Cloudbenutzer user1@contoso.com beispielsweise die Frei/Gebucht-Option für den lokalen Benutzer user2@contoso.rosucht, überprüfen Sie, ob die lokale Domäne contoso.ro aufgeführt ist.

   2. Wenn die Domäne des lokalen Benutzers in den Organisationseinstellungen des Cloudbenutzers nicht vorhanden ist, fügen Sie die Domäne hinzu, indem Sie das folgende PowerShell-Cmdlet ausführen:

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

3. Stellen Sie sicher, dass die SVC-Handlerzuordnung sowohl im virtuellen AutoErmittlungsverzeichnis als auch im virtuellen EWS-Verzeichnis unter Standardwebsite im IIS-Manager vorhanden ist. Weitere Informationen finden Sie unter FederationInformation konnte nicht empfangen werden , und Vom Ziel wurde eine Ausnahme ausgelöst.

   Hinweis: Die AutodiscoverDiscoveryHander Zuordnung (*.svc) wird nicht für die Frei/Gebucht-Suche des Verbunds verwendet.

Zurück zum Anfang

Fehler bei der Webanforderung des Ausnahmeproxys

LID: 43532

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Fehler bei der Webanforderung des Ausnahmeproxys. , innere Ausnahme: Fehler bei der Anforderung mit HTTP-Status 401: Nicht autorisierte Diagnose: 2000005; reason= "Der durch den Benutzerkontext im Token angegebene Benutzer ist mehrdeutig." ; error_category="invalid_user"

Dieser Fehler kann auftreten, wenn der UPN, die SMTP-Adresse oder die SIP-Adresse des lokalen Benutzers von einem anderen lokalen Postfach verwendet wird.

Lösung

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

1. Suchen Sie mithilfe von benutzerdefinierten LDAP-Abfragen nach lokalen Benutzerobjekten, die über einen doppelten UPN, eine SMTP-Adresse oder eine SIP-Adresse verfügen. Sie können LDAP-Abfragen mithilfe von LDP.exe oder dem MMC-Snap-In Active Directory-Benutzer und -Computer ausführen.

   Verwenden Sie beispielsweise die folgende LDAP-Abfrage, um alle Benutzer user@corp.contoso.com anzuzeigen, die über den UPN, user@contoso.com als SMTP-Adresse oder user@contoso.com als SIP-Adresse verfügen:

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

   Weitere Informationen zur Verwendung von LDP.exe oder Active Directory-Benutzern und -Computern zum Suchen von Active Directory-Objekten finden Sie unter LDP-Beispiele.

2. Ändern Sie die doppelte Adresse, oder löschen Sie das doppelte Benutzerobjekt.

Zurück zum Anfang

Schließung einer bestehenden Verbindung wurde vom Remotehost erzwungen

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Fehler bei der Proxywebanforderung. , innere Ausnahme: System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Bei einem Empfang ist ein unerwarteter Fehler aufgetreten. System.IO.IOException: Daten aus der Transportverbindung können nicht gelesen werden: Eine vorhandene Verbindung wurde vom Remotehost erzwungen geschlossen. System.Net.Sockets.SocketException: Eine vorhandene Verbindung wurde vom Remotehost erzwungen geschlossen.

Dieser Fehler kann auftreten, wenn eine lokale Firewall eine eingehende Verbindung von einer externen ausgehenden IP-Adresse in Exchange Online blockiert.

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Überprüfen Sie, ob Frei/Gebucht-Anforderungen von Exchange Online IIS auf einem Exchange-Server erreichen. Stellen Sie eine Frei/Gebucht-Anforderung von Exchange Online, und suchen Sie nach den folgenden IIS-Protokolleinträgen, die zum Zeitpunkt der Frei/Gebucht-Anforderung vorgenommen wurden:

   • Ein AutoErmittlungseintrag im Ordner %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover , der "ASAutoDiscover/CrossForest/EmailDomain" enthält.

     Hinweis: Wenn Sie den Parameter in der TargetSharingEpr Organisationsbeziehung manuell auf die lokale URL für externe Exchange-Webdienste (EWS) festlegen, wird die AutoErmittlung umgangen, und dieser Eintrag ist nicht vorhanden.

   • Ein EWS-Eintrag im Ordner %ExchangeInstallPath%\Logging\HttpProxy\Ews , der "ASProxy/CrossForest/EmailDomain" enthält.

   Hinweis: Zeitstempel in IIS-Protokollen verwenden UTC-Zeit.

2. Stellen Sie sicher, dass die Firewall auf jedem lokalen Exchange-Server eingehende oder ausgehende Verbindungen zwischen Exchange Server-Endpunkten und Exchange Online-IP-Adressen zulässt. Um Firewallprobleme zu identifizieren, stellen Sie Frei/Gebucht-Anforderungen von Exchange Online, und überprüfen Sie dann die lokale Firewall, den Reverseproxy und die Netzwerkprotokolle. Weitere Informationen zum Konfigurieren einer Firewall finden Sie unter Firewallüberlegungen für die Verbunddelegierung und Microsoft 365-URLs und IP-Adressbereiche.

3. Wenn Ihre Organisation Organisationsbeziehungen verwendet, um Frei/Gebucht zu implementieren, stellen Sie sicher, dass auf jedem Exchange-Server ein Verbundzertifikat installiert ist. Führen Sie die folgenden Befehle in der Exchange-Verwaltungsshell (EMS) aus:

   Test-FederationTrustCertificate
   Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo | FL
   

   Wenn das Verbundzertifikat installiert ist, sollte die Befehlsausgabe keine Fehler oder Warnungen enthalten.

4. Führen Sie die folgenden Schritte aus, um die WSSecurity-Authentifizierung umzuschalten:

   1. Befolgen Sie das Verfahren unter Benutzer aus einer Verbundorganisation können die Frei/Gebucht-Informationen einer anderen Exchange-Organisation nicht sehen , um die WSSecurity-Authentifizierung sowohl in der AutoErmittlung als auch in den virtuellen EWS-Verzeichnissen auf allen lokalen Exchange-Servern zu aktivieren oder zurückzusetzen, falls sie bereits aktiviert ist. Führen Sie diesen Schritt auch dann aus, wenn die WSSecurity-Authentifizierung bereits aktiviert ist.

   2. Verwenden Sie die AutoErmittlungs- und EWS-Anwendungspools im IIS-Manager.

   3. Führen Sie den iisreset /noforce Befehl in einem PowerShell- oder Eingabeaufforderungsfenster auf jedem lokalen Exchange-Server aus, um IIS neu zu starten.

5. Wenn nur wenige Cloudbenutzer von diesem Problem betroffen sind und ihre Postfächer auf demselben E-Mail-Server in Exchange Online gehostet werden, überprüfen Sie, ob dieser E-Mail-Server eine Verbindung mit lokalen Endpunkten herstellen kann. Es ist möglich, dass ein lokaler Endpunkt Verbindungen von der ausgehenden IP-Adresse dieses E-Mail-Servers blockiert.

Zurück zum Anfang

Konfigurationsinformationen für Gesamtstruktur/Domäne wurden in Active Directory nicht gefunden

LID: 47932

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann oder umgekehrt. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Konfigurationsinformationen für Gesamtstruktur/Domänendomäne <> konnten in Active Directory nicht gefunden werden.

Dieser Fehler kann auftreten, wenn die Organisationseinstellungen falsch konfiguriert sind.

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Überprüfen Sie, ob die Domäne eines Benutzers, dessen Frei/Gebucht-Informationen angefordert werden, in den Organisationseinstellungen des Benutzers vorhanden ist, der versucht, die Frei/Gebucht-Informationen anzuzeigen. Wählen Sie je nach Frei/Gebucht-Richtung eines der folgenden Verfahren aus.

   • Cloud-zu-Lokal

     Führen Sie für einen Cloudbenutzer, der versucht, die Frei/Gebucht-Informationen für einen lokalen Benutzer anzuzeigen, die folgenden Schritte aus:

     1. Stellen Sie eine Verbindung mit Exchange Online PowerShell her, und führen Sie dann die folgenden PowerShell-Cmdlets aus, um die Verbunddomänen abzurufen:

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

        Vergewissern Sie sich, dass die Domäne des lokalen Benutzers in der Ausgabe eines der beiden Befehle aufgeführt ist. Wenn ein Cloudbenutzer user1@contoso.com beispielsweise die Frei/Gebucht-Option für den lokalen Benutzer user2@contoso.rosucht, überprüfen Sie, ob die lokale Domäne contoso.ro aufgeführt ist.

        Hinweis

        Sie können die Domänennamen auch finden, indem Sie in Exchange Online PowerShell oder (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses in der lokalen Exchange-Verwaltungsshell (EMS) ausführen (Get-FederatedOrganizationIdentifier).Domains .

     2. Wenn die Domäne des lokalen Benutzers in den Organisationseinstellungen des Cloudbenutzers nicht vorhanden ist, fügen Sie die Domäne hinzu, indem Sie das folgende PowerShell-Cmdlet ausführen:

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

   • Lokal in die Cloud

     Führen Sie für einen lokalen Benutzer, der versucht, die Frei/Gebucht-Informationen für einen Cloudbenutzer anzuzeigen, die folgenden Schritte aus:

     1. Führen Sie im EMS die folgenden PowerShell-Cmdlets aus:

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

        Überprüfen Sie, ob die Domäne des Cloudbenutzers mit einer der in der Befehlsausgabe aufgeführten Domänen übereinstimmt. Wenn beispielsweise ein lokaler Benutzer user1@contoso.ro Frei/Gebucht-Informationen für den Cloudbenutzer user2@contoso.comsucht, überprüfen Sie, ob die Clouddomäne contoso.com in der Ausgabe eines der beiden Befehle vorhanden ist.

     2. Wenn die Domäne des Cloudbenutzers in den Organisationseinstellungen des lokalen Benutzers nicht vorhanden ist, fügen Sie die Domäne hinzu. Führen Sie den folgenden Befehl aus:

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

2. Stellen Sie sicher, dass Ihre Exchange-Hybridbereitstellung über eine vollständige Hybridkonfiguration verfügt. Wenn dies erforderlich ist, führen Sie den Hybridkonfigurations-Assistenten (HCW) erneut aus, und wählen Sie Vollständige Hybridkonfiguration anstelle der minimalen Hybridkonfiguration aus. Eine minimale Hybridkonfiguration erstellt keine Organisationsbeziehung (Verbundvertrauensstellung) oder organisationsinterne Connectors.

Zurück zum Anfang

Fehler bei Proxywebanforderung: HTTP-Status 401

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , finden Sie eine der folgenden Fehlermeldungen.

Fehlermeldung 1

Fehler bei der Proxywebanforderung. ,innere Ausnahme: Fehler bei der Anforderung mit dem HTTP-Status 401: Nicht autorisiert.

Fehlermeldung 2

Fehler bei der AutoErmittlung für die E-Mail-Adresse. ,innere Ausnahme: Fehler bei der Anforderung mit dem HTTP-Status 401: Nicht autorisiert.

Dieser Fehler kann auftreten, wenn ein Umkreisgerät vor Exchange Server für die Vorauthentifizierung (Benutzername und Kennwort erforderlich) konfiguriert ist, anstatt Anforderungen von Exchange Online direkt an Exchange Server zu übergeben. Die virtuellen Verzeichnisse AutoErmittlung und EWS in Exchange-Hybridbereitstellungen unterstützen die Vorauthentifizierung nicht.

Beispiele für Umkreisgeräte sind Reverseproxys, Firewalls und Microsoft Threat Management Gateway (TMG).

Fehlermeldung 1 gibt an, dass bei einer EWS-Anforderung ein Fehler aufgetreten ist.

Fehlermeldung 2 gibt an, dass bei einer AutoErmittlungsanforderung ein Fehler aufgetreten ist.

Schritte zur Problembehandlung

Führen Sie die folgenden Schritte aus, um das Frei/Gebucht-Problem zu beheben, unabhängig davon, welche Fehlermeldung Sie erhalten haben. Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Überprüfen Sie, ob die Vorauthentifizierung aktiviert ist. Gehen Sie folgendermaßen vor:

   1. Führen Sie den Frei/Gebucht-Test in der Remotekonnektivitätsanalyse aus, um zu überprüfen, ob die Vorauthentifizierung aktiviert ist. Das Cloudpostfach ist das Quellpostfach, und das lokale Postfach ist das Zielpostfach. Überprüfen Sie nach Abschluss des Tests den Passthrough-Authentifizierungsstatus am Endpunkt. Wenn ein rotes Häkchen angezeigt wird, deaktivieren Sie die Vorauthentifizierung und erneutes Testen. Wenn ein grünes Häkchen angezeigt wird, fahren Sie mit dem nächsten Schritt fort, da es sich um ein falsch positives Ergebnis handelt.

   2. Überprüfen Sie, ob eine Frei/Gebucht-Anforderung von Exchange Online IIS erreicht. Führen Sie eine Frei/Gebucht-Abfrage aus, und durchsuchen Sie dann die IIS-Protokolle in Exchange Server nach einem der folgenden Einträge zum Zeitpunkt der Abfrage:

      • Suchen Sie im Ordner %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover nach einem AutoErmittlungseintrag, der den HTTP-Statuscode 401 Unauthorized enthält und den Text "ASAutoDiscover/CrossForest/EmailDomain" enthält.

        Hinweis: Wenn der TargetSharingEpr Parameter in der Organisationsbeziehung eine lokale externe EWS-URL angibt, wird die AutoErmittlung umgangen, und dieser Eintrag wird nicht angezeigt.

      • Suchen Sie im Ordner %ExchangeInstallPath%\Logging\HttpProxy\Ews nach einem EWS-Eintrag, der den HTTP-Statuscode 401 Unauthorized enthält und den Text "ASProxy/CrossForest/EmailDomain" enthält.

      Hinweis: Zeitstempel in IIS-Protokollen verwenden UTC-Zeit. Einige Einträge mit dem HTTP-Statuscode 401 Unauthorized sind normal.

      Die angegebenen Einträge geben an, dass die Frei/Gebucht-Anforderung IIS erreicht hat und in der Regel Probleme bei der Vorauthentifizierung ausschließen. Wenn Sie die angegebenen Einträge nicht finden, überprüfen Sie Ihre Reverseproxy- und Firewallprotokolle, um zu ermitteln, wo die Frei/Gebucht-Anforderung hängen geblieben ist.

2. Stellen Sie sicher, dass Sie WSSecurity (Exchange Server 2010) oder OAuth-Authentifizierung (Exchange Server 2013 und höhere Versionen) für die virtuellen EWS- und AutoErmittlungsverzeichnisse aktiviert haben. Vergewissern Sie sich außerdem, dass Sie die Standardauthentifizierungseinstellungen in IIS für die virtuellen Verzeichnisse AutoErmittlung und EWS aktiviert haben. Weitere Informationen finden Sie unter Standardauthentifizierungseinstellungen für virtuelle Exchange-Verzeichnisse und Standardeinstellungen für virtuelle Exchange-Verzeichnisse.

3. Führen Sie die Lösungsschritte unter Fehler beim Überprüfen der Sicherheit für die Nachricht aus. Wenn WSSecurity konfiguriert ist, stellen Sie sicher, dass Sie den Schritt ausführen, der WSSecurity umgeschaltet wird. Wenn die OAuth-Authentifizierung anstelle von WSSecurity konfiguriert ist, schalten Sie die OAuth-Authentifizierung für die virtuellen Verzeichnisse AutoErmittlung und EWS ein, indem Sie die folgenden Befehle ausführen:

   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. Vergewissern Sie sich, dass Sie über eine aktuelle Verbundvertrauensstellung verfügen. Führen Sie den folgenden Befehl in Exchange Online PowerShell aus, um die Verbundvertrauensinformationen für Ihre Exchange-Organisation abzurufen:

   Get-FederationTrust
   

   Die Befehlsausgabe sollte die folgenden Informationen enthalten:

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

   Hinweis: Die WindowsLiveId Vertrauensstellung ist eine Consumerinstanz des Microsoft-Verbundgateways. Die MicrosoftOnline Vertrauensstellung ist eine Geschäftsinstanz des Microsoft-Verbundgateways.

   Stellen Sie bei einer aktuellen Verbundvertrauensstellung sicher, dass ist ApplicationIdentifier260563 und nicht 292841, und dass ist ApplicationUrioutlook.com und nicht outlook.live.com. Wenn Sie über eine veraltete Verbundvertrauensstellung verfügen, wenden Sie sich an den Microsoft-Support.

Zurück zum Anfang

Fehler bei der AutoErmittlung für E-Mail-Adresse: InvalidUser

LID: 33676

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Die Antwort des AutoErmittlungsdiensts bei "https://Autodiscover/Autodiscover.svc/WSSecurity" ist aufgrund eines Fehlers in der Benutzereinstellung "ExternalEwsUrl" fehlgeschlagen. Fehlermeldung: InvalidUser.

Die Fehlermeldung wird möglicherweise angezeigt, wenn Sie den Frei/Gebucht-Test in der Remotekonnektivitätsanalyse ausführen.

Dieser Fehler kann auftreten, wenn das Cloudpostfach oder der AutoErmittlungsendpunkt falsch konfiguriert ist.

Schritte zur Problembehandlung

1. Vergewissern Sie sich, dass der Cloudbenutzer über eine sekundäre SMTP-Adresse verfügt, die die onmicrosoft.com Domäne enthält, indem Sie den folgenden Befehl ausführen:

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

   Beispielsweise sollte ein Benutzer, der über die primäre SMTP-Adresse user1@contoso.com verfügt, über eine sekundäre SMTP-Adresse verfügen, die der ähnelt user1@contoso.mail.onmicrosoft.com.

   Wenn der Cloudbenutzer über Exchange Server verwaltet wird, fügen Sie die sekundäre SMTP-Adresse zu Exchange Server hinzu, und synchronisieren Sie dann Identitätsdaten zwischen Ihrer lokalen Umgebung und Microsoft Entra ID.

2. Führen Sie die folgenden Befehle aus, um den TargetSharingEpr Parameterwert in der Organisationsbeziehung auf die url der lokalen externen Exchange-Webdienste (EWS) festzulegen:

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

   Nachdem Sie den TargetSharingEpr Parameterwert festgelegt haben, umgeht das Cloudpostfach die AutoErmittlung und stellt eine direkte Verbindung mit dem EWS-Endpunkt des lokalen Postfachs her.

Zurück zum Anfang

Der Aufrufer hat keinen Zugriff auf Frei/Gebucht-Daten.

LID: 47652, 44348, 40764

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann oder umgekehrt. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException: Der Aufrufer hat keinen Zugriff auf Frei/Gebucht-Daten.

Dieser Fehler kann auftreten, wenn das Postfach des Benutzers, dessen Frei/Gebucht-Informationen angefordert werden, falsch konfiguriert ist.

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Überprüfen Sie die Kalenderberechtigungen des Benutzers, dessen Frei/Gebucht-Informationen angefordert werden, indem Sie den folgenden Befehl ausführen:

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

   Der AccessRights Wert für den Default Benutzer in der Befehlsausgabe sollte oder LimitedDetailsseinAvailabilityOnly. Wenn der AccessRights Wert ist None, führen Sie das folgende PowerShell-Cmdlet aus, um diesen Wert auf oder AvailabilityOnlyLimitedDetailsfestzulegen:

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

2. Verwenden Sie die entsprechende Methode, um die Organisationsbeziehung zu überprüfen:

   • Wenn ein Cloudbenutzer die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann:

     Stellen Sie sicher, dass die Lokale Organisationsbeziehung die Clouddomäne angibt, die auf die lokalen Frei/Gebucht-Informationen zugreifen kann. Ein Beispiel für eine Clouddomäne ist contoso.mail.onmicrosoft.com. Informationen zum Ändern der Organisationsbeziehung in Exchange Server finden Sie unter Verwenden von PowerShell zum Ändern der Organisationsbeziehung. Vergewissern Sie sich außerdem, dass die E-Mail-Adresse des Cloudbenutzers über die gleiche Clouddomäne verfügt, z. B lucine.homsi@contoso.mail.onmicrosoft.com. .

   • Wenn ein lokaler Benutzer die Frei/Gebucht-Informationen für einen Cloudbenutzer nicht anzeigen kann:

     Stellen Sie sicher, dass die Cloudorganisationsbeziehung die lokale Domäne angibt, die auf die Frei/Gebucht-Informationen der Cloud zugreifen kann. Ein Beispiel für eine lokale Domäne ist contoso.com. Informationen zum Ändern der Organisationsbeziehung in Exchange Online finden Sie unter Verwenden von Exchange Online PowerShell zum Ändern der Organisationsbeziehung. Überprüfen Sie außerdem, ob die E-Mail-Adresse des lokalen Benutzers über die gleiche lokale Domäne verfügt, z. Blucine.homsi@contoso.com. .

Zurück zum Anfang

Fehler beim Verarbeiten der Sicherheitstoken in der Nachricht

LID: 59916

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

ProxyWebRequestProcessingException ErrorProxyRequestProcessingFailed
Fehler bei der Proxywebanforderung. , innere Ausnahme: Fehler beim Verarbeiten der Sicherheitstoken in der Nachricht.

Dieser Fehler kann auftreten, wenn die Zertifikate oder Metadaten im Microsoft-Verbundgateway ungültig sind.

Schritte zur Problembehandlung

1. Überprüfen Sie das Ablaufdatum und die Fingerabdrücke der lokalen Verbundvertrauenszertifikate, indem Sie die folgenden PowerShell-Cmdlets ausführen:

   Get-FederationTrust | FL
   Test-FederationTrust
   Test-FederationTrustCertificate
   

2. Um Metadaten im Microsoft-Verbundgateway zu aktualisieren, führen Sie den folgenden Befehl zweimal in der lokalen Exchange-Verwaltungsshell (EMS) aus:

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Weitere Informationen finden Sie unter Frei/Gebucht-Lookups funktionieren nicht mehr.

Zurück zum Anfang

Die organisationsübergreifende Anforderung ist nicht zulässig, da der Anfordernde aus einer anderen Organisation stammt.

LID: 39660

Problem

Sie verfügen über ein Hybrid mesh-Szenario, in dem ein Cloudbenutzer in einem nicht hybriden Exchange Online-Mandanten die Frei/Gebucht-Informationen für einen Cloudbenutzer in einem anderen Exchange Online-Mandanten, der hybrid wird, nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Die organisationsübergreifende Anforderung für die POSTFACH-SMTP-Adresse <> ist nicht zulässig, da der Anfordernde aus einer anderen Organisation stammt.
Empfänger: <SMTP-Adresse>
Ausnahmetyp: CrossOrganizationProxyNotAllowedForExternalOrganization
Ausnahmemeldung: Die organisationsübergreifende Anforderung für <die SMTP-Adresse> ist nicht zulässig, da der Anfordernde aus einer anderen Organisation stammt.

Beispielsweise kann ein Benutzer lucine@adatum.com in einem nicht hybriden Exchange Online-Mandanten die Frei/Gebucht-Eigenschaft eines Cloudbenutzers chanok@contoso.com in einem Hybridmandanten nicht anzeigen. Der Cloudbenutzer chanok@contoso.com verfügt über eine Proxy-E-Mail-Adresse chanok@contoso.mail.onmicrosoft.com. Der nicht hybride Mandant verfügt über zwei Organisationsbeziehungen: contoso.com (lokal) und contoso.mail.onmicrosoft.com (Cloud). AutoErmittlung für contoso.com verweist auf Exchange Server und AutoErmittlung für contoso.mail.onmicrosoft.com Punkte auf Exchange Online. Der Benutzer im Nicht-Hybridmandanten erhält die Fehlermeldung beim Abfragen der Frei/Gebucht-Informationen für chanok@contoso.com, da autoErmittlung für contoso.com Punkte nicht auf Exchange Online verweist.

Hinweis

Informationen zum entsprechenden Szenario für ein lokales Hybridgitter finden Sie unter Hybrid Mesh.

Problemumgehung

Um dieses Problem zu umgehen, kann Ihre Organisation eine der folgenden Methoden verwenden:

• Benutzer im nicht hybriden Exchange Online-Mandanten sollten die Frei/Gebucht-Adresse eines Cloudbenutzers in einem Hybridmandanten abfragen, indem sie die E-Mail-Adresse verwenden, für die autoErmittlung auf Exchange Online verweist. Fragt beispielsweise lucine@adatum.com Frei/Gebucht-Informationen für chanok@contoso.mail.onmicrosoft.comab. Um Frei/Gebucht-Informationen erfolgreich abfragen zu können, müssen Benutzer im nicht hybriden Exchange Online-Mandanten wissen, welche Benutzer im Hybridmandanten in der Cloud gehostet werden, und für jeden dieser Benutzer die E-Mail-Adresse, für die die AutoErmittlung auf Exchange Online verweist.

• Ein Administrator des nicht hybriden Exchange Online-Mandanten sollte die externe E-Mail-Adresse jedes Cloudbenutzers im Hybridmandanten auf die E-Mail-Adresse festlegen, für die die AutoErmittlung auf Exchange Online verweist. Beispielsweise legt ein Administrator im nicht hybriden Exchange Online-Mandanten die Ziel-E-Mail-Adresse von chanok@contoso.com im Hybridmandanten auf fest chanok@contoso.mail.onmicrosoft.com. Um diese Änderung vorzunehmen, muss der Administrator wissen, welche Benutzer im Hybridmandanten in der Cloud gehostet werden, und für jeden dieser Benutzer die E-Mail-Adresse, für die autoErmittlung auf Exchange Online verweist. Weitere Informationen zur mandantenübergreifenden Synchronisierung von Benutzer-E-Mail-Adressen finden Sie unter Was ist die mandantenübergreifende Synchronisierung?

Weitere Informationen

Bei einem Benutzer kann im folgenden Szenario ein ähnliches Problem auftreten:

• Der Benutzer befindet sich in einem nicht hybriden Exchange Server-Mandanten.
• Der Benutzer versucht, die Frei/Gebucht-Datei für einen lokalen Benutzer in einem Hybridmandanten anzuzeigen.
• AutoErmittlung für den Hybridmandanten verweist auf Exchange Online.

Beispielsweise kann ein Benutzer in einem nicht hybriden Exchange Server-Mandanten die Frei/Gebucht-Informationen für lokale Benutzer chanok@contoso.com in einem Hybridmandanten nicht anzeigen, da autoErmittlung für auf contoso.com Exchange Online (autodiscover-s.outlook.com) verweist.

Zurück zum Anfang

Fehler bei der Anforderung mit DEM HTTP-Status 401: Nicht autorisiert (fehlendes Signaturzertifikat)

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

System.Net.WebException: Fehler bei der Anforderung mit dem HTTP-Status 401: Nicht autorisiert.

Wenn Sie das Cmdlet Test-OAuthConnectivity ausführen, wird in der Befehlsausgabe die folgende Fehlermeldung angezeigt:

Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException: Fehlendes Signaturzertifikat.

Führen Sie beispielsweise den folgenden Befehl aus:

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

Der TargetUri Parameterwert ist die URL des lokalen AutoErmittlungsdiensts. Ein Beispiel für diese URL ist https://mail.contoso.com/Autodiscover/Autodiscover.svc.

Dieser Fehler kann auftreten, wenn die Authentifizierungskonfiguration über ein ungültiges OAuth-Zertifikat verfügt.

Lösung

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

1. Führen Sie das folgende PowerShell-Cmdlet in der Exchange-Verwaltungsshell (EMS) aus, um den Fingerabdruck des OAuth-Zertifikats abzurufen, das von der Authentifizierungskonfiguration verwendet wird:

   Get-AuthConfig | FL CurrentCertificateThumbprint
   

   Wenn die Befehlsausgabe keinen Zertifikatfingerabdruck zurückgibt, fahren Sie mit Schritt 3 fort. Fahren Sie andernfalls mit dem nächsten Schritt fort.

2. Führen Sie das folgende PowerShell-Cmdlet aus, um zu überprüfen, ob das in Schritt 1 identifizierte Zertifikat in Exchange Server vorhanden ist:

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

   Wenn Exchange Server kein Zertifikat zurückgibt, fahren Sie mit Schritt 3 fort, um ein neues Zertifikat zu erstellen.

   Wenn Exchange Server ein Zertifikat zurückgibt, dessen Fingerabdruck sich jedoch von dem Fingerabdruck unterscheidet, den Sie in Schritt 1 erhalten haben, fahren Sie mit Schritt 4 fort. Geben Sie in Schritt 4 den Fingerabdruck des Zertifikats an, das Exchange Server zurückgegeben hat.

3. Führen Sie das folgende PowerShell-Cmdlet aus, um ein neues OAuth-Zertifikat zu erstellen:

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

   Hinweis

   Wenn Sie aufgefordert werden, das SMTP-Zertifikat zu ersetzen, akzeptieren Sie die Eingabeaufforderung nicht.

   Geben Sie in Schritt 4 den Fingerabdruck des neuen Zertifikats an, das Sie in diesem Schritt erstellt haben.

4. Führen Sie die folgenden PowerShell-Cmdlets aus, um die Authentifizierungskonfiguration für die Verwendung des angegebenen Zertifikats zu aktualisieren:

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

   Hinweis

   Wenn Sie gewarnt werden, dass das Gültigkeitsdatum in weniger als 48 Stunden liegt, wählen Sie den Vorgang aus.

5. Führen Sie das folgende PowerShell-Cmdlet aus, um alle Verweise auf das vorherige Zertifikat zu entfernen:

   Set-AuthConfig -ClearPreviousCertificate
   

Zurück zum Anfang

Der Anwendung fehlt ein verknüpftes Konto für RBAC-Rollen, oder das verknüpfte Konto verfügt über keine RBAC-Rollenzuweisungen, oder das aufrufende Benutzerkonto ist die Anmeldung deaktiviert.

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

System.Web.Services.Protocols.SoapException: In der Anwendung fehlt ein verknüpftes Konto für RBAC-Rollen, oder das verknüpfte Konto verfügt über keine RBAC-Rollenzuweisungen, oder das Aufrufende Benutzerkonto ist für die Anmeldung deaktiviert.

Schritte zur Problembehandlung

Führen Sie die folgenden Schritte aus, um die in der Fehlermeldung erwähnten Probleme zu beheben. Nachdem Sie die Schritte 1 und 2 ausgeführt haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Stellen Sie sicher, dass der Eintrag "Exchange Online-ApplicationAccount" in der Liste der Exchange Server-Partneranwendungen vorhanden ist. Führen Sie das folgende PowerShell-Cmdlet in der Exchange-Verwaltungskonsole (EMS) aus, um dies zu überprüfen:

   Get-PartnerApplication | FL LinkedAccount
   

   Der Kontoeintrag sollte als <root domain FQDN>/Users/Exchange Online-ApplicationAccountangezeigt werden. Wenn der Eintrag aufgeführt ist, fahren Sie mit Schritt 2 fort.

   Wenn der Kontoeintrag nicht aufgeführt ist, fügen Sie das Konto wie folgt hinzu:

   1. Führen Sie die folgenden PowerShell-Cmdlets aus, um das Konto im lokalen Active Directory zu finden:

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

      Wenn das Konto in Active Directory aufgeführt ist, fahren Sie mit Schritt 1b fort.

      Wenn das Konto nicht in Active Directory aufgeführt ist, wurde es möglicherweise gelöscht. Verwenden Sie ADRestore , um den Kontostatus zu überprüfen und wiederherzustellen, falls es gelöscht wird. Wenn Sie das Konto mithilfe von ADRestore wiederhergestellt haben, fahren Sie mit Schritt 1b fort.

      Wenn Sie das Konto nicht mithilfe von ADRestore wiederherstellen können, führen Sie das unter Active Directory und Domänen für Exchange Server beschriebene Verfahren aus. Wenn das Konto durch dieses Verfahren nicht wiederhergestellt wird, erstellen Sie das Konto manuell in Active Directory, und fahren Sie dann mit Schritt 1b fort.

   2. Führen Sie das folgende PowerShell-Cmdlet aus, um das Active Directory-Konto der Liste der Exchange Server-Partneranwendungen hinzuzufügen:

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

   3. Starten Sie alle lokalen Exchange-Server neu, oder starten Sie IIS neu, indem Sie den iisreset /noforce Befehl in einem PowerShell- oder Eingabeaufforderungsfenster auf jedem Server ausführen.

2. Führen Sie das folgende PowerShell-Cmdlet im EMS aus, um die Zuweisungen der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) zu überprüfen:

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

   Die Befehlsausgabe kann beispielsweise die folgenden Rollenzuweisungen auflisten:

   

3. Durchsuchen Sie die folgenden Protokolle nach den Problemen, die in der Fehlermeldung angegeben sind:

   • EwS-Protokolle (Exchange-Webdienste), die sich im Ordner %ExchangeInstallPath%\Logging\Ews befinden
   • Anwendungsereignisprotokolle
   • Systemereignisprotokolle

4. Durchsuchen Sie die in Schritt 3 aufgeführten Protokolle nach einer Fehlermeldung, die auf AuthzInitializeContextFromSid verweist. Wenn Sie diese Fehlermeldung finden, lesen Sie die folgenden Ressourcen:

   • Einige Anwendungen und APIs erfordern Zugriff auf Autorisierungsinformationen für Kontoobjekte.

   • Fehler bei Zugriffsprüfungen aufgrund von AuthZ

Zurück zum Anfang

Die eingegebenen und gespeicherten Kennwörter stimmen nicht überein.

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Soap-Fehler-Ausnahme empfangen. Die eingegebenen und gespeicherten Kennwörter stimmen nicht überein.

Dieselbe Fehlermeldung wird angezeigt, wenn Sie das folgende Cmdlet ausführen, um zu überprüfen, ob der Cloudbenutzer ein Delegierungstoken für das lokale Benutzerpostfach abrufen kann:

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

Ursache

In den Azure-Anmeldeinformationen für bestimmte Cloudbenutzer besteht eine Inkonsistenz.

Lösung

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

1. Setzen Sie das Kennwort des Cloudbenutzers zurück. Wählen Sie entweder dasselbe oder ein anderes Kennwort aus.

2. Aktualisieren Sie den Benutzerprinzipalnamen (UPN) des Cloudbenutzers, um die onmicrosoft.com Domäne zu verwenden, und setzen Sie dann den UPN auf seinen früheren Wert zurück. Wenn der UPN des Cloudbenutzers beispielsweise ist user@contoso.com, ändern Sie ihn in den temporären UPN, user@contoso.mail.onmicrosoft.comund stellen Sie dann den UPN auf zurück user@contoso.com. Verwenden Sie dazu entweder Azure AD PowerShell oder den MSOL-Dienst.

   • Verwenden von Azure AD-PowerShell

     Führen Sie die folgenden PowerShell-Cmdlets aus:

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

   • Verwenden des MSOL-Diensts

     Führen Sie die folgenden PowerShell-Cmdlets aus:

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

3. Stellen Sie sicher, dass der ImmutableId Wert des lokalen Benutzerobjekts NULL ist. Überprüfen Sie den ImmutableId Wert für das lokale Benutzerobjekt, indem Sie den folgenden Befehl in der Exchange-Verwaltungsshell (EMS) ausführen:

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

   Verwenden Sie je nach ImmutableId Wert eine der folgenden Methoden.

   • ImmutableId-Wert ist NULL

     Wenn der ImmutableId Wert NULL ist, schalten Sie den Wert um:

     1. Legen Sie den ImmutableId des Remotepostfachobjekts auf den UPN des Cloudbenutzers fest, indem Sie das folgende PowerShell-Cmdlet im EMS ausführen:

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

        Beispiel: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

     2. Synchronisieren Sie die Änderung mit der Cloud, indem Sie die folgenden PowerShell-Cmdlets im EMS ausführen:

        Import-Module ADSync
        Start-ADSyncSyncCycle -PolicyType Delta
        

        Führen Sie das folgende PowerShell-Cmdlet in Exchange Online PowerShell aus, um zu überprüfen, ob der ImmutableId Wert aktualisiert wurde:

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

     3. Stellen Sie den ImmutableId des Remotepostfachobjekts auf NULL zurück, indem Sie das folgende PowerShell-Cmdlet im EMS ausführen:

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

     4. Synchronisieren Sie die Änderung mit der Cloud, indem Sie das folgende PowerShell-Cmdlet im EMS ausführen:

        Start-ADSyncSyncCycle -PolicyType Delta
        

        Führen Sie das folgende PowerShell-Cmdlet in Exchange Online PowerShell aus, um zu überprüfen, ob der ImmutableId Wert aktualisiert wurde:

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

   • ImmutableId-Wert ist nicht NULL

     Wenn der ImmutableId Wert nicht NULL ist, führen Sie den folgenden Befehl in ems aus, um den ImmutableId Wert auf NULL festzulegen:

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

     Sie können überprüfen, ob der ImmutableId Wert aktualisiert wurde, indem Sie das folgende PowerShell-Cmdlet in Exchange Online PowerShell ausführen:

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

Zurück zum Anfang

Das Kennwort muss geändert werden, oder das Kennwort für das Konto ist abgelaufen.

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird eine der folgenden Fehlermeldungen angezeigt.

Fehlermeldung 1

Das Kennwort für das Konto ist abgelaufen.

Fehlermeldung 2

Das Kennwort muss geändert werden

Dieselbe Fehlermeldung wird angezeigt, wenn Sie das folgende Cmdlet ausführen, um zu überprüfen, ob der Cloudbenutzer ein Delegierungstoken für das lokale Benutzerpostfach abrufen kann:

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

Dieser Fehler kann auftreten, wenn in den Azure-Anmeldeinformationen für bestimmte Cloudbenutzer eine Inkonsistenz vorhanden ist.

Lösung

Wählen Sie die Auflösung aus, die der Fehlermeldung entspricht.

Lösung für Fehlermeldung 1

Um das Problem zu beheben, verwenden Sie entweder Azure AD PowerShell oder den MSOL-Dienst.

• Verwenden von Azure AD-PowerShell

  Führen Sie die folgenden PowerShell-Cmdlets aus:

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

• Verwenden des MSOL-Diensts

  Führen Sie die folgenden PowerShell-Cmdlets aus:

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

Lösung für Fehlermeldung 2

Führen Sie die folgenden PowerShell-Cmdlets aus, um das Problem zu beheben:

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

Weitere Informationen finden Sie unter Frei/Gebucht-Informationen werden nach der Migration von exchange lokal nicht angezeigt.

Zurück zum Anfang

Die Bereitstellung ist erforderlich, bevor ein Verbundkonto angemeldet werden kann.

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Die Bereitstellung ist erforderlich, bevor ein Verbundkonto angemeldet werden kann. ErrorWin32InteropError

Dieselbe Fehlermeldung wird auch angezeigt, wenn Sie das folgende Cmdlet ausführen, um zu überprüfen, ob der Cloudbenutzer ein Delegierungstoken für das lokale Benutzerpostfach abrufen kann:

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

Dieser Fehler kann auftreten, wenn die Konfiguration von Verbundbenutzern in Microsoft Entra ID inkonsistent ist.

Lösung

Hinweis

Wenn das Problem die meisten oder alle Cloudbenutzer in Ihrer Organisation betrifft, wenden Sie sich an den Microsoft-Support.

Um das Problem zu beheben, aktualisieren Sie den Benutzerprinzipalnamen (UPN) des Cloudbenutzers, um die onmicrosoft.com Domäne zu verwenden, und wechseln Sie dann wieder auf den früheren Wert (Verbunddomäne). Wenn der UPN des Cloudbenutzers beispielsweise lautet user@contoso.com, wechseln Sie zum temporären UPN user@contoso.mail.onmicrosoft.com und dann zurück zu user@contoso.com. Verwenden Sie dazu einen der folgenden Ansätze (Azure AD PowerShell oder MSOL-Dienst):

• Verwenden von Azure AD-PowerShell

  Führen Sie die folgenden PowerShell-Cmdlets aus:

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

• Verwenden des MSOL-Diensts

  Führen Sie die folgenden PowerShell-Cmdlets aus:

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

Zurück zum Anfang

Timeout der Anforderung

LID: 43404

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Timeout der Anforderung
Die Anforderung konnte nicht rechtzeitig verarbeitet werden. Timeout beim Warten auf Anforderungsabschluss.
Microsoft.Exchange.InfoWorker.Common.Availability.TimeoutExpiredException: Die Anforderung konnte nicht rechtzeitig verarbeitet werden. Timeout beim Warten auf Anforderungsabschluss.
Name des Servers, von dem die Ausnahme stammt: <Servername>.

Dieselbe Fehlermeldung wird auch angezeigt, wenn Sie das folgende Cmdlet ausführen, um zu überprüfen, ob der Cloudbenutzer ein Delegierungstoken für das lokale Benutzerpostfach abrufen kann:

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

Dieser Fehler kann auftreten, wenn netzwerk- oder vorübergehende Probleme auftreten. Die Fehlermeldung ist generisch.

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Um vorübergehende Probleme auszuschließen, stellen Sie sicher, dass der Cloudbenutzer bei wiederholten Versuchen, die Frei/Gebucht-Informationen des lokalen Benutzers abzurufen, immer die gleiche Fehlermeldung erhält.

2. Überprüfen Sie, ob Sie ein Delegierungstoken abrufen können, wenn Sie jedes der folgenden Cmdlets ausführen:

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

   Hinweis: Führen Sie das Cmdlet Test-FederationTrust auf allen lokalen Exchange-Servern aus.

3. Vergewissern Sie sich, dass Exchange Server über ausgehenden Internetzugriff auf die beiden folgenden Ressourcen verfügt:

   • Das Microsoft-Verbundgateway (oder ein Autorisierungsserver, wenn Sie OAuth verwenden)

   • Die Verfügbarkeits-URL für Microsoft 365: https://outlook.office365.com/ews/exchange.asmx

   Weitere Informationen finden Sie unter Microsoft 365-URLs und IP-Adressbereiche und Überlegungen zur Firewall für die Verbunddelegierung.

4. Stellen Sie sicher, dass das Systemkonto in Exchange Server über Internetzugriff auf die folgenden URLs verfügt. Führen Sie die folgenden Schritte auf jedem Exchange-Server aus:

   1. Führen Sie den folgenden PsExec-Befehl aus, um eine PowerShell-Sitzung zu starten, die einen Webbrowser über das Systemkonto startet:

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

   2. Testen Sie den Browserzugriff (kein OAuth) vom Systemkonto auf die folgenden Microsoft-Verbundgateway-URLs:

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

        Der Browser sollte eine XML-Seite anzeigen.

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

        Der Browser sollte Sie zum Herunterladen der Datei auffordern.

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

        Der Browser sollte eine Liste von Vorgängen anzeigen, die von ManageDelegation2 unterstützt werden.

   3. Testen Sie den Browserzugriff (OAuth) vom Systemkonto auf die folgenden Microsoft-Autorisierungsserver-URLs:

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

        Der Browser sollte eine Anmeldeaufforderung anzeigen.

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

        Der Browser sollte den Anmeldefehler "Leider haben wir Probleme bei der Anmeldung" anzeigen.

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

        Der Browser sollte den HTTP-Statuscode 400 Bad Requestoder die Anmeldefehlermeldung "Leider haben wir Probleme bei der Anmeldung" anzeigen.

5. Rufen Sie die Details einer Frei/Gebucht-Anforderung ab, indem Sie die Exchange-Webdienste (EWS)-Protokolle überprüfen:

   1. Stellen Sie eine Frei/Gebucht-Anforderung von Exchange Online.

   2. Suchen Sie den Eintrag in den EWS-Protokollen, und überprüfen Sie den Wert in der time-taken Spalte. Die EWS-Protokolle befinden sich im Ordner %ExchangeInstallPath%\Logging\Ews .

   3. Überprüfen Sie die IIS-Protokolle im Ordner W3SVC1 der Standardwebsite, um sicherzustellen, dass die Frei/Gebucht-Anforderung protokolliert wird. Der W3SVC1-Ordnerpfad ist %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

Zurück zum Anfang

Der angegebene Membername ist entweder ungültig oder leer.

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

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>Der angegebene Membername ist entweder ungültig oder leer. </psf:text></psf:internalerror></psf:error></S:Detail></S:Fault> Microsoft.Exchange.Net.WSTrust.SoapFaultException: Soap fault exception received. at Microsoft.Exchange.Net.WSTrust.SecurityTokenService.EndIssueToken(IAsyncResult asyncResult) at Microsoft.Exchange.InfoWorker.Common.Availability.ExternalAuthenticationRequest.Complete(IAsyncResult asyncResult)

Der Fehler kann aus einem der folgenden Gründe auftreten:

• Eine Inkonsistenz in der Microsoft Entra-ID für Benutzer, die ein Delegierungstoken anfordern
• Eine Inkonsistenz bei der Konfiguration von Verbundbenutzern in Active Directory-Verbunddiensten (AD FS)

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Aktualisieren Sie den Benutzerprinzipalnamen (UPN) des Cloudbenutzers, um die onmicrosoft.com Domäne zu verwenden, und setzen Sie dann den UPN auf seinen früheren Wert zurück. Wenn der UPN des Cloudbenutzers beispielsweise ist user@contoso.com, ändern Sie ihn in den temporären UPN, user@contoso.mail.onmicrosoft.comund stellen Sie dann den UPN auf zurück user@contoso.com. Verwenden Sie dazu eine der folgenden Methoden (Azure AD PowerShell oder MSOL-Dienst):

   • Verwenden von Azure AD-PowerShell

     Führen Sie die folgenden PowerShell-Cmdlets aus:

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

   • Verwenden des MSOL-Diensts

     Führen Sie die folgenden PowerShell-Cmdlets aus:

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

2. Überprüfen Sie die AD FS-Regeln, -Endpunkte und -Protokolle.

3. Suchen Sie in der ImmutableID Befehlsausgabe des folgenden PowerShell-Cmdlets nach einem Fehler, der mit dem des Cloudbenutzers zusammenhängt:

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

   Beispielsweise kann die Befehlsausgabe die folgende Fehlermeldung enthalten:

   "Die E-Mail-Adresse "XGuNpVunD0afQeVNfyoUIQ==" ist nicht richtig. Verwenden Sie dieses Format: Benutzername, @-Zeichen, gefolgt vom Domänennamen. Zum Beispiel tonysmith@contoso.com oder tony.smith@contoso.com.
   + CategoryInfo : NotSpecified: (:) [Test-OrganizationRelationship], FormatException"

   Wenn Sie eine ähnliche Fehlermeldung erhalten, verwenden Sie eine der folgenden Methoden, um sicherzustellen, dass der ImmutableId Wert NULL (leerer Wert) ist:

   • Wenn der Cloudbenutzer nicht von der lokalen Umgebung synchronisiert wird, überprüfen Sie den ImmutableId Wert, indem Sie das folgende PowerShell-Cmdlet in Exchange Online PowerShell ausführen:

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

     Wenn der ImmutableId Wert nicht NULL ist, führen Sie das folgende PowerShell-Cmdlet in Exchange Online PowerShell aus:

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

   • Wenn der Cloudbenutzer lokal synchronisiert wird, überprüfen Sie den ImmutableId Wert für das lokale Benutzerobjekt, indem Sie den folgenden Befehl in der Exchange-Verwaltungsshell (EMS) ausführen:

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

     Verwenden Sie je nach ImmutableId Wert eine der folgenden Methoden:

     • ImmutableId-Wert ist NULL

       Wenn der ImmutableId Wert NULL ist, schalten Sie den Wert um:

       1. Legen Sie den ImmutableId des Remotepostfachobjekts auf den UPN des Cloudbenutzers fest, indem Sie das folgende PowerShell-Cmdlet im EMS ausführen:

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

          Beispiel: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

       2. Synchronisieren Sie die Änderung mit der Cloud, indem Sie die folgenden PowerShell-Cmdlets im EMS ausführen:

          Import-Module ADSync
          Start-ADSyncSyncCycle -PolicyType Delta
          

          Führen Sie das folgende PowerShell-Cmdlet in Exchange Online PowerShell aus, um zu überprüfen, ob der ImmutableId Wert aktualisiert wurde:

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

       3. Stellen Sie den ImmutableId des Remotepostfachobjekts auf NULL zurück, indem Sie das folgende PowerShell-Cmdlet im EMS ausführen:

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

       4. Synchronisieren Sie die Änderung mit der Cloud, indem Sie das folgende PowerShell-Cmdlet im EMS ausführen:

          Start-ADSyncSyncCycle -PolicyType Delta
          

          Überprüfen Sie, ob der ImmutableId Wert aktualisiert wurde. Führen Sie dazu das folgende PowerShell-Cmdlet in Exchange Online PowerShell aus:

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

     • ImmutableId-Wert ist nicht NULL

       Wenn der ImmutableId Wert nicht NULL ist, führen Sie den folgenden Befehl in ems aus, um den ImmutableId Wert auf NULL festzulegen:

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

       Führen Sie das folgende PowerShell-Cmdlet in Exchange Online PowerShell aus, um zu überprüfen, ob der ImmutableId Wert aktualisiert wurde:

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

4. Überprüfen Sie die Beziehungseinstellungen der Organisation. Weitere Informationen finden Sie unter Demystifying Hybrid Free/Busy.

5. Wenn die Fehlermeldung für einen Cloudbenutzer generiert wird, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann, führen Sie die folgenden Schritte aus:

   1. Führen Sie das folgende PowerShell-Cmdlet aus:

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

   2. Erstellen Sie die Verbundvertrauensstellung neu. Weitere Informationen finden Sie unter Entfernen einer Verbundvertrauensstellung und Konfigurieren einer Verbundvertrauensstellung.

Zurück zum Anfang

Das Resultset enthält zu viele Kalendereinträge.

LID: 54796

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen anderen Cloudbenutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Ausnahme: Das Resultset enthält zu viele Kalendereinträge. Die zulässige Größe = 1000; die tatsächliche Größe = 5009.

Dieser Fehler tritt auf, wenn die Anzahl der Kalendereinträge in einem einzelnen Zeitfenster 1.000 Elemente überschreitet. Eine einzelne Frei/Gebucht-Anforderung kann nicht mehr als 1.000 Elemente abrufen.

Lösung

Entfernen Sie einige der Kalenderelemente aus dem Zeitfenster, um den Grenzwert von 1.000 Elementen, die in einer einzelnen Frei/Gebucht-Anforderung abgerufen werden können, nicht zu überschreiten.

Weitere Informationen finden Sie unter Sie können keine Frei/Gebucht-Informationen im Kalender eines anderen Benutzers in Exchange Online anzeigen.

Zurück zum Anfang

Die Startzeit der Arbeitszeit muss kleiner oder gleich der Endzeit sein.

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für eine Raumliste nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Ausnahme: Microsoft.Exchange.InfoWorker.Common.InvalidParameterException: Die Startzeit der Arbeitszeit muss kleiner oder gleich der Endzeit sein.
Microsoft.Exchange.InfoWorker.Common.MeetingSuggestions.AttendeeWorkHours.Validate(TimeSpan startTime, TimeSpan endTime).

Dieser Fehler kann auftreten, wenn eine oder mehrere der folgenden Kalendereinstellungen für ein Raumpostfach in einer Raumliste ungültig sind:

• WorkingHoursStartTime
• WorkingHoursEndTime
• WorkingHoursTimeZone

Die Startzeit der Arbeitszeit muss kleiner oder gleich der Endzeit der Arbeitszeit sein, und die Zeitzone der Arbeitszeit muss festgelegt werden.

Lösung

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

1. Führen Sie das folgende PowerShell-Cmdlet aus, um die Kalendereinstellungen jedes Postfachs in der Raumliste zu überprüfen, um das Raumpostfach zu identifizieren, das ungültige Einstellungen aufweist:

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

2. Führen Sie das folgende PowerShell-Cmdlet aus, um die erforderlichen Parameterwerte für ein Raumpostfach festzulegen:

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

   Weitere Informationen finden Sie unter Set-MailboxCalendarConfiguration.

Zurück zum Anfang

Fehler bei der Anforderung mit dem HTTP-Status 401: Nicht autorisiert (Token hat eine ungültige Signatur)

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

System.Net.WebException: Fehler bei der Anforderung mit dem HTTP-Status 401: Nicht autorisiert.

Wenn Sie das folgende PowerShell-Cmdlet ausführen, um die OAuth-Authentifizierung zu testen:

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

Sie erhalten die folgende Befehlsausgabe:

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

Hinweis: Der TargetUri Parameterwert im befehl Test-OAuthConnectivity ist eine externe EWS-URL (Exchange Web Services), z https://mail.contoso.com/ews/exchange.asmx. B. .

Dieser Fehler kann auftreten, wenn die Einstellungen des Microsoft-Autorisierungsservers ungültig sind.

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Aktualisieren Sie die Autorisierungsmetadaten auf dem angegebenen Microsoft-Autorisierungsserver, dem Exchange vertraut. Führen Sie das folgende PowerShell-Cmdlet im EMS (lokal) aus:

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

   Warten Sie etwa 15 Minuten, bis der Befehl vollständig wirksam wird, oder starten Sie IIS neu, indem Sie den iisreset /noforce Befehl in einem PowerShell- oder Eingabeaufforderungsfenster auf jedem Exchange Server ausführen.

2. Überprüfen Sie die Einstellungen des Microsoft-Autorisierungsservers in Ihrer Exchange-Organisation, indem Sie das folgende PowerShell-Cmdlet im EMS ausführen:

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

   Die folgende Befehlsausgabe ist ein Beispiel für gültige Einstellungen:

   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
   

   Wenn die Microsoft-Autorisierungsservereinstellungen ungültig sind, versuchen Sie, den Hybridkonfigurations-Assistenten erneut auszuführen, um die Einstellungen des Microsoft-Autorisierungsservers auf gültige Werte zurückzusetzen.

Zurück zum Anfang

Fehler bei der Anforderung mit HTTP-Status 401: Nicht autorisiert (Schlüssel wurde nicht gefunden)

Problem

Sie verfügen über einen lokalen Benutzer, der die Frei/Gebucht-Informationen für einen Cloudbenutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

System.Net.WebException: Fehler bei der Anforderung mit dem HTTP-Status 401: Nicht autorisiert.

Wenn Sie das folgende PowerShell-Cmdlet in EMS ausführen, um die OAuth-Authentifizierung zu testen:

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

Sie erhalten die folgende Befehlsausgabe:

System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert.
Fehler: Token vom Authentifizierungsserver kann nicht abgerufen werden. Fehlercode: "invalid_client". Beschreibung: 'AADSTS70002:
Fehler beim Überprüfen der Anmeldeinformationen. AADSTS50012: Die Clientassertion enthält eine ungültige Signatur. [Ursache: Der Schlüssel wurde nicht gefunden., Fingerabdruck des vom Client verwendeten Schlüssels: '<fingerabdruck>'.

Dieser Fehler kann auftreten, wenn das OAuth-Zertifikat in Exchange Server nicht in Exchange Online vorhanden ist.

Lösung

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

1. Bestimmen Sie, ob Ihr lokales Exchange Server OAuth-Zertifikat in Ihrer Exchange Online-Organisation vorhanden ist:

   1. Führen Sie das folgende PowerShell-Cmdlet in der Exchange-Verwaltungsshell (EMS) aus, um das OAuth-Zertifikat in Exchange Server abzurufen:

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

      Die Befehlsausgabe enthält den Thumbprint Wert.

   2. Führen Sie die folgenden PowerShell-Cmdlets aus, um das Exchange Online OAuth-Zertifikat mithilfe des MSOL-Diensts abzurufen:

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

      Wenn der Value Parameterwert in der Befehlsausgabe leer ist, ist in Exchange Online kein OAuth-Zertifikat vorhanden. Fahren Sie in diesem Fall mit Schritt 3 fort, um das lokale Zertifikat in Exchange Online hochzuladen.

      Wenn der Value Parameterwert nicht leer ist, speichern Sie den Wert in einer Datei mit der Erweiterung ".cer". Öffnen Sie die Datei im Microsoft Certificate Manager-Tool , um das Exchange Online OAuth-Zertifikat anzuzeigen. Vergleichen Sie den Thumbprint Wert im Exchange Online-Zertifikat mit dem Fingerabdruck des lokalen Zertifikats, das Sie in Schritt 1a erhalten haben. Wenn die Fingerabdruckwerte übereinstimmen, fahren Sie mit Schritt 4 fort. Wenn die Fingerabdruckwerte nicht übereinstimmen, wählen Sie eine der folgenden Optionen aus:

      • Fahren Sie mit Schritt 2 fort, um das vorhandene lokale Zertifikat durch das Exchange Online-Zertifikat zu ersetzen.

      • Fahren Sie mit Schritt 3 fort, um das vorhandene Exchange Online-Zertifikat durch das lokale Zertifikat zu ersetzen.

2. Ersetzen Sie das vorhandene lokale Zertifikat durch das Exchange Online-Zertifikat:

   1. Führen Sie das folgende PowerShell-Cmdlet aus, um den Fingerabdruck des lokalen Zertifikats zu aktualisieren:

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

      Wenn Sie benachrichtigt werden, dass das Gültigkeitsdatum des Zertifikats in weniger als 48 Stunden liegt, akzeptieren Sie die Aufforderung, den Vorgang fortzusetzen.

   2. Führen Sie das folgende PowerShell-Cmdlet aus, um das lokale Zertifikat zu veröffentlichen:

      Set-AuthConfig -PublishCertificate  
      

   3. Führen Sie das folgende PowerShell-Cmdlet aus, um alle Verweise auf das vorherige Zertifikat zu entfernen:

      Set-AuthConfig -ClearPreviousCertificate 
      

   4. Fahren Sie mit Schritt 4 fort.

3. Exportieren Sie das lokale Autorisierungszertifikat, und laden Sie es dann in Ihre Exchange Online-Organisation hoch.

4. Führen Sie das folgende PowerShell-Cmdlet aus, um zu überprüfen, ob der SPN in der lokalen Authentifizierungskonfiguration lautet 00000002-0000-0ff1-ce00-000000000000:

   Get-AuthConfig | FL ServiceName
   

   Wenn sich der SPN-Wert unterscheidet, aktualisieren Sie den SPN, indem Sie das folgende PowerShell-Cmdlet ausführen:

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

Zurück zum Anfang

Fehler bei Proxywebanforderung: Antwort ist kein wohlgeformtes XML

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Fehler bei der Proxywebanforderung., innere Ausnahme: Antwort ist kein wohlgeformtes XML

Wenn Sie den Test Synchronisierung, Benachrichtigung, Verfügbarkeit und automatische Antworten für den lokalen Benutzer ausführen, erhalten Sie die folgende Fehlermeldung:

Die vom Dienst empfangene Antwort enthielt keinen gültigen XML-Code.

Diese Fehler können aus einem der folgenden Gründe auftreten:

• Problem mit externen Exchange-Webdiensten (EWS)
• Fehlkonfiguration von Netzwerkgeräten, z. B. reverse proxy oder firewall

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Überprüfen Sie, ob eine Frei/Gebucht-Anforderung von Exchange Online IIS auf einem Exchange-Server erreichen kann. Führen Sie eine Frei/Gebucht-Abfrage aus, und durchsuchen Sie dann die IIS-Protokolle nach Einträgen mit HTTP-Statuscode 200 OK oder 401 Unauthorized zum Zeitpunkt der Abfrage. Diese Einträge deuten darauf hin, dass die Frei/Gebucht-Anforderung IIS erreicht hat. Hinweis: Zeitstempel in IIS-Protokollen verwenden UTC-Zeit.

   Wenn Sie diese Einträge nicht finden, überprüfen Sie den Reverseproxy und die Firewallprotokolle, um zu ermitteln, wo die Frei/Gebucht-Anforderung hängen geblieben ist.

2. Führen Sie eine Frei/Gebucht-Abfrage aus, und durchsuchen Sie dann das Exchange Server-Anwendungsprotokoll in der Windows-Ereignisanzeige nach Einträgen, die zum Zeitpunkt der Abfrage vorgenommen wurden, um die Ursache des Problems einzugrenzen.

Zurück zum Anfang

Herstellen einer Verbindung mit dem Remoteserver nicht möglich

Problem

Sie verfügen über einen lokalen Benutzer, der die Frei/Gebucht-Informationen für einen Cloudbenutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Fehler bei der Kommunikation mit https://login.microsoftonline.com/extSTS.srf., innere Ausnahme: Verbindung mit dem Remoteserver kann nicht hergestellt werden.

Dieser Fehler kann auftreten, wenn mindestens ein Exchange-Server keine Verbindung mit einer Microsoft-Verbundgateway-URL herstellen kann.

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Führen Sie die folgenden PowerShell-Cmdlets in der Exchange-Verwaltungsshell (EMS) aus, um zu überprüfen, ob Sie ein Delegierungstoken abrufen können:

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

2. Vergewissern Sie sich, dass Ihre lokalen Exchange-Server über ausgehenden Internetzugriff auf die beiden folgenden Ressourcen verfügen:

   • Das Microsoft-Verbundgateway oder der Microsoft-Autorisierungsserver, wenn Sie die OAuth-Authentifizierung verwenden.

   • Die Verfügbarkeits-URL für Microsoft 365: https://outlook.office365.com/ews/exchange.asmx.

   Weitere Informationen finden Sie unter Microsoft 365-URLs und IP-Adressbereiche und Überlegungen zur Firewall für die Verbunddelegierung.

3. Vergewissern Sie sich, dass das Systemkonto in Exchange Server über Internetzugriff auf die folgenden URLs verfügt. Führen Sie die folgenden Schritte auf allen Exchange-Servern in Ihrer Organisation aus:

   1. Führen Sie den folgenden PsExec-Befehl aus, um eine PowerShell-Sitzung zu starten, die einen Webbrowser über das Systemkonto startet:

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

   2. Testen Sie den Browserzugriff (keine OAuth-Authentifizierung) vom Systemkonto auf die folgenden Microsoft-Verbundgateway-URLs:

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

        Der Browser sollte eine XML-Seite anzeigen.

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

        Der Browser sollte Sie zum Herunterladen der Datei auffordern.

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

        Der Browser sollte eine Liste von Vorgängen anzeigen, die von ManageDelegation2 unterstützt werden.

   3. Testen Sie den Browserzugriff (OAuth-Authentifizierung) vom Systemkonto auf die folgenden Microsoft-Autorisierungsserver-URLs:

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

        Der Browser sollte eine Anmeldeaufforderung anzeigen.

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

        Der Browser sollte die Anmeldefehlermeldung "Leider haben wir Probleme bei der Anmeldung" anzeigen.

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

        Der Browser sollte den HTTP-Statuscode 400 Bad Request oder die Anmeldefehlermeldung "Leider haben wir Probleme bei der Anmeldung" anzeigen.

Zurück zum Anfang

Fehler bei der AutoErmittlung für E-Mail-Adresse: Der Remotename konnte nicht aufgelöst werden.

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Fehler bei der AutoErmittlung für die E-Mail-Adresse><des Benutzers mit Dem Fehler System.Net.WebException: Der Remotename konnte nicht aufgelöst werden: "<Lokaler Hostname>".

Dieser Fehler kann auftreten, wenn die URL des lokalen AutoErmittlungsendpunkts oder die öffentlichen DNS-Einstellungen falsch sind.

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Führen Sie die folgenden PowerShell-Cmdlets in Exchange Online PowerShell aus, um den Wert des TargetAutodiscoverEpr Parameters abzurufen:

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

   Wenn der Wert des lokalen Hostnamens in der Fehlermeldung beispielsweise lautet, ist mail.contoso.comdie Url des AutoErmittlung-Endpunkts wahrscheinlich https://autodiscover.contoso.com/autodiscover/autodiscover.svc.

   Wenn der TargetAutodiscoverEpr Parameterwert richtig ist, fahren Sie mit Schritt 3 fort. Fahren Sie andernfalls mit Schritt 2 fort.

2. Aktualisieren Sie die Url des AutoErmittlungsendpunkts mithilfe einer der folgenden Methoden:

   • Führen Sie den Hybridkonfigurations-Assistenten (HCW) aus, um den Standardmäßigen AutoErmittlungsendpunkt wiederherzustellen.

   • Aktualisieren Sie entweder den DiscoveryEndpoint Parameter oder den TargetAutodiscoverEpr Parameter manuell, indem Sie eines der folgenden PowerShell-Cmdlets ausführen:

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

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

3. Stellen Sie sicher, dass der lokale Hostname in der Fehlermeldung (z. B. mail.contoso.com) im öffentlichen DNS aufgelöst werden kann. Der DNS-Eintrag für den Hostnamen sollte auf den lokalen AutoErmittlungsdienst unter der AutoErmittlungs-Endpunkt-URL verweisen.

   Hinweis: Wenn Sie das Problem nicht beheben können und eine temporäre Problemumgehung benötigen, führen Sie eines der folgenden PowerShell-Cmdlets aus, um den TargetSharingEpr Parameterwert manuell auf die externe EXCHANGE-Webdienst-URL (EWS) zu aktualisieren. Die externe EWS-URL sollte ähnlich aussehen https://<EWS hostname>/ews/exchange.asmx und in DNS aufgelöst werden können.

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

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

   Hinweis

   Wenn Sie den TargetSharingEpr Parameterwert festlegen, umgeht das Cloudpostfach die AutoErmittlung und stellt eine direkte Verbindung mit dem EWS-Endpunkt her.

Zurück zum Anfang

Fehler beim Abrufen von ASURL. Fehler 8004010F

Problem

Sie verfügen über einen lokalen Benutzer, der die Frei/Gebucht-Informationen für einen Cloudbenutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Fehler beim Abrufen von ASURL. Fehler 8004010F.

Dies ist ein allgemeiner Fehler, der sich auf den AutoErmittlungsdienst bezieht.

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Stellen Sie sicher, dass die AutoErmittlung für den betroffenen Benutzer die EWS-URL (Exchange Web Services) für den Benutzer zurückgibt.

2. Führen Sie den E-Mail-Autokonfigurationstest im Outlook-Client des betroffenen Benutzers aus, um sicherzustellen, dass die AutoErmittlung die EWS-URL für den Benutzer zurückgibt.

3. Stellen Sie sicher, dass frei/gebucht zwischen lokalen Benutzern funktioniert, die auf verschiedenen Exchange-Servern gehostet werden.

4. Wenn Sie über Lastenausgleichsmodule verfügen, überprüfen Sie, ob die Lastenausgleichsmodule das Problem verursacht haben. Ändern Sie dazu die Windows Hosts-Datei (auf dem Computer, auf dem der Outlook-Client des Benutzers installiert ist), um die Lastenausgleichsmodule zu umgehen und auf einen bestimmten Clientzugriffsserver zu verweisen.

5. Wenn Frei/Gebucht zwischen lokalen Benutzern funktioniert, überprüfen Sie, ob alle lokalen Exchange-Server über ausgehenden Zugriff auf Microsoft 365-URLs und IP-Adressbereiche verfügen.

6. Überprüfen Sie, ob jeder Exchange-Server ein Delegierungstoken abrufen kann. Führen Sie hierzu das folgende PowerShell-Cmdlet im EMS auf allen lokalen Exchange-Servern aus:

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

   Wenn der Befehl ein Delegierungstoken nicht abrufen kann, überprüfen Sie, ob der Server auf Proxy- oder Firewallebene eine Verbindung mit Office 365 herstellen kann.

Zurück zum Anfang

Fehler bei Proxywebanforderung: Objekt verschoben

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Fehler bei der Proxywebanforderung. , innere Ausnahme: System.Net.WebException: Fehler bei der Anforderung mit der Fehlermeldung: Objekt verschoben.

Dieser Fehler kann auftreten, wenn der TargetSharingEpr Parameterwert in den Organisationseinstellungen auf eine falsche EWS-Endpunkt-URL (Exchange Web Services) festgelegt ist.

Sie können die folgenden PowerShell-Cmdlets ausführen, um den TargetSharingEpr Parameterwert aus den Organisationseinstellungen (organisationsinterner Connector oder Organisationsbeziehung) abzurufen:

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

Vergewissern Sie sich, dass der TargetSharingEpr Parameterwert im öffentlichen DNS nicht aufgelöst wird.

Hinweis: Der Hybridkonfigurations-Assistent (HCW) legt keinen Wert für den TargetSharingEpr Parameter fest, es sei denn, Sie wählen Exchange Modern Hybrid Technology zum Installieren eines Hybrid-Agents verwenden aus. In diesem Szenario legt der HCW den TargetSharingEpr Parameter auf einen externen EWS-URL-Endpunktwert fest, der ähnelt https://<GUID>.resource.mailboxmigration.his.msappproxy.net/ews/exchange.asmx. Sie können den TargetSharingEpr Parameterwert auch manuell festlegen. Wenn der TargetSharingEpr Wert auf einen Endpunkt festgelegt ist, umgeht Outlook die AutoErmittlung und stellt eine direkte Verbindung mit diesem Endpunkt her.

Lösung

Um das Problem zu beheben, führen Sie einen der folgenden Befehle aus, um den TargetSharingEpr Parameterwert manuell auf eine externe EWS-URL zu aktualisieren, die in DNS aufgelöst wird:

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

Zurück zum Anfang

Die Anforderung wurde abgebrochen: Sicherer SSL/TLS-Kanal konnte nicht erstellt werden

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann oder umgekehrt. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Die Anforderung wurde abgebrochen: Sicherer SSL/TLS-Kanal konnte nicht erstellt werden.

Ursache 1: Cloudbenutzer können die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen.

Das Problem kann auftreten, wenn TLS 1.2 in einem lokalen Endpunkt, mit dem Microsoft 365 eine Verbindung herstellt, z. B. Exchange Server oder eine Firewall, falsch konfiguriert oder deaktiviert ist.

Ursache 2: Ein lokaler Benutzer kann die Frei/Gebucht-Informationen für einen Cloudbenutzer nicht anzeigen.

Das Problem kann auch aus einem der folgenden Gründe auftreten:

• Das Microsoft 365-Zertifikat (outlook.office365.com) fehlt im Speicher der vertrauenswürdigen Stammzertifizierungsstellen ( CA).
• Es besteht ein Cypher Suite-Konflikt .
• Andere SSL/TLS-Probleme.

Schritte zur Problembehandlung

Verwenden Sie die folgenden Tools, um lokale TLS 1.2-Probleme zu diagnostizieren:

• Führen Sie den SSL-Servertest im Microsoft Remote Connectivity Analyzer aus.
• Führen Sie das HealthChecker-Skript in der Exchange-Verwaltungsshell (EMS) auf jedem Exchange-Server aus.

Informationen zur TLS-Konfiguration finden Sie unter Bewährte Methoden für die TLS-Konfiguration für Exchange Server und Vorbereiten auf TLS 1.2.

Informationen zum Suchen nach Zertifikaten im Speicher der vertrauenswürdigen Stammzertifizierungsstelle finden Sie unter Anzeigen von Zertifikaten mit dem MMC-Snap-In.

Informationen zu unterstützten TLS-Verschlüsselungssammlungen finden Sie unter VON Microsoft 365 unterstützte TLS-Verschlüsselungssammlungen.

Zurück zum Anfang

Der vom Benutzerkontext im Token angegebene Benutzer ist nicht vorhanden.

Problem

Sie verfügen über einen lokalen Benutzer, der die Frei/Gebucht-Informationen für einen Cloudbenutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Der vom Benutzerkontext im Token angegebene Benutzer ist nicht vorhanden. error_category="invalid_user". 401: Nicht autorisiert.

Die gleiche Fehlermeldung wird angezeigt, wenn Sie das PowerShell-Cmdlet Test-OAuthConnectivity ausführen.

Der Fehler kann auftreten, wenn das lokale Benutzerpostfach und das entsprechende E-Mail-Benutzerobjekt in Microsoft Entra ID nicht synchronisiert werden. Bis zur Synchronisierung ist die Bereitstellung des E-Mail-Benutzerobjekts in der Microsoft Entra-ID möglicherweise aufgehoben.

Lösung

Um das Problem zu beheben, verwenden Sie Microsoft Entra Connect , um den lokalen Benutzer und das entsprechende E-Mail-Benutzerobjekt in Microsoft Entra ID zu synchronisieren.

Zurück zum Anfang

Die Hostnamenkomponente des Zielgruppenanspruchswerts ist ungültig.

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Die Hostnamenkomponente des Zielgruppenanspruchswerts "https://< hybrid.domain.com>" ist ungültig; error_category="invalid_resource"

Der Fehler kann aus einem der folgenden Gründe auftreten.

Ursache 1

Ssl-Auslagerung und OAuth-Authentifizierung sind beide aktiviert. Die SSL-Abladung funktioniert nicht, wenn die OAuth-Authentifizierung aktiviert ist.

Ursache 2

Ein Netzwerkgerät vor Exchange Server blockiert Frei/Gebucht-Anforderungen.

Lösung

Problemumgehung für Ursache 1

Wählen Sie eine der folgenden Problemumgehungen aus:

• Deaktivieren Sie die SSL-Abladung sowohl für Exchange-Webdienste (EWS) als auch für die AutoErmittlung in der lokalen Umgebung. Weitere Informationen finden Sie unter Konfigurieren der SSL-Abladung für die AutoErmittlung und Konfigurieren der SSL-Abladung für EWS sowie unter SSL-Standardeinstellungen.

• Führen Sie das folgende PowerShell-Cmdlet aus, um die OAuth-Authentifizierung zu deaktivieren, indem Sie den organisationsinternen Cloudconnector deaktivieren:

  Set-IntraOrganizationConnector "HybridIOC*" -Enabled $false
  

  Wenn der organisationsinterne Connector deaktiviert ist, wird die DAuth-Authentifizierung über die Organisationsbeziehung aktiviert. Führen Sie das folgende PowerShell-Cmdlet aus, um die Organisationsbeziehung zu überprüfen:

  Get-OrganizationRelationship
  

  Weitere Informationen zu den Organisationsbeziehungseinstellungen finden Sie unter Demystifying Hybrid Free/Busy.

Lösung für Ursache 2

Konfigurieren Sie das Netzwerkgerät vor Exchange, um Frei/Gebucht-Anforderungen nicht zu blockieren.

Zurück zum Anfang

Fehler bei der Proxywebanforderung mit HTTP-Status 503: Dienst nicht verfügbar

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Fehler bei der Proxywebanforderung, innere Ausnahme: System.Net.WebException: Fehler bei der Anforderung mit HTTP-Status 503: Dienst nicht verfügbar...

Dieser Fehler kann auftreten, wenn ein Microsoft Windows-Dienst, eine Serverkomponente, ein IIS-Anwendungspool oder ein falsch konfigurierter Endpunkt beendet wurde.

Schritte zur Problembehandlung

Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Stellen Sie sicher, dass die Für Exchange Server benötigten Windows-Dienste ausgeführt werden. Führen Sie das folgende PowerShell-Cmdlet auf jedem Exchange-Server in Ihrer Organisation aus, um den Status von Diensten zu überprüfen:

   Test-ServiceHealth
   

   Verwenden Sie die Dienstkonsole, um alle beendeten Dienste zu starten, die für Exchange Server erforderlich sind.

2. Überprüfen Sie, ob die erforderlichen Exchange Server-Komponenten aktiv sind. Um den Status von Komponenten zu überprüfen, führen Sie das folgende PowerShell-Cmdlet auf jedem Exchange-Server in Ihrer Organisation aus:

   Get-ServerComponentState <server name>
   

   Verwenden Sie zum Aktivieren einer inaktiven Komponente das PowerShell-Cmdlet Set-ServerComponentState .

3. Stellen Sie sicher, dass die folgenden IIS-Anwendungspools für Exchange-Webdienste (EWS) und AutoErmittlung gestartet wurden:

   • MSExchangeServicesAppPool
   • Msexchangesyncapppool
   • MSExchangeAutodiscoverAppPool

4. Testen Sie, ob der AutoErmittlungsendpunkt gültig ist. Gehen Sie folgendermaßen vor:

   1. Führen Sie die folgenden PowerShell-Cmdlets aus, um die AutoErmittlungs-Endpunkt-URL aus den DiscoveryEndpoint Parameterwerten oder TargetAutodiscoverEpr abzurufen:

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

   2. Navigieren Sie in einem Webbrowser zur URL des AutoErmittlungsendpunkts, oder führen Sie das Invoke-WebRequest -Uri "<endpoint URL>" -Verbose PowerShell-Cmdlet aus, um sicherzustellen, dass die URL gültig ist. Überprüfen Sie vorzugsweise die URL aus einem externen Netzwerk.

5. Führen Sie die folgenden Schritte aus, um zu testen, ob die EWS-URL gültig ist:

   1. Führen Sie die folgenden PowerShell-Cmdlets aus, um die EWS-URL aus dem TargetSharingEpr Parameterwert in den Organisationseinstellungen abzurufen:

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

   b. Navigieren Sie in einem Webbrowser zur EWS-URL, oder führen Sie das Invoke-WebRequest -Uri "<endpoint URL>" -Verbose PowerShell-Cmdlet aus, um sicherzustellen, dass die URL gültig ist. Überprüfen Sie vorzugsweise die URL aus einem externen Netzwerk.

6. Überprüfen Sie die IIS-Protokolle auf Frei/Gebucht-Anforderungen, die den HTTP-Statuscode 503 Service Unavailablezurückgeben:

   1. Stellen Sie eine Frei/Gebucht-Anforderung von Exchange Online.

   2. Suchen Sie in den IIS-Protokollen im Ordner W3SVC1 für die Standardwebsite auf jedem Exchange-Server nach HTTP-Statuscodeeinträgen503 Service Unavailable. Der W3SVC1-Ordnerpfad ist %SystemDrive%\inetpub\logs\LogFiles\W3SVC1. Diese Einträge können dabei helfen, den Server zu identifizieren, auf dem das Problem vorliegt.

   3. Wenn die Frei/Gebucht-Anforderung nicht im Ordner W3SVC1 protokolliert wird, überprüfen Sie, ob die Anforderung in den Fehlerprotokollen im HTTPERR-Ordner auf jedem Exchange-Server protokolliert wird. Der HTTPERR-Ordnerpfad ist %SystemRoot%\System32\LogFiles\HTTPERR. Wenn die Frei/Gebucht-Anforderung in den HTTPERR-Protokollen protokolliert wird, suchen Sie nach falsch konfigurierten IIS-Einstellungen.

7. Überprüfen Sie den Header der Serverantwort, die Sie erhalten, wenn Sie eine Verbindung mit der lokalen EWS-URL herstellen, um sicherzustellen, dass IIS (kein anderer Webserver) die Antwort gesendet hat. Führen Sie hierzu die folgenden Befehle in einer PowerShell-Sitzung aus, die nicht mit dem lokalen EWS verbunden ist (führen Sie die Befehle nicht in der Exchange-Verwaltungsshell aus):

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

   Wenn beispielsweise "Microsoft-HTTPAPI/2.0" in der Befehlsausgabe anstelle von "Microsoft -IIS/10.0" angezeigt wird, ist es wahrscheinlich, dass ein WAP-Dienst (Web Application Proxy) (nicht IIS) auf die Anforderung geantwortet hat. Überprüfen Sie, ob der WAP-Dienst ausgefallen ist.

Zurück zum Anfang

Fehler bei der Proxywebanforderung mit HTTP-Status 504: Gatewaytimeout

LID: 43532

Problem

Sie verfügen über einen Cloudbenutzer, der die Frei/Gebucht-Informationen für einen lokalen Benutzer nicht anzeigen kann. Wenn Sie das Problem diagnostizieren , wird die folgende Fehlermeldung angezeigt:

Fehler bei der Proxy-Webanforderung, innere Ausnahme: Fehler bei der Anforderung mit HTTP-Status 504: Gatewaytimeout...

Dieser Fehler kann auftreten, wenn ein Hybrid-Agent in Ihrer Organisation falsch konfiguriert ist.

Lösung

Führen Sie die folgenden Schritte aus, um das Problem zu beheben. Nachdem Sie die einzelnen Schritte abgeschlossen haben, überprüfen Sie, ob das Frei/Gebucht-Problem behoben wurde.

1. Überprüfen Sie den TargetSharingEpr Parameterwert in den Organisationseinstellungen. Der Wert sollte ähnlich aussehen https://<GUID>.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx. Führen Sie die folgenden PowerShell-Cmdlets aus, um den Wert des TargetSharingEpr Parameters zu bestimmen:

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

   Wenn der TargetSharingEpr Parameterwert falsch ist:

   1. Führen Sie den Hybridkonfigurations-Assistenten (HCW) aus, und wählen Sie Klassische Exchange-Hybridtopologie verwenden aus.

   2. Führen Sie den HCW erneut aus, und wählen Sie Exchange Modern HybridTopology verwenden aus. Diese Prozedur zwingt den HCW, den TargetSharingEpr Parameterwert zurückzusetzen.

2. Überprüfen Sie den Status des Microsoft-Hybriddiensts auf dem Server, auf dem der Hybrid-Agent installiert ist. Wenn der Dienst beendet wurde, starten Sie ihn.

3. Überprüfen Sie den Status des Hybrid-Agents. Wenn der Status Inaktiv lautet:

   1. Führen Sie den Hybridkonfigurations-Assistenten (HCW) aus, und wählen Sie Klassische Exchange-Hybridtopologie verwenden aus.

   2. Führen Sie den HCW erneut aus, und wählen Sie Exchange Modern HybridTopology verwenden aus. Dieses Verfahren zwingt den HCW, den Hybrid-Agent neu zu installieren.

   3. Installieren Sie das Hybrid-Agent-PowerShell-Modul, und führen Sie dann das PowerShell-Cmdlet Get-HybridApplication aus, um die interne URL zu finden, auf die der Hybrid-Agent verweist.

4. Navigieren Sie zu der internen URL, die Sie in Schritt 3 gefunden haben. Beheben Sie alle gefundenen Fehler, z. B. Zertifikatfehler.

5. Konfigurieren Sie den Hybrid-Agent so, dass Anforderungen an einen Lastenausgleich statt an einen Server mit Microsoft Exchange Server weitergeroutet werden, um Probleme auszuschließen, die möglicherweise auf diesem Server vorhanden sind.

6. Stellen Sie sicher, dass der Hybrid-Agent Frei/Gebucht-Anforderungen und die Postfachmigration unterstützt.

Zurück zum Anfang