HCW im Detail

Auf der Seite Hybrid Configuration Wizard habe ich einen schnellen Marsch durch den Assistenten einer Hybrid-Umgebung gemacht. Auch wenn ein Assistent vieles alleine macht, möchte ich schon wissen, was dabei im Hintergrund passiert. Das beschreibe ich auf dieser Seite. Dazu nutze ich einfach einen "frisch gestarteten" HCW, der in seinem Logfile ausführlich protokolliert, was er getan hat. Einige Aktionen können nämlich durchaus "Auswirkungen" auf ihre Umgebung haben. Daher habe ich mal ein Logfile auseinander genommen, welches Sie auf ihrem PC auch finden können.

C:\Users\%username%\AppData\Roaming\Microsoft\Exchange Hybrid Configuration\

Hinweis:
Der HCW ist sehr dynamisch, d.h. Microsoft bekommt per Default von jedem Fehler eine Rückmeldung und die Produktgruppe ist laufend dabei den HCW zu aktualisieren und Fehler zu vermeiden. Wenn Sie also einen Fehler haben, dann können Sie gerne ein Ticket bei Microsoft eröffnen. Wenn Sie aber sicher sind, dass bei ihnen alles in Ordnung ist, dann können Sie auch einfach mal ein paar Tage warten. Oftmals ist die nächste Version schon etwas schlauer.

Microsoft aktualisiert den HCW häufiger, als ich ihn ausführen und die Logs analysieren kann. Wenn Sie meinen, dass meine Auflistung korrigiert werden muss, dann bitte ich um einen Hinweis, idealerweise mit einem Logfile, damit ich die Seite aktualisieren kann.

Den automatischen Upload der Logs zu Microsoft können Sie über einen Registrierungsschlüssel abschalten.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\Update-HybridConfiguration]
"DisableUploadLogs"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v16\Update-HybridConfiguration]
"DisableUploadLogs"=dword:00000001

Die aktuellste Version des HCW bekommen Sie unter

Beachten Sie, dass der HCW beim Start nach Aktualisierungen sucht und viele Firewalls und Proxy-Server hier gerne Ungemach wittern. Daher sollten Sie die folgende URL auf jeden fall Zulassen

*.configure.office.com

Hier eine Analyse der einzelnen Schritte:

Vorarbeiten

Der HCW unterstützt sie zwar bei der Einrichtung der Hybrid Umgebung, aber das betrifft nur die Konfiguration von Exchange On-Prem und Online. Sie müssen schon einige Voraussetzungen vorher erfüllt haben:

  • Tenant muss mit Domain eingerichtet sein
  • Ihr Exchange muss per Autodiscover und EWS für Office 365 erreichbar sein (Anonyme Zugriffe mit OAUTH Token)
    Ideal ist einfach NAT mit Routing, aber dazu muss der interne Exchange natürlich die Cloud auflösen können
    Firewalls können die Office 365 IPs als Source/Destination filtern oder im TLS-Handshake den Zertifikatnamen abfragen
  • Exchange muss ein gültiges Zertifikat haben.
  • Für das Mailrouting muss ihr Exchange per Port 25 mit der Cloud sprechen können und erreichbar sein
    NAT oder Exchange Edge Server sind erlaubt aber andere Relays sind nicht supported. Also auch kein NoSpamProxy dazwischen, obwohl wir es sicher könnten. Es ist nicht supportet aber sie hätten kaum einen Mehrwert, denn es ist ja "interner Mailverkehr"
  • ADSync muss Exchange Hybrid aktiviert haben
    Dazu muss er alle Exchange Objekte von On-Prem in die Cloud synchronisieren (identische GAL). Bitte legen Sie nie neue Anwender direkt in der Cloud an und weisen sie keine Exchange Lizenz zu. Sie haben sonst einen User in der Cloud der On-Prem nicht bekannt und nicht erreichbar ist. Der korrekte Web ist es, den Anwender lokal als AD User anzulegen und dann als „RemoteMailbox“ zu aktivieren. Dann hat der Anwender ein Cloud Postfach und sie geben ihm danach in Office 365 auch eine Exchange Lizenz
  • Erreichbarkeit des Internet
    Der Exchange "Connector Server" muss natürlich selbst auch "ins Internet" dürfen, d.h. HTTPS ausgehend und SMTP muss möglich sein. Die erforderlichen DNS-Anfragen als auch CRL-Checks sind ebenso erforderlich

Dann können Sie den HCW starten. der dann folgende Schritte durchläuft:

Einlesen/Anlegen der Hybrid Konfiguration

Die aktuelle Hybrid Konfiguration wird in einem AD-Objekte ihrer lokalen Organisation abgelegt. Wenn Sie schon mal den HCW ausgeführt haben, dann liest der nun gestartete HCW diese Information einfach wieder aus und belegt die verschiedenen Eingabemasken mit den vorherigen Einstellungen. Ansonsten wir ein neues Objekt angelegt

Das kann dann z.B. so aussehen.

Set-HybridConfiguration `
   -ClientAccessServers $null `
   -ExternalIPAddresses $null `
   -Domains 'msxfaq.de' `
   -On-PremsSmartHost 'hybrid.msxfaq.de' `
   -TLSCertificateName '<I>CN=AlphaSSL CA - SHA256 - G2, O=GlobalSign nv-sa, C=BE<S>CN=*.msxfaq.de, OU=Domain Control Validated' `
   -SendingTransportServers EX01 `
   -ReceivingTransportServers EX01 `
   -EdgeTransportServers $null `
   -Features FreeBusy,MoveMailbox,Mailtips,MessageTracking,OwaRedirection,OnlineArchive,SecureMail,CentralizedTransport,Photos

Verifikation des Tenant

Mit den von ihnen eingegebenen Ameldedaten liest der HCW dann auch noch die Office 365 Einstellungen aus. Im Protokoll finden Sie sehr viele „GET-Commandlets“

Achtung:
Der HCW überprüft nicht, ob ihre ADSync-Installation auch für Exchange Hybrid konfiguriert ist.

Upgrade der Einstellungen von früheren Exchange Versionen

Den Hybrid Mode gibt es schon seit Exchange 2010. Der aktuelle HCW wird ggfls. die vorgefundenen „alten“ Einstellungen aktualisieren.

Prüfen der lokalen Voraussetzungen

Für den Hybrid Mode müssen natürlich auch lokale Einstellungen „passen“, z.B. external URLs, Exchange Versionen, ihre Berechtigungen etc. Diese prüft der HCW vorab, ehe er an die Arbeit geht. Im Log finden Sie die entsprechenden „Get“-Commandlets.

Empfängereinstellungen

Damit Hybrid funktioniert, müssen z.B. alle lokalen Empfänger auch in der Cloud bekannt sein und es sollte keine zusätzlichen Empfänger in der Cloud geben, die es lokal nicht gibt. Zudem muss für das Routing  entsprechende Domänen angelegt werden. Im Details ist dies:

  • Einrichten der Mail Domain msxfaq.mail.onmicrosoft.com
New-RemoteDomain `
   -Name 'Hybrid Domain - msxfaq.mail.onmicrosoft.com' `
   -DomainName 'msxfaq.mail.onmicrosoft.com' `
Set-RemoteDomain `
   -Identity 'Hybrid Domain `
   -Domainname 'msxfaq.mail.onmicrosoft.com' `
   -TargetDeliveryDomain $True
New-AcceptedDomain `
   -DomainName 'msxfaq.mail.onmicrosoft.com' `
   -Name 'msxfaq.mail.onmicrosoft.com'
  • Einrichten der Routing Domain als Accepted Domain
    Es ist erforderlich, dass die SMTP-Domänen in beiden Welten gleich sein. Der HCW addiert die „msxfaq.mail.onmicrosoft.com“ als sekundäre Adresse bei all den Empfängerrichtlinien, bei denen die im HCW ausgewählten primären SMTP-Domains verwendet werden. Im Log finden Sie etwas wie:
Set-EmailAddressPolicy `
   -Identity [Recipient Policy] `
   -EnabledEmailAddressTemplates [Proxy Addresses]
  • Update-Recipient
    Und dann kommt der etwas längere Teil, da die neuen Empfängerrichtlinien angewendet werden, Das passiert zwar mit einem Switch, dass nur die sekundären Adressen geändert werden aber im schlimmsten Fall werden alle Objekte angefasst und die Objekte, bei denen die Anwendung von Empfängerrichtlinien unterbunden ist, müssen Sie von Hand anpassen. Das kann also auch mal Stunden dauern und wenn sich mehr als 10% der Objekte ändern, führt das zu einer Neugenerierung und Download des kompletten OABs. Diese Änderung hat ganz sicher einen Einfluss auf ihre Umgebung.
Update-EmailAddressPolicy `
   -Identity [Recipient Policy] `
   -UpdateSecondaryAddressesOnly: $true

Wenn Sie dies aber nicht machen, dann können sie z.B. später bei einer Migration auf Fehler stoßen. Hier ein Beispiel:

Organization Relation Ship / Microsoft Federation Gateway

Damit später auch der Zugriff der Server zwischen den Welten für Free/Busy u.a. erfolgt, muss eine Partnerschaft mit dem Microsoft Federation Gateway eingerichtet werden. Auch das übernimmt der HCW aber er braucht natürlich ihre Mithilfe. Er kann zwar ihre Domain im Federation Gateway eintragen aber im externen DNS müssen Sie schon noch den ermittelten Wert hinterlegen, damit das Federation Gateway ihre Anfragen auch als authentisch akzeptiert. (Proof of ownership). Das ganze geht über ein „Organization Relationship“

Set-Federationtrust `
   -RefreshMetadata `
   -Identity 'Microsoft Federation Gateway' `
   -RefreshMetadata: $false

Set-FederatedOrganizationIdentifier `
   -AccountNamespace msxfaq.net' `
   -DelegationFederationTrust 'Microsoft Federation Gateway' `
   -Enabled 'True' `
   -DefaultDomain $null

New-OrganizationRelationship `
   -Name 'On-Prems to O365 - {GUID}' `
   -TargetApplicationUri 'outlook.com' `
   -TargetAutodiscoverEpr 'https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity' `
   -Enabled: $true `
   -DomainNames ("msxfaq.net","msxfaq.de")

In Exchange Online wird ausgeführt

New-OrganizationRelationship `
   -Name 'O365 to On-Prems - {GUID}' `
   -TargetApplicationUri 'FYDIBOHF25SPDLT.msxfaq.net' `
   -TargetAutodiscoverEpr 'https://autodiscover.msxfaq.net/autodiscover/autodiscover.svc/WSSecurity' `
   -Enabled: $true `
   -DomainNames ("msxfaq.net","msxfaq.de")

Konfiguration Free/Busy

Mit den Vorarbeiten des Microsoft Federation Gateways können dann die Freigaben für „FreeBusy“ eingerichtet werden

Set-OrganizationRelationship `
    -MailboxMoveEnabled: $true `
    -FreeBusyAccessEnabled: $true `
    -FreeBusyAccessLevel 'LimitedDetails' `
    -ArchiveAccessEnabled: $true `
    -MailTipsAccessEnabled: $true `
    -MailTipsAccessLevel 'All' `
   -DeliveryReportEnabled: $true `
    -PhotosEnabled: $true `
   -TargetOwaURL 'http://outlook.com/owa/msxfaq.onmicrosoft.com' `
   -Identity 'On-Prems to O365 - {GUID}'

Add-AvailabilityAddressSpace `
   -ForestName 'msxfaq.mail.onmicrosoft.com' `
   -AccessMethod 'InternalProxy' `
   -UseServiceAccount: $true `
   -ProxyUrl 'https://mail.msxfaq.net/EWS/Exchange.asmx'

In Exchange Online wird addiert

Set-OrganizationRelationship `
   -FreeBusyAccessEnabled: $true `
   -FreeBusyAccessLevel 'LimitedDetails' `
   -MailTipsAccessEnabled: $true `
   -MailTipsAccessLevel 'All' `
   -DeliveryReportEnabled: $true`
    -PhotosEnabled: $true `
   -Identity 'O365 to On-Prems - {GUID}'

Mailfluss

Nun gilt es noch dafür zu sorgen, dass Mails zwischen On-Prem und Office 365 Tenant sicher übertragen werden. Sicher heißt zwingend per TLS verschlüsselt aber vor allem dass die Mails als „intern“ zählen, d.h. auch Systemheader mit ankommen, die Formatierung beibehalten wird, interne OOF Meldungen gesendet werden und vor allem kein Spamfilter eventuell dazwischen grätscht etc. Dazu werden Connectoren angelegt.

New-SendConnector `
   -Name 'Outbound to Office 365' `
   -AddressSpaces [Coexistence Domain] `
   -SourceTransportServers [Servers] `
   -DNSRoutingEnabled: $true `
   -TLSDomain 'mail.protection.outlook.com' `
   -RequireTLS: $true `
   -TLSAuthLevel 'DomainValidation' `
   -ErrorPolicies 'Default' `
   -TLSCertificateName [CERTIFICATE] `
   -CloudServicesMailEnabled: $true `
   -Fqdn $null

Set-ReceiveConnector `
   -Identity EX01\Default Frontend EX01' `
   -TLSCertificateName [CERTIFICATE] `
   -TLSDomainCapabilities [CERTIFICATE]

In meinem Tenant sah der Send-Connector dann so aus:

AddressSpaces                : {smtp:msxfaq.mail.onmicrosoft.com;1}
AuthenticationCredential     :
CloudServicesMailEnabled     : True
Comment                      :
ConnectedDomains             : {}
ConnectionInactivityTimeOut  : 00:10:00
ConnectorType                : Default
DNSRoutingEnabled            : True
DomainSecureEnabled          : False
Enabled                      : True
ErrorPolicies                : Default
ForceHELO                    : False
Fqdn                         : mail.msxfaq.de
FrontendProxyEnabled         : False
HomeMTA                      : Microsoft MTA
HomeMtaServerId              : NAWEX16
Identity                     : Outbound to Office 365
IgnoreSTARTTLS               : False
IsScopedConnector            : False
IsSmtpConnector              : True
MaxMessageSize               : 35 MB (36,700,160 bytes)
Name                         : Outbound to Office 365
Port                         : 25
ProtocolLoggingLevel         : None
RequireOorg                  : False
RequireTLS                   : True
SmartHostAuthMechanism       : None
SmartHosts                   : {}
SmartHostsString             :
SmtpMaxMessagesPerConnection : 20
SourceIPAddress              : 0.0.0.0
SourceRoutingGroup           : Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers       : {NAWEX16}
TlsAuthLevel                 : DomainValidation
TlsCertificateName           : <I>CN=AlphaSSL CA - SHA256 - G2, O=GlobalSign nv-sa, C=BE<S>CN=*.msxfaq.de, OU=Domain Control Validated
TlsDomain                    : mail.protection.outlook.com
UseExternalDNSServersEnabled : False

Der Adressraum ist "%tenantnamt%.mail.onmicrosoft.com" und es wird hier kein Smarthost o.ä eingetragen. Exchange erwartet, dass über den MX-Record, den Microsoft pflegt, die Zielsysteme in der Cloud auflösbar und erreichbar sind. Wenn Sie eine direkte Verbindung nach Extern nicht zulassen wollen, dann müssen Sie Exchange Edge-Server-Rollen installieren. Andere Relay-Systeme sind nicht supported.

Don't place any servers, services, or devices between your On-Prems Exchange servers and Office 365 that process or modify SMTP traffic. Secure mail flow between your On-Prems Exchange organization and Office 365 depends on information contained in messages sent between the organization. Firewalls that allow SMTP traffic on TCP port 25 through without modification are supported. If a server, service, or device processes a message sent between your On-Prems Exchange organization and Office 365, this information is removed. If this happens, the message will no longer be considered internal to your organization and will be subject to anti-spam filtering, transport and journal rules, and other policies that may not apply to it.
Edge Transport servers with hybrid deployments https://technet.microsoft.com/en-us/library/hh134662.aspx

In Exchange Online werden ebenso die Connectoren angelegt, von denen der "InboundConnector" für die Annahme von Mails ihrer On-Prem Umgebung zuständig ist

New-InboundConnector `
   -Name 'Inbound from {GUID}' `
   -ConnectorType 'On-Prems' `
   -RequireTLS: $true `
   -SenderDomains {smtp:*;1} `
   -TLSSenderCertificateName [CERTIFICATE] `
   -CloudServicesMailEnabled: $true

New-OutboundConnector `
   -Name 'Outbound to {GUID}' `
   -RecipientDomains {msxfaq.de} `
   -SmartHosts {hybrid.msxfaq.net } `
    -ConnectorType 'On-Prems' `
   -TLSSettings 'DomainValidation' `
   -TLSDomain 'hybrid.msxfaq.net' `
   -CloudServicesMailEnabled: $true `
   -RouteAllMessagesViaOn-Prems: $false `
   -UseMxRecord: $false

Der "OutboundConnector" routet Mails an ihre Domäne direkt zum Eingang ihrer On-Prem Umgebung. Auch hier wird in meinem Beispiel TLS erzwungen und das Zertifikat auf dem On-Prem-System geprüft.

Und dann wird in Exchange Online noch die neue Organisation bekannt gegeben. Seit einiger Zeit kann ein Office 365 Tenant nämlich mit mehreren Exchange Organisationen gleichzeitig verbunden werden. Sie dürfen dazu aber nur genau eine ADSync Instanz nutzen und den Abgleich der Empfänger zwischen den lokalen Exchange Organisationen obliegt auch ihnen.

New-On-PremsOrganization `
   -HybridDomains {msxfaq.net} `
   -InboundConnector 'Inbound from {GUID}' `
   -OutboundConnector 'Outbound to {GUID}' `
   -OrganizationRelationship 'O365 to On-Prems - {GUID}' `
   -OrganizationName 'Tenant' -Name '{GUID}' `
   -OrganizationGuid '{GUID}'

MRS-Proxy für Migration von Postfächern

Wenn die Cloud quasi „von draußen“ dann On-Prem-Postfächer in die Cloud verlagern will, muss sie auf die Postfachserver zugreifen. Niemand wird nun jeden Exchange Server veröffentlichen wollen, daher gibt es in der Regel einen Hybrid Server, der als Brückenkopf arbeitet. Es geht hier aber nicht um OWA., ActiveSync oder EWS, bei denen die Proxy-Funktion per Default vorhanden ist, sondern um den Mailbox Replication Service (MRS). Der MRS-Proxy wird durch den HCW wie folgt aktiviert

# Identity zur Lesbarkeit umgebrochen. Dies muss ein String sein

Set-WebServicesVirtualDirectory `
   -Identity 'CN=EWS (Default Web Site),CN=HTTP,CN=Protocols,CN=EX01,
              CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),
              CN=Administrative Groups,CN=ORG,CN=Microsoft Exchange,CN=Services,
              CN=Configuration,DC=msxfaq,DC=net' `
   -MRSProxyEnabled: $true

Einrichtung IntraOrganizationConnector

Kurz vor dem Ende wird dann noch ein IntraOrganizationConnector auf beiden Seiten eingerichtet

New-IntraOrganizationConnector `
   -Name 'HybridIOC - {GUID}' `
   -DiscoveryEndpoint 'https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc' `
   -TargetAddressDomains {msxfaq.mail.onmicrosoft.com} `
   -Enabled: $true

Die Einstellung wird natürlich auch in Exchange Online in die Gegenrichtung eingetragen

# Exchange Online
New-IntraOrganizationConnector `
   -Name 'HybridIOC - {GUID}' `
   -DiscoveryEndpoint 'https://hybrid.msxfaq.com/autodiscover/autodiscover.svc' `
   -TargetAddressDomains 'msxfaq.net' `
   -Enabled: $true

OAuth

Für einige Funktionen ist die Konfiguration von OAUTH erforderlich, d.h. dass sich die Exchange Server gegenseitig authentifizieren können. Das geht natürlich nicht mit Dienstkonten und Kennworten, sondern Applikationsbezogen. Sie kennen das Verfahren vielleicht schon bei der Kopplung von Exchange und Skype for Business zum Zugriff auf Chatverläufe oder den Unified Contact Store. Für folgende Funktionen ist eine OAUTH-Konfiguration zwischen Exchange Online und Exchange On-Prem erforderlich.

  • Suche per eDiscovery in Exchange On-Prem und Online, wenn die Suche "On-Prem gestartet wurde aber einige Postfächer in Exchange Online sind
  • Suche per eDiscovery On-Prem, wenn das Archiv des Postfachs in der Cloud liegt
  • Suche per eDiscovery On-Prem, wenn die zu durchsuchenden Inhalte komplett in Exchange Online liegen

In den ersten Versionen des HCW wurden Sie am Ende darauf hingewiesen aber mussten OAUTH noch selbst einrichten. Mit Exchange 2013 CU5 hat HCW angefangen, OAUTH mit einzurichten, was aber gerade in der Anfangszeit nicht immer erfolgreich war. Da der HCW aber Probleme zu Microsoft meldet und Microsoft den HCW quasi täglich aktualisieren kann, ist auch diese Hürde mittlerweile in den meisten Fällen problemlos zu nehmen. Im Log finden Sie dann dies Befehle:

New-AuthServer `
   -Name ACS `
   -AuthMetadataUrl `
   -AuthMetadataUrl 'https://accounts.accesscontrol.windows.net/de21c301-a4ae-4292-aa09-6db710a590a6/metadata/json/1'
Set-PartnerApplication `
   -Identity 'Exchange Online' `
   -Enabled: $true
New-AuthServer `
   -Name EvoSts `
   -AuthMetadataUrl 'https://login.windows.net/msxfaq.onmicrosoft.com/federationmetadata/2007-06/federationmetadata.xml' `
   -Type AzureAD

Knifflig wird es immer dann, wenn eine Umgebung größer und komplexer ist, z.B. mehrere Domains an verschiedenen Standorten hat und die Exchange Server vielleicht nicht alle in der gleichen Domäne sind und daher WAN-Leitungen und Berechtigungen nicht immer passen. Hier muss man dann doch manuell nacharbeiten.

HCW-Einstellung entfernen

Wenn Sie noch mal von ganz vorne Anfangen wollen, dann reicht es nicht die Konfiguration des HCW im AD zu entfernen.

# Hybrid Konfiguratioentfernen (Ab Exchange 2013)
Remove-HybridConfiguration 

# Entfernen der Organisationsvertrauen
Get-OrganizationRelationship | Remove-OrganizationRelationship 

get-federationtrust | Remove-FederationTrust

Sollte noch der Eintrag für das Microsoft Federation Gateway korrupt sein, kann können Sie dieses per ADSIEDIT entfernen und danach wieder über die Powershell neu einrichten. Sie Löschen dazu per ADISIEDT das folgende Objekt:

CN=Configuration,DC=msxfaq,DC=net
!- CN=Services
    !- CN=Microsoft Exchange
        !- CN=yourexchangeorg
            !-CN=Federation Trusts
               !- CN=Microsoft Federation Gateway

Löschen Sie bitte nichts in der "ou=Federation" daneben oder gar die "ou = Hybrid Configuration".

Weitere Links