Konfigurieren der OAuth-Authentifizierung zwischen Exchange- und Exchange Online-OrganisationenConfigure OAuth authentication between Exchange and Exchange Online organizations

 

Gilt für: Exchange Online, Exchange Server 2013Applies to: Exchange Online, Exchange Server 2013

In reinen Exchange 2013-Hybridbereitstellungen wird bei Verwendung des Assistenten für die Hybridkonfiguration die OAuth-Authentifizierung konfiguriert. Bei gemischten Exchange 2013/2010- und Exchange 2013/2007-Hybridbereitstellungen wird die neue OAuth-basierte Authentifizierungsverbindung zwischen Office 365 und lokalen Exchange-Organisationen für Hybridbereitstellungen nicht vom Assistenten für die Hybridkonfiguration konfiguriert. In diesen Bereitstellungen wird standardmäßig weiterhin der Verbundvertrauensstellungsprozess verwendet. Bestimmte Exchange 2013-Funktionen sind jedoch nur vollständig in Ihrer gesamten Organisation verfügbar, wenn das neue Exchange OAuth-Authentifizierungsprotokoll benutzt wird.Exchange 2013-only hybrid deployments configure OAuth authentication when using the Hybrid Configuration Wizard. For mixed Exchange 2013/2010 and Exchange 2013/2007 hybrid deployments, the new hybrid deployment OAuth-based authentication connection between Office 365 and on-premises Exchange organizations isn’t configured by the Hybrid Configuration wizard. These deployments continue to use the federation trust process by default. However, certain Exchange 2013 features are only fully available across your organization by using the new Exchange OAuth authentication protocol.

Mit dem neuen Exchange OAuth-Authentifizierungsprozess werden derzeit die folgenden Exchange-Funktionen aktiviert:The new Exchange OAuth authentication process currently enables the following Exchange features:

  • Nachricht Datensatzverwaltung (MRM)Message Records Management (MRM)

  • Compliance-eDiscovery-Suche unter ExchangeExchange In-place eDiscovery

  • Compliance-Archivierung in ExchangeExchange In-place Archiving

Sie sollten in allen gemischten Exchange-Organisationen, in denen eine Hybridbereitstellung mit Exchange 2013 und Exchange Online implementiert wird, die Exchange-OAuth-Authentifizierung konfigurieren, nachdem Sie die Hybridbereitstellung mit dem Assistenten für die Hybridkonfiguration konfiguriert haben.We recommend that all mixed Exchange organizations that implement a hybrid deployment with Exchange 2013 and Exchange Online configure Exchange OAuth authentication after configuring their hybrid deployment with the Hybrid Configuration Wizard.

Wichtig

Wenn in Ihrer lokalen Organisation nur Exchange 2013-Server mit installiertem kumulativen Update 5 oder höher ausgeführt werden, führen Sie den Assistenten für die Hybridbereitstellung anstelle der Schritte in diesem Thema aus.If your on-premises organization is running only Exchange 2013 servers with Cumulative Update 5 or later installed, run the Hybrid Deployment Wizard instead of performing the steps in this topic.
Dieses Feature von Exchange Server 2013 nicht vollständig kompatibel mit Office 365 von 21Vianet in China betrieben wird, und einige Einschränkungen gelten möglicherweise. Weitere Informationen finden Sie unter informieren Sie sich über Office 365 handelt, das von 21Vianet.This feature of Exchange Server 2013 isn’t fully compatible with Office 365 operated by 21Vianet in China and some feature limitations may apply. For more information, see Learn about Office 365 operated by 21Vianet.

Was sollten Sie wissen, bevor Sie beginnen?What do you need to know before you begin?

Tipp

Liegt ein Problem vor? Erhalten Sie in der Exchange-Foren. Besuchen Sie die Foren unter Exchange Server, Exchange Onlineoder Exchange Online Protection.Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server, Exchange Online, or Exchange Online Protection.

Wie konfigurieren Sie die OAuth-Authentifizierung zwischen Ihren lokalen Exchange- und den Exchange-Online-Organisationen?How do you configure OAuth authentication between your on-premises Exchange and Exchange Online organizations?

Schritt 1: Erstellen eines Autorisierungsserverobjekts für Ihre Exchange-Online-OrganisationStep 1: Create an authorization server object for your Exchange Online organization

Für dieses Verfahren müssen Sie eine überprüfte Domäne für die Exchange Online-Organisation angeben. Diese Domäne sollte der gleichen Domäne wie die primäre SMTP-Domäne für die Cloud-basierte e-Mail-Konten verwendet werden. Wird diese Domäne als bezeichnet * <der überprüften Domäne> * in das folgende Verfahren.For this procedure, you have to specify a verified domain for your Exchange Online organization. This domain should be the same domain used as the primary SMTP domain used for the cloud-based email accounts. This domain is referred as <your verified domain> in the following procedure.

Führen Sie in der Exchange-Verwaltungsshell (Exchange PowerShell) den folgenden Befehl für Ihre lokale Exchange-Organisation aus.Run the following command in the Exchange Management Shell (the Exchange PowerShell) in your on-premises Exchange organization.

    New-AuthServer -Name "WindowsAzureACS" -AuthMetadataUrl https://accounts.accesscontrol.windows.net/<your verified domain>/metadata/json/1

Schritt 2: Aktivieren der Partneranwendung für Ihre Exchange-Online-OrganisationStep 2: Enable the partner application for your Exchange Online organization

Führen Sie den folgenden Befehl in der Exchange PowerShell in Ihrer lokalen Exchange-Organisation aus.Run the following command in the Exchange PowerShell in your on-premises Exchange organization.

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

Schritt 3: Exportieren des lokalen AutorisierungszertifikatsStep 3: Export the on-premises authorization certificate

In diesem Schritt müssen Sie ein PowerShell-Skript ausführen, um das lokale Autorisierungszertifikat zu exportieren, welches dann im nächsten Schritt in Ihre Exchange-Online-Organisation importiert wird.In this step, you have to run a PowerShell script to export the on-premises authorization certificate, which is then imported to your Exchange Online organization in the next step.

  1. Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei, die etwa ExportAuthCert.ps1 benannt werden kann.Save the following text to a PowerShell script file named, for example, ExportAuthCert.ps1.

        $thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint
    
        if((test-path $env:SYSTEMDRIVE\OAuthConfig) -eq $false)
        {
            md $env:SYSTEMDRIVE\OAuthConfig
        }
        cd $env:SYSTEMDRIVE\OAuthConfig
    
        $oAuthCert = (dir Cert:\LocalMachine\My) | where {$_.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. Beispiel:In Exchange PowerShell in your on-premises Exchange organization, run the PowerShell script that you created in the previous step. For example:

    .\ExportAuthCert.ps1
    

Schritt 4: Hochladen des lokalen Autorisierungszertifikats auf Azure Active Directory ACSStep 4: Upload the on-premises authorization certificate to Azure Active Directory ACS

Im nächsten Schritt müssen Sie Windows PowerShell Verwenden des lokalen autorisierungszertifikats hochladen, die Sie im vorherigen Schritt auf Azure Active Directory Access Control Services (ACS) exportiert haben. Hierzu muss die Azure Active Directory-Modul für Windows PowerShell-Cmdlets installiert sein. Wenn dies nicht der Fall ist, fahren Sie mit https://aka.ms/aadposh So installieren Sie die Azure Active Directory-Modul für Windows PowerShell. Führen Sie die folgenden Schritte aus, nach der Azure Active Directory-Modul für Windows PowerShell installiert ist.Next, you have to use Windows PowerShell to upload the on-premises authorization certificate that you exported in the previous step to Azure Active Directory Access Control Services (ACS). To do this, the Azure Active Directory Module for Windows PowerShell cmdlets has to be installed. If it’s not installed, go to https://aka.ms/aadposh to install the Azure Active Directory Module for Windows PowerShell. Complete the following steps after the Azure Active Directory Module for Windows PowerShell is installed.

  1. Klicken Sie auf die Verknüpfung Azure Active Directory-Modul für Windows PowerShell, um einen Windows PowerShell-Arbeitsbereich zu öffnen, in dem die Azure AD-Cmdlets installiert sind. Alle Befehle in diesem Schritt werden unter Verwendung der Windows PowerShell für die Azure Active Directory-Konsole ausgeführt.Click the Azure Active Directory Module for Windows PowerShell shortcut to open a Windows PowerShell workspace that has the Azure AD cmdlets installed. All commands in this step will be run using the Windows PowerShell for Azure Active Directory console.

  2. Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei, die etwa UploadAuthCert.ps1 benannt werden kann.Save the following text to a PowerShell script file named, for example, UploadAuthCert.ps1.

        Connect-MsolService;
        Import-Module msonlineextended;
    
        $CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
    
        $objFSO = New-Object -ComObject Scripting.FileSystemObject;
        $CertFile = $objFSO.GetAbsolutePathName($CertFile);
    
        $cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
        $cer.Import($CertFile);
        $binCert = $cer.GetRawCertData();
        $credValue = [System.Convert]::ToBase64String($binCert);
    
        $ServiceName = "00000002-0000-0ff1-ce00-000000000000";
    
        $p = Get-MsolServicePrincipal -ServicePrincipalName $ServiceName
        New-MsolServicePrincipalCredential -AppPrincipalId $p.AppPrincipalId -Type asymmetric -Usage Verify -Value $credValue
    
  3. Führen Sie das PowerShell-Skript aus, welches Sie im vorherigen Schritt erstellt haben. Beispiel:Run the PowerShell script that you created in the previous step. For example:

    .\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 Azure AD-Organisation ein. Lassen Sie Windows PowerShell nach der Ausführung des Skripts für die Azure AD-Sitzung geöffnet. Sie werden diese zum Ausführen eines PowerShell-Skripts im nächsten Schritt erneut nutzen.After you start the script, a credentials dialog box is displayed. Enter the credentials for the tenant administrator account in your Microsoft Online Azure AD organization. After running the script, leave the Windows PowerShell for Azure AD session open. You will use this to run a PowerShell script in the next step.

Schritt 5: Registrieren aller Hostnamenautoritäten für Ihre externen lokalen Exchange HTTP-Endpunkte mit Azure Active DirectoryStep 5: Register all hostname authorities for your external on-premises Exchange HTTP endpoints with Azure Active Directory

Sie müssen das Skript in diesen Schritt für jeden Endpunkt in Ihrer lokalen Exchange-Organisation ausgeführt, der öffentlich zugänglich ist. Es wird empfohlen, dass Sie nach Möglichkeit Platzhalter verwenden. Nehmen wir beispielsweise an, dass Exchange extern auf https://mail.contoso.com/ews/exchange.asmx. In diesem Fall konnte ein Platzhalter verwendet werden: ** *. contoso.com**. Dies würde "autodiscover.contoso.com" und "Mail.contoso.com" Endpunkte behandelt. Es wird nicht jedoch die Domäne der obersten Ebene "contoso.com" erfassen. In Fällen, in dem Ihre Exchange 2013-Clientzugriffsservern mit der obersten Ebene Hostname Behörde extern zugegriffen werden kann, muss dieser Hostname Behörde auch als "contoso.com" registriert werden. Es ist kein Grenzwert für das Registrieren von zusätzlichen externen Hostname-Berechtigungen.You have to run the script in this step for each endpoint in your on-premises Exchange organization that is publically accessible. We recommended that you use wild cards, if possible. For example, assume that Exchange is externally available on https://mail.contoso.com/ews/exchange.asmx. In this case a single wildcard could be used: *.contoso.com. This would cover autodiscover.contoso.com and mail.contoso.com endpoints. However, it doesn't cover the top-level domain, contoso.com. In cases where your Exchange 2013 Client Access servers are externally accessible with the top-level hostname authority, this hostname authority must also be registered as contoso.com. There isn’t a limit for registering additional external hostname authorities.

Wenn Sie sich über die externen Exchange-Endpunkte in Ihrer lokalen Exchange-Organisation nicht sicher sind, können Sie eine Liste der extern konfigurierten Webdienst-Endpunkte beziehen, indem Sie den folgenden Befehl in der Exchange PowerShell Ihrer lokalen Exchange-Organisation ausführen:If you are not sure of the external Exchange endpoints in your on-premises Exchange organization, you can get a list of the external configured Web services endpoints by running the following command in Exchange PowerShell in your on-premises Exchange organization:

Get-WebServicesVirtualDirectory | FL ExternalUrl

Hinweis

Für eine erfolgreiche Ausführung des folgenden Skripts ist eine Verbindung der Windows PowerShell für Azure Active Directory mit Ihrem Microsoft Online Azure AD-Mandanten erforderlich, wie unter Schritt 4 im vorherigen Abschnitt erläutert.Successfully running the following script requires that the Windows PowerShell for Azure Active Directory is connected to your Microsoft Online Azure AD tenant, as explained in step 4 in the previous section.

  1. Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei, die etwa RegisterEndpoints.ps1 benannt werden kann. In diesem Beispiel wird ein Platzhalterzeichen verwendet, um alle Endpunkte auf contoso.com zu registrieren. Ersetzen Sie contoso.com durch eine Hostname-Stelle für Ihre lokale Exchange-Organisation.Save the following text to a PowerShell script file named, for example, RegisterEndpoints.ps1. This example uses a wildcard to register all endpoints for contoso.com. Replace contoso.com with a hostname authority for your on-premises Exchange organization.

        $externalAuthority="*.contoso.com"
    
        $ServiceName = "00000002-0000-0ff1-ce00-000000000000";
    
        $p = Get-MsolServicePrincipal -ServicePrincipalName $ServiceName;
    
        $spn = [string]::Format("{0}/{1}", $ServiceName, $externalAuthority);
        $p.ServicePrincipalNames.Add($spn);
    
        Set-MsolServicePrincipal -ObjectID $p.ObjectId -ServicePrincipalNames $p.ServicePrincipalNames;
    
  2. Führen Sie in Windows PowerShell für Azure Active Directory das PowerShell-Skript aus, das Sie im vorherigen Schritt erstellt haben. Beispiel:In Windows PowerShell for Azure Active Directory, run the Windows PowerShell script that you created in the previous step. For example:

    .\RegisterEndpoints.ps1
    

Schritt 6: Erstellen eines IntraOrganizationConnector aus Ihrer lokalen Organisation für Office 365Step 6: Create an IntraOrganizationConnector from your on-premises organization to Office 365

Sie müssen eine Zieladresse für Ihre Postfächer definieren, die in Exchange Online gehostet werden. Diese Zieladresse wird automatisch erstellt, wenn Ihr Office 365-Mandant erstellt wird. Wenn beispielsweise die im Office 365-Mandanten gehostete Domäne Ihrer Organisation "contoso.com" lautet, ist Ihre Zieldienstadresse "contoso.mail.onmicrosoft.com".You must define a target address for your mailboxes that are hosted in Exchange Online. This target address is created automatically when your Office 365 tenant is created. For example, if your organization’s domain hosted in the Office 365 tenant is "contoso.com", your target service address would be "contoso.mail.onmicrosoft.com".

Führen Sie unter Verwendung der Exchange PowerShell das folgende Cmdlet in Ihrer lokalen Organisation aus:Using Exchange PowerShell, run the following cmdlet in your on-premises organization:

    New-IntraOrganizationConnector -name ExchangeHybridOnPremisesToOnline -DiscoveryEndpoint https://outlook.office365.com/autodiscover/autodiscover.svc -TargetAddressDomains <your service target address>

Schritt 7: Erstellen eines IntraOrganizationConnector von Ihrem Office 365-Mandanten aus für Ihre lokale Exchange-OrganisationStep 7: Create an IntraOrganizationConnector from your Office 365 tenant to your on-premises Exchange organization

Sie müssen eine Zieladresse für die Postfächer definieren, die in Ihrer lokalen Organisation gehostet werden. Wenn die primäre SMTP-Adresse Ihrer Organisation "contoso.com" lautet, so ist dies "contoso.com".You must define a target address for your mailboxes that are hosted in your on-premises organization. If you organization’s primary SMTP adddress is "contoso.com", this would be "contoso.com".

Sie müssen außerdem den externen Autodiscover-Endpunkt für Ihre lokale Organisation definieren. Wenn Ihr Unternehmen "contoso.com" ist, so ist dies in der Regel einer der folgenden:You must also define the external Autodiscover endpoint for your on-premises organization. If your company is "contoso.com" this is usually either of the following:

  • https://autodiscover.<your primäre SMTP-Domäne>/autodiscover/autodiscover.svchttps://autodiscover.<your primary SMTP domain>/autodiscover/autodiscover.svc

  • https://<Ihre primäre SMTP-Domäne>/autodiscover/autodiscover.svchttps://<your primary SMTP domain>/autodiscover/autodiscover.svc

Hinweis

Sie können das Get-IntraOrganizationConfiguration-Cmdlet sowohl in Ihren lokalen als auch den Office 365-Mandanten verwenden, um die vom New-IntraOrganizationConnector-Cmdlet benötigten Endpunktwerte festzulegen.You can use the Get-IntraOrganizationConfiguration cmdlet in both your on-premises and Office 365 tenants to determine the endpoint values needed by New-IntraOrganizationConnector cmdlet.

Führen Sie unter Verwendung der Windows PowerShell das folgende Cmdlet aus:Using Windows PowerShell, run the following cmdlet:

    $UserCredential = Get-Credential
    
    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
    
    Import-PSSession $Session
    
    New-IntraOrganizationConnector -name ExchangeHybridOnlineToOnPremises -DiscoveryEndpoint <your on-premises Autodiscover endpoint> -TargetAddressDomains <your on-premises SMTP domain>

Schritt 8: Konfigurieren eines AvailabilityAddressSpace für alle Exchange-Server vor Version 2013 SP1Step 8: Configure an AvailabilityAddressSpace for any pre-Exchange 2013 SP1 servers

Wenn Sie eine Hybridbereitstellung in einer Organisation mit Exchange vor Version 2013 konfigurieren, müssen Sie mindestens einen Server mit Exchange 2013 SP1 oder höher mit den Clientzugriffs- und Postfachserverrollen in Ihrer vorhandenen Exchange-Organisation installieren. Die Exchange 2013-Clientzugriffs- und -Postfachserver fungieren als Front-End-Server und koordinieren die Kommunikation zwischen Ihrer vorhandenen lokalen Exchange-Organisation und der Exchange Online-Organisation. Diese Kommunikation beinhaltet auch den Nachrichtentransport zwischen der lokalen und der Exchange Online-Organisation sowie Messagingfunktionen. Für eine bessere Zuverlässigkeit und höhere Verfügbarkeit der Funktionen der Hybridbereitstellung sollten Sie mehrere Exchange 2013-Server in der lokalen Organisation installieren.When you configure a hybrid deployment in a pre-Exchange 2013 organization, you have to install at least one Exchange 2013 SP1 or greater server with the Client Access and Mailbox server roles in your existing Exchange organization. The Exchange 2013 Client Access and Mailbox servers serve as frontend servers and coordinate communications between your existing Exchange on-premises organization and the Exchange Online organization. This communication includes message transport and messaging features between the on-premises and Exchange Online organizations. We highly recommend installing more than one Exchange 2013 server in your on-premises organization to help increase reliability and availability of hybrid deployment features.

In einer gemischten Bereitstellung mit Exchange 2013/2010 oder Exchange 2013/2007 wird empfohlen, dass alle mit dem Internet verbundenen Front-End-Server für Ihre lokale Organisation Clientzugriffsserver sind, auf denen Exchange 2013 SP1 oder höher ausgeführt wird. Alle Exchange-Webdienste-Anforderungen, die von Office 365 und Exchange Online stammen, müssen eine Verbindung zu einem Exchange 2013-Clientzugriffsserver in Ihrer lokalen Bereitstellung herstellen. Darüber hinaus müssen alle Exchange-Webdienste-Anforderungen für Exchange Online, die von Ihren lokalen Exchange-Organisationen stammen, mittels Proxy über einen Clientzugriffsserver weitergeleitet werden, auf dem Exchange 2013 SP1 oder höher ausgeführt wird. Da diese Exchange 2013-Clientzugriffsserver diese zusätzlichen eingehenden und ausgehenden Exchange-Webdienste-Anforderungen verarbeiten müssen, ist es wichtig, eine ausreichende Anzahl von Exchange 2013-Clientzugriffsservern verfügbar zu haben, um die Verarbeitungslast handhaben und Verbindungsredundanz bereitstellen zu können. Die Anzahl der erforderlichen Clientzugriffsserver hängt von der durchschnittlichen Menge von Exchange-Webdienste-Anforderungen ab und ist je nach Organisation unterschiedlich.In a mixed deployment with Exchange 2013/2010 or Exchange 2013/2007, it is recommended that all the Internet-facing frontend servers for your on-premises organization are Client Access servers running Exchange 2013 SP1 or greater. All Exchange Web Services (EWS) requests originating from Office 365 and Exchange Online must connect to an Exchange 2013 Client Access server(s) in your on-premises deployment. Additionally, all EWS requests originating in your on-premises Exchange organizations for Exchange Online must be proxied through a Client Access server running Exchange 2013 SP1 or greater. Since these Exchange 2013 Client Access servers have to handle this additional incoming and outgoing EWS requests, it is important to have a sufficient number of Exchange 2013 Client Access servers available to handle the processing load and provide connection redundancy. The number of Client Access servers needed will depend on the average amount of EWS requests and will vary by organization.

Bevor Sie den folgenden Schritt ausführen, stellen Sie Folgendes sicher:Before you complete the following step, make sure:

  • Auf den Front-End-Hybridservern wird Exchange 2013 SP1 oder höher ausgeführt.The frontend hybrid servers are Exchange 2013 SP1 or greater

  • Sie verfügen über eine eindeutige externe Exchange-Webdienste-URL für die Exchange 2013-Server. Der Office 365-Mandant muss eine Verbindung mit diesen Servern herstellen, damit cloudbasierte Anforderungen für Hybridfunktionen ordnungsgemäß ausgeführt werden.You have a unique external EWS URL for the Exchange 2013 server(s). The Office 365 tenant must connect to these servers in order for cloud-based requests for hybrid features to work correctly.

  • Die Server verfügen sowohl über die Postfach- als auch die Clientzugriffsrolle.The servers have both the Mailbox and Client Access server roles

  • Für alle vorhandenen Exchange 2010/2007-Postfach- und -Clientzugriffsserver wurde das neueste kumulative Update oder Service Pack (SP) angewendet.Any existing Exchange 2010/2007 Mailbox and Client Access servers have the latest Cumulative Update (CU) or Service Pack (SP) applied.

    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 bei Anforderungen für Hybridbereitstellungsfunktionen vom Office 365-Mandanten muss eine Verbindung mit Exchange 2013-Servern hergestellt werden.Existing Exchange 2010/2007 Mailbox servers can continue to use Exchange 2010/2007 Client Access servers for frontend servers for non-hybrid feature connections. Only hybrid deployment feature requests from the Office 365 tenant need to connect to Exchange 2013 servers.

Ein AvailabilityAddressSpace muss konfiguriert sein, auf vor Exchange 2013-Clientzugriffsservern, die an den Exchange-Webdienste-Endpunkt, von einem lokalen Exchange 2013 SP1-Clientzugriffsserver erfolgt verweist. Dieser Endpunkt ist dieselbe IP-Adresse, wie zuvor in Schritt 5 beschriebenen oder bestimmt werden kann, indem Sie das folgende Cmdlet auf Ihrem lokalen Exchange 2013 SP1-Clientzugriffs-Server ausführen:An AvailabilityAddressSpace must be configured on pre-Exchange 2013 Client Access servers that points to the Exchange Web Services endpoint of your on-premises Exchange 2013 SP1 Client Access server(s). This endpoint is the same endpoint as previously outlined in Step 5 or can be determined by running the following cmdlet on your on-premises Exchange 2013 SP1 Client Access server:

Get-WebServicesVirtualDirectory | FL AdminDisplayVersion,ExternalUrl

Hinweis

Wenn virtuelle Verzeichnisinformationen von mehreren Servern zurückgegeben wird, stellen Sie sicher, mit denen Sie den Endpunkt für einen Exchange 2013 SP1-Clientzugriffs-Server zurückgegeben. Daraufhin wird 15.0 (Build 847.32) angezeigt oder höher für den Parameter AdminDisplayVersion .If virtual directory information is returned from multiple servers, make sure you use the endpoint returned for an Exchange 2013 SP1 Client Access server. It will display 15.0 (Build 847.32) or higher for the AdminDisplayVersion parameter.

Um den AvailabilityAddressSpacezu konfigurieren, verwenden Sie Exchange PowerShell, und führen Sie das folgende Cmdlet in Ihrer lokalen Organisation:To configure the AvailabilityAddressSpace, use Exchange PowerShell and run the following cmdlet in your on-premises organization:

    Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl <your on-premises External Web Services URL> -ForestName <your Office 365 service target address> -UseServiceAccount $True

Woher wissen Sie, dass dieses Verfahren erfolgreich war?How do you know this worked?

Sie können die Korrektheit der OAuth-Konfiguration verifizieren, indem Sie das Test-OAuthConnectivity-Cmdlet verwenden. Mit diesem Cmdlet kann überprüft werden, ob die lokalen Exchange- und Exchange Online-Endpunkte erfolgreich gegenseitige Anforderungen authentifizieren können.You can verify that the OAuth configuration is correct by using the Test-OAuthConnectivity cmdlet. This cmdlet verifies that the on-premises Exchange and Exchange Online endpoints can successful authenticate requests from each other.

Wichtig

Bei der Verbindung mit Ihrer Remote-PowerShell mit Exchange Online-Organisation müssen Sie möglicherweise den Parameter AllowClobber mit dem Import-PSSession -Cmdlet verwenden, um die neuesten Befehle in in die lokale PowerShell-Sitzung zu importieren.When connecting to your Exchange Online organization using Remote PowerShell, you may have to use the AllowClobber parameter with the Import-PSSession cmdlet to import the latest commands in to the local PowerShell session.

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:To verify that your on-premises Exchange organization can successfully connect to Exchange Online, run the following command in Exchange PowerShell in your on-premises organization:

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

Wenn Sie überprüfen möchten, ob Ihre Exchange Online-Organisation erfolgreich eine Verbindung mit Ihrer lokalen Exchange-Organisation herstellen kann, verwenden Sie Remote PowerShell, um die Verbindung mit Ihrer Exchange Online-Organisation aufzubauen, und führen Sie den folgenden Befehl aus:To verify that your Exchange Online organization can successfully connect to your on-premises Exchange organization, use the Remote PowerShell to connect to your Exchange Online organization and run the following command:

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

Beispiel: Test-OAuthConnectivity -Service EWS -TargetUri https://lync.contoso.com/metadata/json/1 -Mailbox ExchangeOnlineBox1 -Verbose | flSo, as an example, Test-OAuthConnectivity -Service EWS -TargetUri https://lync.contoso.com/metadata/json/1 -Mailbox ExchangeOnlineBox1 -Verbose | fl

Wichtig

Sie können die Fehlermeldung "Der SMTP-Adresse ist kein Postfach zugeordnet." ignorieren. Es ist lediglich von Bedeutung, dass der Parameter ResultTask einen Wert über den Erfolg zurückgibt. Der letzte Abschnitt des Testergebnisses sollte beispielsweise wie folgt lauten:You can ignore the “The SMTP address has no mailbox associated with it.” error. It’s only important that the ResultTask parameter returns a value of Success. For example, the last section of the test output should read:
ResultType: Success
Identity: Microsoft.Exchange.Security.OAuth.ValidationResultNodeId
IsValid: True
ObjectState: New

Tipp

Liegt ein Problem vor? Erhalten Sie in der Exchange-Foren. Besuchen Sie die Foren unter Exchange Server, Exchange Onlineoder Exchange Online Protection.Having problems? Ask for help in the Exchange forums. Visit the forums at Exchange Server, Exchange Online, or Exchange Online Protection.