Konfigurieren von Exchange-Hybridbereitstellungsfunktionen mit Office 365, betrieben von 21Vianet
Hinweis: Dieser Artikel gilt nur für Office 365, das von 21Vianet in China betrieben wird, und für lokale Exchange-Organisationen, die nicht auf Exchange 2013 CU5 oder höher aktualisieren können.
Voll ausgestattete Hybridbereitstellungen zwischen lokalen Exchange 2013 CU5-Organisationen und Office 365-Diensten werden jetzt unterstützt. Wenn Sie jedoch kein Upgrade auf Exchange 2013 CU5 durchführen oder es in Ihrer lokalen Organisation nicht installieren können, können Sie dennoch die Frei/Gebucht-Kalenderfreigabe zwischen Ihren lokalen Exchange- und Exchange Online-Organisationen konfigurieren.
Führen Sie die folgenden Schritte aus, um diese Hybridbereitstellungsfunktion für Ihre lokalen und Exchange Online-Organisationen zu aktivieren.
Schritt 1: Erstellen Sie ein Autorisierungsserverobjekt für Ihre Exchange Online-Organisation
Für dieses Verfahren müssen Sie eine verifizierte Domäne für Ihre Exchange Online-Organisation angeben. Bei dieser Domäne sollte es sich um dieselbe Domäne handeln, die auch als primäre SMTP-Domäne für die cloudbasierten E-Mail-Konten verwendet wird. Diese Domäne wird im folgenden Verfahren als <Ihre verifizierte Domäne> bezeichnet.
Führen Sie den folgenden Befehl in der Exchange-Verwaltungsshell (Exchange PowerShell) in Ihrer lokalen Exchange-Organisation aus.
New-AuthServer -Name "MicrosoftAzureACS" -AuthMetadataUrl https://accounts.accesscontrol.chinacloudapi.cn/<your verified-domain>/metadata/json/1
Schritt 2: Aktivieren Sie die Partneranwendung für Ihre Exchange Online-Organisation
Führen Sie den folgenden Befehl in Exchange PowerShell in Ihrer lokalen Exchange-Organisation aus.
Get-PartnerApplication | ?{$_.ApplicationIdentifier -eq "00000002-0000-0ff1-ce00-000000000000"-and $_.Realm -eq ""} | Set-PartnerApplication -Enabled $true
Schritt 3: Exportieren Sie das lokale Autorisierungszertifikat
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-Organisation importiert wird.
Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei mit dem Namen beispielsweise ExportAuthCert.ps1 .
$thumbprint = (get-authconfig).CurrentCertificateThumbprintif((test-path $env:SYSTEMDRIVE\OAuthConfig) -eq $false){ md $env:SYSTEMDRIVE\OAuthConfig}cd $env:SYSTEMDRIVE\OAuthConfig $oAuthCert = (dir Cert: \LocalMachine\My) | wobei {$_.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-Organisation das PowerShell-Skript aus, das Sie im vorherigen Schritt erstellt haben. Zum Beispiel:
.\ExportAuthCert.ps1
Schritt 4: Laden Sie das lokale Autorisierungszertifikat in Microsoft Azure Active Directory ACS hoch
Als Nächstes müssen Sie Windows PowerShell verwenden, um das lokale Autorisierungszertifikat, das Sie im vorherigen Schritt exportiert haben, in Microsoft Azure Active Directory Access Control Services (ACS) hochzuladen. Dazu muss das Microsoft Azure Active Directory (AD)-Modul für Windows PowerShell-Cmdlets installiert werden. Wenn es nicht installiert ist, gehen Sie zu http://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 ist.
Klicken Sie auf die Verknüpfung „Microsoft Azure Active Directory-Modul für Windows PowerShell" , um einen Windows PowerShell-Arbeitsbereich zu öffnen, in dem die Microsoft Azure AD-Cmdlets installiert sind. Alle Befehle in diesem Schritt werden mit der Windows PowerShell für Microsoft Azure Active Directory-Konsole ausgeführt.
Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei mit dem Namen beispielsweise 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. Zum Beispiel:
.\UploadAuthCert.ps1
Nachdem Sie das Skript gestartet haben, wird ein Dialogfeld mit Anmeldeinformationen angezeigt. Geben Sie die Anmeldeinformationen für das Mandantenadministratorkonto in Ihrer Microsoft Online Microsoft Azure AD-Organisation 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 Sie alle Hostnamenautoritäten für Ihre externen lokalen Exchange-HTTP-Endpunkte bei Microsoft Azure Active Directory
Sie müssen darin für jeden Endpunkt in Ihrer lokalen Exchange-Organisation, der öffentlich zugänglich ist, ein Skript ausführen. Wir empfehlen, wenn möglich, Platzhalter zu verwenden. Nehmen Sie beispielsweise an, dass Exchange extern unter https://mail.contoso.com/ews/exchange.asmx verfügbar ist. In diesem Fall könnte ein einzelner Platzhalter verwendet werden: *.contoso.com . Dies würde die Endpunkte autodiscover.contoso.com und mail.contoso.com abdecken. Die Top-Level-Domäne contoso.com wird jedoch nicht abgedeckt. In Fällen, in denen Ihre Exchange 2013-Clientzugriffsserver von außen mit der Hostnamen-Autorität der obersten Ebene zugänglich sind, muss diese Hostnamen-Autorität auch als contoso.com registriert werden. Es gibt keine Beschränkung für die Registrierung zusätzlicher externer Hostnamen-Autoritäten.
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 abrufen, indem Sie den folgenden Befehl in Exchange PowerShell in Ihrer lokalen Exchange-Organisation ausführen:
Get-WebServicesVirtualDirectory | FL ExternalUrl
Hinweis: Für die erfolgreiche Ausführung des folgenden Skripts ist es erforderlich, dass Windows PowerShell für Microsoft Azure Active Directory mit Ihrem Microsoft Online Microsoft Azure AD-Mandanten verbunden ist, wie in Schritt 4 im vorherigen Abschnitt erläutert.
Speichern Sie den folgenden Text in einer PowerShell-Skriptdatei mit dem Namen beispielsweise RegisterEndpoints.ps1 . In diesem Beispiel wird ein Platzhalter verwendet, um alle Endpunkte für contoso.com zu registrieren. Ersetzen Sie contoso.com durch eine Hostnamenautorität für Ihre lokale Exchange-Organisation.
$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. Zum Beispiel:
.\RegisterEndpoints.ps1
Schritt 6: Erstellen Sie einen IntraOrganizationConnector von Ihrer lokalen Organisation zu 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 die im Office 365-Mandanten gehostete Domäne Ihrer Organisation beispielsweise „contoso.com" lautet, lautet Ihre Zieldienstadresse „contoso.partner.mail.onmschina.cn".
Führen Sie mit Exchange PowerShell das folgende Cmdlet in Ihrer lokalen Organisation aus:
New-IntraOrganizationConnector -name ExchangeHybridOnPremisesToOnline -DiscoveryEndpoint https://partner.outlook.cn/autodiscover/autodiscover.svc -TargetAddressDomains <your service target address>
Schritt 7: Erstellen Sie einen IntraOrganizationConnector von Ihrem Office 365-Mandanten zu Ihrer lokalen Exchange-Organisation
Sie müssen eine Zieladresse für Ihre Postfächer definieren, die in Ihrer lokalen Organisation gehostet werden. Wenn die primäre SMTP-Adresse Ihrer Organisation „contoso.com" lautet, wäre dies „contoso.com".
Sie müssen auch den externen Autodiscover-Endpunkt für Ihre lokale Organisation definieren. Wenn Ihr Unternehmen „contoso.com" ist, ist dies normalerweise eines der folgenden:
https://autodiscover.<Ihre primäre SMTP-Domäne>/autodiscover/autodiscover.svc
https://<Ihre primäre SMTP-Domäne>/autodiscover/autodiscover.svc
Hinweis: Sie können das Cmdlet „Get-IntraOrganizationConfiguration" sowohl in Ihren lokalen als auch in Ihren Office 365-Mandanten verwenden, um die vom Cmdlet „New-IntraOrganizationConnector" benötigten Endpunktwerte zu ermitteln.
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 Sie einen AvailabilityAddressSpace für alle Server vor Exchange 2013 SP1
Wenn Sie eine Hybridbereitstellung in einer Organisation vor Exchange 2013 konfigurieren, müssen Sie in Ihrer vorhandenen Exchange-Organisation mindestens einen Server mit Exchange 2013 SP1 oder höher mit den Serverrollen „Clientzugriff" und „Postfach" installieren. Die Clientzugriffs- und Postfachserver von Exchange 2013 dienen als Front-End-Server und koordinieren die Kommunikation zwischen Ihrer vorhandenen lokalen Exchange-Organisation und der Exchange Online-Organisation. Diese Kommunikation umfasst Nachrichtentransport- und Messagingfunktionen zwischen den lokalen und Exchange Online-Organisationen. Wir empfehlen dringend, mehr als einen Exchange 2013-Server in Ihrer lokalen Organisation zu installieren, um die Zuverlässigkeit und Verfügbarkeit der Hybridbereitstellungsfunktionen zu erhöhen.
Bei 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 Web Services (EWS)-Anfragen, die von Office 365 und Exchange Online stammen, müssen eine Verbindung zu einem oder mehreren Exchange 2013-Clientzugriffsservern in Ihrer lokalen Bereitstellung herstellen. Darüber hinaus müssen alle EWS-Anfragen, die von Ihren lokalen Exchange-Organisationen für Exchange Online stammen, ü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 EWS-Anfragen verarbeiten müssen, ist es wichtig, über eine ausreichende Anzahl von Exchange 2013-Clientzugriffsservern zu 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-Anfragen 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 EWS-URL für den/die Exchange 2013-Server. Der Office 365-Mandant muss eine Verbindung zu diesen Servern herstellen, damit cloudbasierte Anforderungen für Hybridfunktionen ordnungsgemäß funktionieren.
Die Server verfügen sowohl über die Serverrollen „Postfach" als auch „Clientzugriff".
Auf allen vorhandenen Exchange 2010/2007-Postfach- und Clientzugriffsservern ist das neueste kumulative Update (CU) oder Service Pack (SP) installiert.
Hinweis: Vorhandene Exchange 2010/2007-Postfachserver können weiterhin Exchange 2010/2007-Clientzugriffsserver für Front-End-Server für nicht-hybride Funktionsverbindungen verwenden. Nur Hybridbereitstellungsfunktionsanfragen vom Office 365-Mandanten müssen eine Verbindung zu Exchange 2013-Servern herstellen.
Konfigurieren Sie den Proxy für ausgehende Exchange-Webdienste für Server vor Exchange 2013
Es muss ein AvailabilityAddressSpace konfiguriert werden, der auf den Exchange-Webdienste-Endpunkt 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 ermittelt werden:
Get-WebServicesVirtualDirectory | FL AdminDisplayVersion,ExternalUrl
Hinweis: Wenn Informationen zu virtuellen Verzeichnissen von mehreren Servern zurückgegeben werden, stellen Sie sicher, dass Sie den zurückgegebenen Endpunkt für einen Exchange 2013 SP1-Clientzugriffsserver verwenden. Für den Parameter AdminDisplayVersion wird 15.0 (Build 847.32) oder höher angezeigt.
Um den AvailabilityAddressSpace zu konfigurieren, verwenden Sie Exchange PowerShell und führen Sie das folgende Cmdlet in Ihrer lokalen Organisation 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, dass das funktioniert hat?
Mit dem Cmdlet Test_OAuthConnectivity können Sie überprüfen, ob die OAuth-Konfiguration korrekt ist. Dieses Cmdlet überprüft, ob die lokalen Exchange- und Exchange Online-Endpunkte gegenseitige Anforderungen erfolgreich authentifizieren können.
Wichtig: Wenn Sie über Remote PowerShell eine Verbindung zu Ihrer Exchange Online-Organisation herstellen, müssen Sie möglicherweise den Parameter „AllowClobber " mit dem Cmdlet „ Import- PSSession " verwenden, um die neuesten Befehle in die lokale PowerShell-Sitzung zu importieren.
Um zu überprüfen, ob Ihre lokale Exchange-Organisation erfolgreich eine Verbindung zu Exchange Online herstellen kann, führen Sie den folgenden Befehl in Exchange PowerShell in Ihrer lokalen Organisation aus:
Test-OAuthConnectivity -Service EWS -TargetUri https://partner.outlook.cn/ews/exchange.asmx -Mailbox <On-Premises Mailbox> -Verbose | fl
Um zu überprüfen, ob Ihre Exchange Online-Organisation erfolgreich eine Verbindung zu Ihrer lokalen Exchange-Organisation herstellen kann, verwenden Sie Remote PowerShell, um eine Verbindung zu Ihrer Exchange Online-Organisation 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
Wichtig: Sie können die Meldung „Der SMTP-Adresse ist kein Postfach zugeordnet" ignorieren. Fehler. Wichtig ist nur, dass der ResultTask-Parameter den Wert Success zurückgibt. Der letzte Abschnitt der Testausgabe sollte beispielsweise lauten:
ResultType: Success
Identity: Microsoft.Exchange.Security.OAuth.ValidationResultNodeId
IsValid: True
ObjectState: New
No comments:
Post a Comment