Konfigurieren von Exchange-Hybridbereitstellungsfeatures mit Office 365, betrieben von 21Vianet

Hybridbereitstellungen mit vollem Funktionsumfang zwischen lokalen Exchange 2013 CU5-Organisationen und Microsoft 365-Diensten werden jetzt unterstützt. Wenn Sie jedoch kein Upgrade auf Exchange 2013 CU5 in Ihrem lokalen organization durchführen oder diese installieren können, können Sie trotzdem die Frei/Gebucht-Kalenderfreigabe und zwischen Ihrer lokalen Exchange- und Exchange Online-Organisation konfigurieren.

Führen Sie die folgenden Schritte aus, um dieses Hybridbereitstellungsfeature für Ihre lokalen und Exchange Online Organisationen zu aktivieren.

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

Für dieses Verfahren müssen Sie eine überprüfte Domäne für Ihre Exchange Online organization angeben. Diese Domäne sollte dieselbe Domäne sein, die wie die primäre SMTP-Domäne verwendet wird, die für die cloudbasierten E-Mail-Konten verwendet wird. Diese Domäne wird im folgenden Verfahren als <Ihre überprüfte Domäne> bezeichnet.

Führen Sie den folgenden Befehl in der Exchange-Verwaltungsshell (Exchange PowerShell) in Ihrem lokalen Exchange-organization aus.

New-AuthServer -Name "MicrosoftAzureACS" -AuthMetadataUrl https://accounts.accesscontrol.chinacloudapi.cn/<your tenant initial domain>/metadata/json/1

New-AuthServer -Name "EvoSTS" -Type AzureAD -AuthMetadataUrl "https://login.chinacloudapi.cn/<your tenant initial domain>/federationmetadata/2007-06/federationmetadata.xml"

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

Führen Sie den folgenden Befehl in Exchange PowerShell in Ihrer lokalen Exchange-organization 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 ausführen, um das lokale Autorisierungszertifikat zu exportieren, das dann im nächsten Schritt in Ihre Exchange Online organization importiert wird.

Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei namens, z. B.ExportAuthCert.ps1.

$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)

Führen Sie in Exchange PowerShell in Ihrer lokalen Exchange-organization das PowerShell-Skript aus, das Sie im vorherigen Schritt erstellt haben. Beispiel:

.\ExportAuthCert.ps1

Schritt 4: Hochladen des lokalen Autorisierungszertifikats auf Microsoft Entra Access Control Server (ACS)

Als Nächstes müssen Sie Windows PowerShell verwenden, um das lokale Autorisierungszertifikat hochzuladen, das Sie im vorherigen Schritt in Microsoft Azure Active Directory Access Control Services (ACS) exportiert haben. Dazu muss das Microsoft Azure Active Directory -Modul (AD) für Windows PowerShell-Cmdlets installiert werden. Wenn es nicht installiert ist, wechseln Sie zu https://aka.ms/aadposh, um das Microsoft Azure AD-Modul zu installieren. Führen Sie die folgenden Schritte aus, nachdem das Microsoft Azure AD Modul installiert wurde.

Klicken Sie auf die Verknüpfung Microsoft Azure Active Directory Module for Windows PowerShell, um einen Windows PowerShell Arbeitsbereich zu öffnen, in dem die Microsoft Azure AD-Cmdlets installiert sind. Alle Befehle in diesem Schritt werden mithilfe des Windows PowerShell für Microsoft Azure Active Directory Konsole ausgeführt.

Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei namens, z. B.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 $ServiceNameNew-MsolServicePrincipalCredential -AppPrincipalId $p.AppPrincipalId -Type asymmetric -Usage Verify -Value $credValue

Führen Sie das PowerShell-Skript aus, das Sie im vorherigen Schritt erstellt haben. Beispiel:

.\UploadAuthCert.ps1

Nachdem Sie das Skript gestartet haben, wird ein Dialogfeld mit den Anmeldeinformationen angezeigt. Geben Sie die Anmeldeinformationen für das Mandantenadministratorkonto in Ihrem Microsoft Online-Microsoft Azure AD organization ein. Lassen Sie nach dem Ausführen des Skripts die Windows PowerShell für Microsoft Azure Active Directory Sitzung geöffnet. Damit führen Sie im nächsten Schritt ein PowerShell-Skript aus.

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

Sie müssen in diesem Skript für jeden Endpunkt in Ihrer lokalen Exchange-organization ausführen, auf die öffentlich zugegriffen werden kann. Es wird empfohlen, nach Möglichkeit Wildcards zu verwenden. Angenommen, Exchange ist auf https://mail.contoso.com/ews/exchange.asmx extern verfügbar. In diesem Fall könnte ein einzelner Wildcard verwendet werden: *.contoso.com. Dies würde autodiscover.contoso.com- und mail.contoso.com-Endpunkte abdecken. Es deckt jedoch nicht die Domäne der obersten Ebene ab, contoso.com. In Fällen, in denen auf Ihre Exchange 2013-Clientzugriffsserver extern mit der Hostnamenautorität der obersten Ebene zugegriffen werden kann, muss diese Hostnamenautorität auch als contoso.com registriert werden. Es gibt keine Beschränkung für die Registrierung zusätzlicher externer Hostnamen-Autoritäten.

Wenn Sie die externen Exchange-Endpunkte in Ihrer lokalen Exchange-organization nicht sicher sind, können Sie eine Liste der externen konfigurierten Webdienstendpunkte abrufen, indem Sie den folgenden Befehl in Exchange PowerShell in Ihrer lokalen Exchange-organization ausführen:

Get-WebServicesVirtualDirectory | FL ExternalUrl

Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei namens, z. B.RegisterEndpoints.ps1. In diesem Beispiel wird ein Wildcard verwendet, um alle Endpunkte für contoso.com zu registrieren. Ersetzen Sie contoso.com durch eine Hostnamenautorität für Ihre lokale 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

Führen Sie in Windows PowerShell für Microsoft Azure Active Directory das PowerShell-Skript aus, das Sie im vorherigen Schritt erstellt haben. Beispiel:

.\RegisterEndpoints.ps1

Schritt 6: Erstellen eines IntraOrganizationConnector aus Ihrem lokalen organization zu Microsoft 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 Microsoft 365-Mandant erstellt wird. Wenn beispielsweise die Domäne Ihres organization, die im Microsoft 365-Mandanten gehostet wird, "contoso.com" lautet, lautet Ihre Zieldienstadresse "contoso.partner.mail.onmschina.cn".

Führen Sie mithilfe von Exchange PowerShell das folgende Cmdlet in Ihrer lokalen organization aus:

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

Schritt 7: Erstellen eines IntraOrganizationConnector von Ihrem Microsoft 365-Mandanten zu Ihrem lokalen Exchange-organization

Sie müssen eine Zieladresse für Ihre Postfächer definieren, die in Ihrer lokalen organization gehostet werden. Wenn Sie organization primäre SMTP-Adresse "contoso.com" lautet, lautet dies "contoso.com".

Sie müssen auch den externen AutoErmittlungsendpunkt für Ihre lokale organization definieren. Wenn Ihr Unternehmen "contoso.com" ist, ist dies in der Regel einer der folgenden:

• https://autodiscover.<Ihre primäre SMTP-Domäne>/autoDiscover/autodiscover.svc
• <https:// Ihre primäre SMTP-Domäne>/autodiscover/autodiscover.svc

Führen Sie mit Windows PowerShell das folgende Cmdlet aus:

$UserCredential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://partner.outlook.cn/powershell-liveid/ -Credential $UserCredential

Import-PSSession $Session

New-IntraOrganizationConnector -name ExchangeHybridOnlineToOnPremises -DiscoveryEndpoint <your on-premises-Autodiscover endpoint> -TargetAddressDomains <your on-premises target address>

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

Wenn Sie eine Hybridbereitstellung in einem organization vor Exchange 2013 konfigurieren, müssen Sie mindestens einen Exchange 2013 SP1-Server mit den Serverrollen Clientzugriff und Postfach in Ihrem vorhandenen Exchange-organization installieren. Die Exchange 2013-Clientzugriffs- und Postfachserver dienen als Front-End-Server und koordinieren die Kommunikation zwischen Ihren vorhandenen lokalen Exchange-organization und dem Exchange Online organization. Diese Kommunikation umfasst Nachrichtentransport- und Messagingfeatures zwischen lokalen und Exchange Online Organisationen. Es wird dringend empfohlen, mehr als einen Exchange 2013-Server in Ihrer lokalen organization zu installieren, um die Zuverlässigkeit und Verfügbarkeit von Hybridbereitstellungsfeatures zu erhöhen.

In einer gemischten Bereitstellung mit Exchange 2013/2010 oder Exchange 2013/2007 wird empfohlen, dass alle Front-End-Server mit Internetzugriff für Ihre lokalen organization Clientzugriffsserver mit Exchange 2013 SP1 oder höher sind. Alle Exchange-Webdienste (EWS)-Anforderungen, die von Microsoft 365 und Exchange Online stammen, müssen eine Verbindung mit einem Exchange 2013-Clientzugriffsserver in Ihrer lokalen Bereitstellung herstellen. Darüber hinaus müssen alle EWS-Anforderungen, die aus Ihren lokalen Exchange-Organisationen für Exchange Online stammen, über einen Clientzugriffsserver mit Exchange 2013 SP1 oder höher per Proxy übertragen werden. Da diese Exchange 2013-Clientzugriffsserver diese zusätzlichen ein- und ausgehenden EWS-Anforderungen verarbeiten müssen, ist es wichtig, dass eine ausreichende Anzahl von Exchange 2013-Clientzugriffsservern verfügbar ist, um die Verarbeitungslast zu verarbeiten und Verbindungsredundanz bereitzustellen. Die Anzahl der benötigten Clientzugriffsserver hängt von der durchschnittlichen Anzahl der EWS-Anforderungen ab und variiert je nach organization.

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 EWS-URL für die Exchange 2013-Server. Der Microsoft 365-Mandant muss eine Verbindung mit diesen Servern herstellen, damit cloudbasierte Anforderungen für Hybridfeatures ordnungsgemäß funktionieren.
• Die Server verfügen über die Serverrollen "Postfach" und "Clientzugriff".
• Auf alle vorhandenen Exchange 2010/2007-Postfach- und Clientzugriffsserver wurde das neueste kumulative Update (CU) oder Service Pack (SP) angewendet.

Konfigurieren des Proxys für ausgehende Exchange-Webdienste für Server vor Exchange 2013

Es muss ein AvailabilityAddressSpace konfiguriert werden, der auf den Exchange-Webdienstendpunkt Ihres lokalen Exchange 2013 SP1-Clientzugriffsservers verweist. Dieser Endpunkt ist derselbe Endpunkt wie zuvor in Schritt 5 beschrieben oder kann durch Ausführen des folgenden Cmdlets auf Ihrem lokalen Exchange 2013 SP1-Clientzugriffsserver bestimmt werden:

Get-WebServicesVirtualDirectory | FL AdminDisplayVersion,ExternalUrl

Verwenden Sie zum Konfigurieren von AvailabilityAddressSpace Exchange PowerShell, und führen Sie das folgende Cmdlet in Ihrer lokalen organization aus:

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

Woher wissen Sie, ob dieser Vorgang erfolgreich war?

Sie können überprüfen, ob die OAuth-Konfiguration korrekt ist, indem Sie das Cmdlet Test_OAuthConnectivity verwenden. Dieses Cmdlet überprüft, ob die lokalen Exchange- und Exchange Online-Endpunkte anforderungen voneinander erfolgreich authentifizieren können.

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

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

Um zu überprüfen, ob Ihr Exchange Online organization erfolgreich eine Verbindung mit Ihrem lokalen Exchange-organization herstellen kann, verwenden Sie die Remote-PowerShell, um eine Verbindung mit Ihrem Exchange Online organization herzustellen, und führen Sie den folgenden Befehl aus:

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

ResultType: Success

Identity: Microsoft.Exchange.Security.OAuth.ValidationResultNodeId

IsValid: True

ObjectState: New