Konfigurieren der OAuth-Authentifizierung zwischen Exchange- und Exchange Online-Organisationen

Der Hybridkonfigurations-Assistent konfiguriert automatisch die OAuth-Authentifizierung zwischen lokalen Exchange Server- und Exchange Online-Organisationen. Wenn Ihre Exchange-Organisation Exchange 2010- oder Exchange 2007-Server enthält, konfiguriert der Hybridkonfigurations-Assistent keine OAuth-Authentifizierung zwischen lokalen und Online-Exchange-Organisationen. Für diese Bereitstellungen wird weiterhin standardmäßig der Prozess der Verbundvertrauensstellung verwendet. Bestimmte Features sind jedoch nur mithilfe des neuen Exchange OAuth-Authentifizierungsprotokolls vollständig in Ihrer Organisation verfügbar.

Mit dem neuen Exchange OAuth-Authentifizierungsprozess werden derzeit die folgenden Exchange-Funktionen aktiviert:

  • Nachrichtendatensatzverwaltung (Message Records Management, MRM)
  • Compliance-eDiscovery-Suche unter Exchange
  • Compliance-Archivierung in Exchange

Es wird empfohlen, dass alle gemischten Exchange 2013-Organisationen die Exchange OAuth-Authentifizierung konfigurieren, nachdem der Hybridkonfigurations-Assistent ausgeführt wurde.

Wichtig

  • Wenn Ihre lokale Organisation nur Exchange 2013-Server mit kumulativem Update 5 oder höher, Exchange 2016 oder Exchange 2019 ausführt, führen Sie den Hybridkonfigurations-Assistenten aus, anstatt die Schritte in diesem Thema auszuführen.

  • Dieses Feature von Exchange Server 2013 ist nicht vollständig kompatibel mit Office 365, das von 21Vianet in China betrieben wird, und es gelten möglicherweise einige Featurebeschränkungen. Weitere Informationen finden Sie unter Office 365, betrieben von 21Vianet.

Was sollten Sie wissen, bevor Sie beginnen?

Tipp

Liegt ein Problem vor? Bitten Sie in den Exchange-Foren um Hilfe. Besuchen Sie die Foren unter Exchange Server.

Wie konfigurieren Sie die OAuth-Authentifizierung zwischen Ihren lokalen Exchange- und den Exchange-Online-Organisationen?

Glossar

Anfängliche Domäne: Die erste domäne, die im Mandanten bereitgestellt wurde. Beispiel: contoso.onmicrosoft.com. Sie wird in dieser Dokumentation als <Ihre mandantenebenannte Domäne> bezeichnet.

Hybridroutingdomäne: Die Hybridroutingdomäne in Exchange-Hybridumgebungen wie contoso.mail.onmicrosoft.comwird verwendet, um den Nachrichtenfluss zwischen lokalen Exchange-Servern und Exchange Online zu verwalten. Es stellt eine nahtlose Kommunikation und Nachrichtenübermittlung in beiden Umgebungen sicher. Sie wird in dieser Dokumentation als <Ihre Hybridroutingdomäne> bezeichnet.

Microsoft Online Email Routing Address (MOERA): Die aus dem Präfix des userPrincipalName Benutzers erstellte Adresse sowie das anfängliche Domänensuffix, das automatisch der proxyAddress in Microsoft Entra ID hinzugefügt wird. Beispiel: smtp:john.doe@contoso.onmicrosoft.com. Wir verwenden die MOERA in dieser Dokumentation nicht, sondern führen sie hier der Vollständigkeit halber auf.

Primäre SMTP-Domäne: Die primäre SMTP-Domäne in Microsoft Exchange Server ist die Hauptdomäne, die für E-Mail-Adressen innerhalb der Organisation verwendet wird. Sie wird in dieser Dokumentation als <Primäre SMTP-Domäne> bezeichnet.

AutoErmittlungsendpunkt: Der AutoErmittlungsendpunkt ist eine Webdienst-URL, die Exchange Server-Konfigurationsinformationen bereitstellt. Es ermöglicht Anwendungen, exchange-Dienste automatisch zu ermitteln und eine Verbindung mit diesen herzustellen. Wenn Ihr Unternehmen z. B contoso.com . als primäre SMTP-Domäne verwendet, ist der AutoErmittlungsendpunkt in der Regel https://autodiscover.contoso.com/autodiscover/autodiscover.svc oder https://contoso.com/autodiscover/autodiscover.svc. Er wird in dieser Dokumentation als <Ihr lokaler AutoErmittlungsendpunkt> bezeichnet.

Exchange-Webdienste (EWS): Exchange Web Services (EWS) ist eine plattformübergreifende API, mit der Anwendungen auf Postfachelemente wie E-Mail-Nachrichten, Besprechungen und Kontakte zugreifen können. Sie wird in dieser Dokumentation als <Ihre lokale externe Exchange-Webdienst-URL> bezeichnet.

Schritt 1: Erstellen der Autorisierungsserverobjekte für Ihre Exchange Online-Organisation

Führen Sie den folgenden Befehl in der Exchange-Verwaltungsshell (Exchange PowerShell) in Ihrer lokalen Exchange-Organisation aus. Stellen Sie sicher, dass Sie die Platzhalter durch Ihre Werte ersetzen, bevor Sie den Befehl ausführen:

New-AuthServer -Name "WindowsAzureACS" -AuthMetadataUrl "https://accounts.accesscontrol.windows.net/<your tenant initial domain>/metadata/json/1"
New-AuthServer -Name "evoSTS" -Type AzureAD -AuthMetadataUrl "https://login.windows.net/<your tenant initial domain>/federationmetadata/2007-06/federationmetadata.xml"

In GCC High oder DoD müssen Sie stattdessen die folgenden Befehle verwenden:

New-AuthServer -Name "WindowsAzureACS" -AuthMetadataUrl "https://login.microsoftonline.us/<your tenant initial domain>/metadata/json/1"
New-AuthServer -Name "evoSTS" -Type AzureAD -AuthMetadataUrl "https://login.microsoftonline.us/<your tenant initial domain>/federationmetadata/2007-06/federationmetadata.xml"

Schritt 2: Aktivieren der Partneranwendung für Ihre Exchange-Online-Organisation

Führen Sie den folgenden Befehl in Exchange PowerShell in Ihrer lokalen Exchange-Organisation aus:

Get-PartnerApplication |  Where-Object {$_.ApplicationIdentifier -eq "00000002-0000-0ff1-ce00-000000000000" -and $_.Realm -eq ""} | Set-PartnerApplication -Enabled $true

Schritt 3: Exportieren des lokalen Autorisierungszertifikats

In diesem Schritt müssen Sie ein PowerShell-Skript direkt auf dem Exchange-Server ausführen, um das lokale Autorisierungszertifikat zu exportieren, das dann im nächsten Schritt in Ihre Exchange Online-Organisation importiert wird.

  1. Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei, die etwa ExportAuthCert.ps1 benannt werden kann.

    Hinweis

    Wenn Sie das Zertifikat hochladen möchten, das in Zukunft als neues Authentifizierungszertifikat konfiguriert ist, ersetzen Sie durch $thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint$thumbprint = (Get-AuthConfig).NewCertificateThumbprint.

    $thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint
    if((Test-Path $env:SYSTEMDRIVE\OAuthConfig) -eq $false)
    {
       New-Item -Path $env:SYSTEMDRIVE\OAuthConfig -Type Directory
    }
    Set-Location -Path $env:SYSTEMDRIVE\OAuthConfig
    $oAuthCert = (dir Cert:\LocalMachine\My) | Where-Object {$_.Thumbprint -match $thumbprint}
    $certType = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
    $certBytes = $oAuthCert.Export($certType)
    $CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
    [System.IO.File]::WriteAllBytes($CertFile, $certBytes)
    
  2. Führen Sie unter Exchange PowerShell in Ihrer lokalen Exchange-Organisation das PowerShell-Skript aus, welches Sie im vorherigen Schritt erstellt haben. Zum Beispiel:

    .\ExportAuthCert.ps1
    

Schritt 4: Hochladen des lokalen Autorisierungszertifikats in Microsoft Entra Access Control Service (ACS)

Verwenden Sie als Nächstes microsoft Graph PowerShell, um das lokale Autorisierungszertifikat hochzuladen, das Sie im vorherigen Schritt in Microsoft Entra Access Control Services (ACS) exportiert haben. Wenn Sie das Modul nicht installiert haben, öffnen Sie ein Windows PowerShell-Fenster als Administrator, und führen Sie den folgenden Befehl aus:

Install-Module -Name Microsoft.Graph.Applications

Führen Sie die folgenden Schritte aus, nachdem Microsoft Graph PowerShell installiert wurde.

  1. Öffnen Sie einen Windows PowerShell-Arbeitsbereich, in dem die Microsoft Graph-Cmdlets installiert sind. Alle Befehle in diesem Schritt werden mithilfe der Windows PowerShell ausgeführt, die mit der Microsoft Graph-Konsole verbunden ist.

  2. Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei, die etwa UploadAuthCert.ps1 benannt werden kann.

    Connect-MgGraph -Scopes Application.ReadWrite.All
    
    $CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
    $objFSO = New-Object -ComObject Scripting.FileSystemObject
    $CertFile = $objFSO.GetAbsolutePathName($CertFile)
    $cer = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($CertFile)
    $binCert = $cer.GetRawCertData()
    $credValue = [System.Convert]::ToBase64String($binCert)
    $ServiceName = "00000002-0000-0ff1-ce00-000000000000"
    Write-Host "[+] Trying to query the service principals for service: $ServiceName" -ForegroundColor Cyan
    $p = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'"
    Write-Host "[+] Trying to query the keyCredentials for service: $ServiceName" -ForegroundColor Cyan
    $servicePrincipalKeyInformation = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'" -Select "keyCredentials"
    
    $keyCredentialsLength = $servicePrincipalKeyInformation.KeyCredentials.Length
    if ($keyCredentialsLength -gt 0) {
       Write-Host "[+] $keyCredentialsLength existing key(s) found - we keep them if they have not expired" -ForegroundColor Cyan
    
       $newCertAlreadyExists = $false
       $servicePrincipalObj = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphServicePrincipal
       $keyCredentialsArray = @()
    
       foreach ($cred in $servicePrincipalKeyInformation.KeyCredentials) {
          $thumbprint = [System.Convert]::ToBase64String($cred.CustomKeyIdentifier)
    
          Write-Host "[+] Processing existing key: $($cred.DisplayName) thumbprint: $thumbprint" -ForegroundColor Cyan
    
          if ($newCertAlreadyExists -ne $true) {
             $newCertAlreadyExists = ($cer.Thumbprint).Equals($thumbprint, [System.StringComparison]::OrdinalIgnoreCase)
          }
    
          if ($cred.EndDateTime -lt (Get-Date)) {
             Write-Host "[+] This key has expired on $($cred.EndDateTime) and will not be retained" -ForegroundColor Yellow
             continue
          }
    
          $keyCredential = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphKeyCredential
          $keyCredential.Type = "AsymmetricX509Cert"
          $keyCredential.Usage = "Verify"
          $keyCredential.Key = $cred.Key
    
          $keyCredentialsArray += $keyCredential
       }
    
    
       if ($newCertAlreadyExists -eq $false) {
          Write-Host "[+] New key: $($cer.Subject) thumbprint: $($cer.Thumbprint) will be added" -ForegroundColor Cyan
          $keyCredential = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphKeyCredential
          $keyCredential.Type = "AsymmetricX509Cert"
          $keyCredential.Usage = "Verify"
          $keyCredential.Key = [System.Text.Encoding]::ASCII.GetBytes($credValue)
    
          $keyCredentialsArray += $keyCredential
    
          $servicePrincipalObj.KeyCredentials = $keyCredentialsArray
          Update-MgServicePrincipal -ServicePrincipalId $p.Id -BodyParameter $servicePrincipalObj
       } else {
          Write-Host "[+] New key: $($cer.Subject) thumbprint: $($cer.Thumbprint) already exists and will not be uploaded again" -ForegroundColor Yellow
       }
    } else {
       $params = @{
          type = "AsymmetricX509Cert"
          usage = "Verify"
          key = [System.Text.Encoding]::ASCII.GetBytes($credValue)
       }
    
       Write-Host "[+] This is the first key which will be added to this service principal" -ForegroundColor Cyan
       Update-MgServicePrincipal -ServicePrincipalId $p.Id -KeyCredentials $params
    }
    
  3. Führen Sie das PowerShell-Skript aus, welches Sie im vorherigen Schritt erstellt haben. Beispiel:

    .\UploadAuthCert.ps1
    
  4. Nachdem Sie das Skript gestartet haben, wird ein Dialogfeld für Anmeldeinformationen angezeigt. Geben Sie die Anmeldeinformationen für das Mandantenadministratorkonto in Ihrer Microsoft Online Microsoft Entra-Organisation ein. Lassen Sie nach dem Ausführen des Skripts die mit Microsoft Graph verbundene Windows PowerShell-Sitzung geöffnet. Sie werden diese zum Ausführen eines PowerShell-Skripts im nächsten Schritt erneut nutzen.

Schritt 5: Registrieren aller Hostnamenautoritäten für Ihre internen und externen lokalen Exchange-HTTP-Endpunkte mit Microsoft Entra ID

Sie müssen das Skript in diesem Schritt für jeden öffentlich zugänglichen Endpunkt in Ihrer lokalen Exchange-Organisation ausführen, einschließlich interner und externer URLs für die moderne Hybridauthentifizierung). Wenn Exchange beispielsweise extern unter https://mail.contoso.com/ews/exchange.asmxverfügbar ist, verwenden Sie den Dienstprinzipalnamen https://mail.contoso.com. Bei der Registrierung zusätzlicher externer Hostnamen-Berechtigungen besteht keine Begrenzung.

Führen Sie die folgenden Befehle in der Exchange-Verwaltungsshell aus, um die Exchange-Endpunkte in Ihrer lokalen Organisation zu bestätigen:

Get-MapiVirtualDirectory | Format-List server,*url*
Get-WebServicesVirtualDirectory | Format-List server,*url*
Get-OABVirtualDirectory | Format-List server,*url*

Hinweis

Das folgende Skript erfordert, dass die mit Microsoft Graph verbundene Windows PowerShell mit Ihrer Microsoft 365-Organisation verbunden ist, wie in Schritt 4 im vorherigen Abschnitt erläutert.

  1. Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei, die etwa RegisterEndpoints.ps1 benannt werden kann. Ersetzen Sie https://mail.contoso.com/ und https://autodiscover.contoso.com/ durch die entsprechende Hostnamenautorität für Ihre lokale Exchange-Organisation.

     $ServiceName = "00000002-0000-0ff1-ce00-000000000000";
     $x = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'"
     $x.ServicePrincipalNames += "https://mail.contoso.com/"
     $x.ServicePrincipalNames += "https://autodiscover.contoso.com/"
     Update-MgServicePrincipal -ServicePrincipalId $x.Id -ServicePrincipalNames $x.ServicePrincipalNames
    
  2. Führen Sie in Windows PowerShell, das mit Microsoft Graph verbunden ist, das Windows PowerShell-Skript aus, das Sie im vorherigen Schritt erstellt haben. Zum Beispiel:

    .\RegisterEndpoints.ps1
    
  3. Um zu überprüfen, ob alle Datensätze hinzugefügt wurden, führen Sie den folgenden Befehl in Windows PowerShell aus, die mit Microsoft Graph verbunden ist, und suchen https://namespace Sie in den Ergebnissen nach Einträgen.

    Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'" | Select-Object -ExpandProperty ServicePrincipalNames | Sort-Object
    

Schritt 6: Erstellen eines IntraOrganizationConnector aus Ihrer lokalen Organisation zu Microsoft 365 oder Office 365

In diesem Schritt konfigurieren wir eine IntraOrganizationConnector , die es Exchange Server lokal ermöglicht, Ihre Exchange Online-Organisation zu erreichen. Dieser Connector ermöglicht die Featureverfügbarkeit und Dienstkonnektivität in allen Organisationen. Sie können das Cmdlet Get-IntraOrganizationConfiguration sowohl in Ihren lokalen Mandanten als auch in Microsoft 365- oder Office 365-Mandanten verwenden, um die Endpunktwerte zu bestimmen, die für das New-IntraOrganizationConnector-Cmdlet erforderlich sind.

Wir konfigurieren die Hybridroutingdomäne als Zieladresse. Die Hybridroutingdomäne wird automatisch erstellt, wenn Ihre Microsoft 365- oder Office 365-Organisation erstellt wird. Wenn beispielsweise die erste Domäne, die in der Microsoft 365- oder Office 365-Organisation hinzugefügt und überprüft wurde, ist contoso.com, lautet contoso.mail.onmicrosoft.comIhre Zieladresse .

Führen Sie unter Verwendung der Exchange PowerShell das folgende Cmdlet in Ihrer lokalen Organisation aus:

$ServiceDomain = (Get-AcceptedDomain | Where-Object {$_.DomainName -like "*.mail.onmicrosoft.com"}).DomainName.Address
New-IntraOrganizationConnector -Name ExchangeHybridOnPremisesToOnline -DiscoveryEndpoint https://outlook.office365.com/autodiscover/autodiscover.svc -TargetAddressDomains $ServiceDomain

Schritt 7: Erstellen eines IntraOrganizationConnector von Ihrer Microsoft 365- oder Office 365-Organisation für Ihre lokale Exchange-Organisation

In diesem Schritt konfigurieren wir eine IntraOrganizationConnector , mit der Exchange Online Ihre lokale Exchange-Organisation erreichen kann. Dieser Connector ermöglicht die Featureverfügbarkeit und Dienstkonnektivität in allen Organisationen. Sie können das Cmdlet Get-IntraOrganizationConfiguration sowohl in Ihren lokalen Mandanten als auch in Microsoft 365- oder Office 365-Mandanten verwenden, um die Endpunktwerte zu bestimmen, die für das New-IntraOrganizationConnector-Cmdlet erforderlich sind.

Sie sollten alle SMTP-Domänen, die in Ihrer lokalen Exchange-Organisation verwendet werden (mit Ausnahme von initial domain und hybrid routing domain), als TargetAddressDomainshinzufügen. Wenn Sie über mehrere SMTP-Domänen verfügen, fügen Sie diese als durch Trennzeichen getrennte Liste hinzu (z. B contoso.com. ,tailspintoys.com). Außerdem müssen Sie Ihren lokalen AutoErmittlungsendpunkt als DiscoveryEndpointangeben.

Nachdem Sie eine Verbindung mit Exchange Online PowerShell hergestellt haben, ersetzen <your on-premises AutoDiscover endpoint> Sie und <your on-premises SMTP domain(s)> durch Ihre Werte, und führen Sie den folgenden Befehl aus:

New-IntraOrganizationConnector -Name ExchangeHybridOnlineToOnPremises -DiscoveryEndpoint <your on-premises AutoDiscover endpoint> -TargetAddressDomains <your on-premises SMTP domain(s)>

Schritt 8: Konfigurieren eines AvailabilityAddressSpace für alle Exchange-Server vor Version 2013 SP1

Warnung

Exchange Server 2007, Exchange Server 2010 und Exchange Server 2013 haben das Ende des Supports erreicht.

Wenn Sie eine Hybridbereitstellung in älteren Exchange-Organisationen konfigurieren, benötigen Sie mindestens einen Exchange 2013-Server, auf dem Exchange 2013 SP1 oder höher ausgeführt wird. Der Exchange 2013-Server erfordert die Serverrollen Clientzugriff und Postfach. Der Exchange 2013-Server koordiniert die Kommunikation zwischen Ihrer vorhandenen lokalen Exchange-Organisation und der Exchange Online-Organisation. Um die Zuverlässigkeit und die Verfügbarkeit der Funktionen der hybriden Bereitstellung zu verbessern, wird dringend empfohlen, mehrere Exchange 2013-Server in der lokalen Organisation zu installieren.

In Exchange 2013-Organisationen mit Exchange 2010 oder Exchange 2007 wird empfohlen, dass alle Front-End-Server mit Internetzugriff Exchange 2013-Clientzugriffsserver mit SP1 oder höher sind. Alle Exchange-Webdienste (EWS)-Anforderungen müssen einen Exchange 2013-Clientzugriffsserver durchlaufen. Diese Anforderung umfasst Anforderungen von Microsoft 365 an Ihre lokale Exchange-Organisation sowie Anforderungen von Ihrer lokalen Exchange-Organisation an Microsoft 365. Es ist wichtig, dass Sie über genügend Exchange 2013-Clientzugriffsserver verfügen, um die Verarbeitungslast zu bewältigen und Verbindungsredundanz bereitzustellen. Die Anzahl der benötigten Clientzugriffsserver hängt von der durchschnittlichen Anzahl der EWS-Anforderungen ab und variiert je nach Organisation.

Bevor Sie den folgenden Schritt ausführen, stellen Sie Folgendes sicher:

  • Die Front-End-Hybridserver sind Exchange 2013 SP1 oder höher.
  • Sie verfügen über eine eindeutige externe Exchange-Webdienste-URL für die Exchange 2013-Server. Die Microsoft 365- oder Office 365-Organisation muss eine Verbindung mit diesen Servern herstellen, damit cloudbasierte Anforderungen für Hybridfeatures ordnungsgemäß funktionieren.
  • Die Server verfügen sowohl über die Postfach- als auch die Clientzugriffsrolle.
  • Für alle vorhandenen Exchange 2010/2007-Postfach- und -Clientzugriffsserver wurde das neueste kumulative Update oder Service Pack (SP) angewendet.

Hinweis

Vorhandene Exchange 2010/2007-Postfachserver können weiterhin Exchange 2010/2007-Clientzugriffsserver als Front-End-Server für Verbindungen mit nicht hybriden Funktionen verwenden. Nur Hybridbereitstellungsfeatureanforderungen der Microsoft 365- oder Office 365-Organisation müssen eine Verbindung mit Exchange 2013-Servern herstellen.

Ein AvailabilityAddressSpace muss auf Exchange 2013-Clientzugriffsservern vor Exchange 2013 konfiguriert werden, die auf den Exchange-Webdienstendpunkt Ihrer lokalen Exchange 2013 SP1-Clientzugriffsserver verweist. Dieser Endpunkt ist derselbe Endpunkt, der zuvor in Schritt 5 dargelegt wurde, oder kann durch das Ausführen des folgenden Cmdlets auf Ihrem lokalen Exchange 2013 SP1-Clientzugriffsserver festgelegt werden.

Get-WebServicesVirtualDirectory | Format-List AdminDisplayVersion,ExternalUrl

Hinweis

Wenn virtuelle Verzeichnisinformationen von mehreren Servern zurückgegeben werden, vergewissern Sie sich, dass Sie den für einen Exchange 2013 SP1-Clientzugriffsserver zurückgegebenen Endpunkt verwenden. Sie wird für den AdminDisplayVersion Parameter oder höher angezeigt15.0 (Build 847.32).

Verwenden Sie zum Konfigurieren von AvailabilityAddressSpaceExchange PowerShell, und führen Sie das folgende Cmdlet in Ihrer lokalen Organisation aus:

Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl <your on-premises external Exchange Web Services URL> -ForestName <your hybrid routing domain> -UseServiceAccount $true

Woher wissen Sie, dass dieses Verfahren erfolgreich war?

Sie können die Korrektheit der OAuth-Konfiguration verifizieren, indem Sie das Test-OAuthConnectivity-Cmdlet verwenden. Dieses Cmdlet überprüft, ob die lokalen Exchange- und Exchange Online-Endpunkte anforderungen voneinander erfolgreich authentifizieren können.

Wenn Sie überprüfen möchten, ob Ihre lokale Exchange-Organisation erfolgreich eine Verbindung mit Exchange Online herstellen kann, müssen Sie den folgenden Befehl in der Exchange PowerShell in Ihrer lokalen Organisation ausführen:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox <On-Premises Mailbox> -Verbose | Format-List

Um zu überprüfen, ob Ihre Exchange Online-Organisation erfolgreich eine Verbindung mit Ihrer lokalen Exchange-Organisation herstellen kann, stellen Sie eine Verbindung mit Exchange Online PowerShell her , und führen Sie den folgenden Befehl aus:

Test-OAuthConnectivity -Service EWS -TargetUri <external hostname authority of your Exchange On-Premises deployment>/metadata/json/1 -Mailbox <Exchange Online Mailbox> -Verbose | Format-List

Beispiel:

Test-OAuthConnectivity -Service EWS -TargetUri `https://mail.contoso.com/metadata/json/1` -Mailbox ExchangeOnlineBox1 -Verbose | Format-List

Wichtig

Sie können den The SMTP address has no mailbox associated with it. Fehler ignorieren. Es ist nur wichtig, dass der ResultTask Parameter den Wert zurückgibt Success. Der letzte Abschnitt der Testausgabe sollte z. B.:

ResultType: Success
Identity: Microsoft.Exchange.Security.OAuth.ValidationResultNodeId
IsValid: True
ObjectState: New