Hybrid Connector Server

Wenn all ihre Postfächer in Office 365 sind aber sie mit AADConnect einen Verzeichnisabgleich betreiben, dann müssen sind aktuell die Exchange Eigenschaften im lokalen Active Directory mit den Exchange PowerShell-Commandlets zu pflegen.

Warum Sie einen On-Premises Exchange Server für die Verwaltung von Exchange Online Konten mit AADConnect brauchen, ist auf ADSync mit Exchange Online Only und DirSync mit Exchange beschrieben.

 Diese Seite beschreibt, wie Sie so einen "minimal Server" aufbauen.

Updates 20. Apr 2022

Mit dem Exchange 2019 CU12 vom 20.04.2022 Update ist es möglich, die Exchange Empfänger allein per PowerShell zu bearbeiten und erfordern keine komplette Installation von Exchange 2019 als Server. Wenn Sie aber weiterhin einen gesicherten Mailfluss zwischen dem Tenant und einer lokalen SMTP-Umgebung bereitstellen müssen, kommen Sie am Exchange Server nicht vorbei.

Lizenzierung

Jeder Exchange Server muss ja auch lizenziert sein. Ein reiner "Hybrid Connector Server" hat keine Postfächer und stellt auch sonst keine Speicherdienste bereit. In dem Fall gilt:

Q: If my organization is Hybrid with Office 365 and I do not host mailboxes On-Premises, do I still need to license Exchange Server?
A: If you do not host any mailboxes on the servers used to connect to Office 365 you can license them using the Office 365 Hybrid Configuration Wizard (HCW). The HCW validates your Office 365 subscription and installs the appropriate licenses on your servers.
Quelle: Exchange Licensing FAQs https://products.office.com/en-us/exchange/microsoft-exchange-licensing-faq-email-for-business

Es scheint so zu sein, dass jeder Office 365 Tenant mit Exchange Online ihnen die Installation eines On-Prem Exchange Servers für Mailrouting und Provisioning erlaubt.

Achtung
In Verbindung mit einem Office 365 Tenant bekommen sie einen kostenfreien Exchange 2016 Produkt-Key zum Aufbau dieses Connector Servers. Angeblich reicht die Anmeldung am Office 365 Tenant als "Global Admin" als Verifikation. Der Server darf natürlich dennoch keine Postfächer bedienen.

Die Lizenz besorgt der HCW bei der Einrichtung von Hybrid und sie sehen es auch bei der Auswahl des Exchange Servers in verschiedenen Dialogen, Hier beim Receive Connector

Aufgaben des Servers

Microsoft beschreibt auf mehreren Stellen (Siehe dazu auch DirSync mit Exchange), dass direkte Modifikationen der LDAP-Felder von Exchange nicht getestet und damit auch nicht supportet sind. Da kann man nun streiten, wie ernst das zu nehmen ist und ob man nicht doch vielleicht per ADSIEDIT und eigenen Skripts das gleiche Ergebnis erreichen kann. Tatsächlich geht das und auf ADSync mit Exchange Online habe ich beschrieben, wie man alleine mit einer "lokalen Exchange PowerShell" arbeiten könnte. Aber es bleibt "nicht supportet".

Auf der anderen Seite finde ich es gar nicht so schlimm einen kleinen lokalen Exchange Server zu betreiben, der mir nicht nur das Provisioning vereinfacht. Die Exchange Commandlets enthalten nämlich ganz viel Code zur Qualitätssicherung, z.B. wird sichergestellt, dass ich nur Mailadressen für Domänen vergeben kann, die ich auch als "Accepted Domains" hinterlegt habe. Zudem werden doppelte Mailadresse u.a. verhindert. Ich müsste also viel Code und Intelligenz in eigene Skripte stecken, die über die Exchange Commandlets schon vorliegen.

Aber der Server kann noch mehr: Er kann einen per "MTLS" gesicherten SMTP-Kanal zwischen meinem lokalen internen LAN und meinem Office 365 Tenant aufbauen, der mir viele Möglichkeiten eröffnet. Ohne einen lokalen Server gibt es nämlich einige Herausforderungen wie:;

  • Scan2Mail
    Wie kann man Scanner im Haus-LAN etwas an die Postfächer senden? Soll ihr Drucker wirklich per NAT und SMTP direkt die Office 365 Server erreichen bei denen Sie dann noch sicherstellen müssen, dass der Spamfilter nicht zuschlägt? Ihre eigene "Public-IP" wollen Sie doch sicher nicht auf eine Allowlist setzen, damit jeder interne (Virus/Malware) Client per SMTP seinen Schadcode ungehindert verbreitet
  • Authentifizierung und Konten
    Wenn Sie auf anonymen Versand verzichten, dann müssen ihre Sender ein Office 365 Postfach und Anmeldedaten bekommen. Können Sie sicher sein, dass all diese Clients auch SMTP mit Verschlüsselung machen oder übertragen Sie gültige Office 365 Anmeldedaten unverschlüsselt?
  • Überlastung/Ausfall
    Welche diese einfachen "Mailserver" kann damit umgehen, dass die Verbindung nicht wenige Millisekunden sondern auch mal 100 und mehr Millisekunden Latenzzeit hat oder temporär nicht vorhanden ist? Versucht es der Client wieder über eine interne Queue oder bricht er einfach ab und die Information geht verloren?
  • Eingehende Dienste
    Sie haben sicher gar kein internes System (ERP, CRM, HelpDesk etc.) In Office 365 können Sie sehr einfach eine Weiterleitung einrichten, indem Sie einen Mailkontakt anlegen, der Mails an support@example.com einfach an support@erp.example.com weiterleitet. Nur müssen Sie Office 365 über einen "Outbound Connector" auch noch beibringen, wohin er Mails mit der Domäne erp.example.com senden soll. Da ist es schon einfacher diese Mails über einen "Tunnel" zu einem Brückenkopf in ihrem LAN zu senden, der die Mails dann weiter intern verteilt.

Es gibt neben dem reinen Provisioning also durchaus einen Grund einen kleinen lokalen Exchange Server zu betreiben, der nicht mal viel Ressourcen benötigt. Er hat ja keine Postfächer und die Lizenz ist in ihrem Office 365 Abonnement mit enthalten.

Hybrid, Min-Hybrid oder weniger ?

Wenn Exchange im lokalen AD installiert ist und AADConnect die Identitäten verwaltet, dann sprechen wir in der Regel von einem Hybrid-Mode. Ein voller Hybrid-Mode ist aber nur notwendig, wenn wirklich Postfächer in beiden Welten sind, die zudem über einen längeren Zeitraum in einer Koexistenz bestehen. Sie benötigen natürlich "Free/Busy"-Informationen und vieles mehr. Das ist hier nicht geplant. Selbst der "Min Hybrid"-Mode, der primär für die Migration in die Cloud aufgebaut wird, ist hier nicht zutreffend. Dennoch müssen wir ein bisschen Hybrid schon machen. Denn Hybrid bedeutet auch einen Abgleich einiger Einstellungen wie der "Accepted Domains" und natürlich das Mailrouting.

Theoretisch könnten Sie das auch alles von Hand manuell einrichten aber der HCW macht das schon besser. Sie müssen ja nicht alle Schritte komplett umsetzen.

Beachten Sie dazu auch die Gegenüberstellung auf HCW Feature&Topologie

Exchange Einrichtung

Die Installation des Exchange Servers im lokalen Netzwerk ist heute nicht mehr schwer.

Aktion Erledigt

Sizing

Sie können sich quasi auch alle größeren Vorarbeiten zum Sizing sparen, da der Server nie Benutzerpostfächer tragen wird. Damit entfällt auch ein Großteil der weiteren Komponenten wie Backup, Archiv, Provisioning, Monitoring etc. Wenngleich sie natürlich schon die "Light"-Version für Monitoring und einen Recovery-Plan vorhalten müssen. Für das Sizing müssen Sie nur ermitteln, wie viele Mails sie über diesen Server übertragen werden. Selbst da sind sie z.B. mit virtuellen Maschinen flexibel in der Planung. In der Regel reicht eine VM mi

  • 2-4 CPUs
  • 8-16 GB Ram
  • 100-200 GB Disk
    Wobei hier die Queues und deren Vorhaltezeit ein Thema sein könnte.

Installation

Die Installation habe ich auf anderen Seiten (siehe Exchange 2016 Installation) schon beschrieben. In einer kleinen Umgebung starten Sie das Setup am besten auf dem vorgesehenen Exchange Server in der in der Root-Domäne Mitglied ist und sie als Enterprise-Administrator angemeldet sind. zudem müssen Sie das Recht zur Schema-Erweiterung haben. Zur Installation sollten Sie einfach das aktuellste Service Pack von Exchange 2016 nutzen. Es ist eine Vollinstallation.

Danach rate ich ihnen zu folgenden Konfigurationseinstellungen, um Störungen auf dem Client zu vermeiden. Dies geht per PowerShell aber viele Dinge sind auch per Browser auf dem Server unter "https://<fqdn-des-exchange-server/ecp" einstellbar.

SCP Entfernen

Der erste Schritt nach der Installation von Exchange sollte eine Konfigurationsänderung sein. Um Störungen der Clients zu vermeiden sollten sie als allererstes den Service Connection Point entfernen, den das Exchange Setup angelegt hat. Outlook liest per Default im Rahmen seiner "Autodisover"-Ermittlung auch das lokale AD und findet mit der Installation des Servers auch die lokale Frontend-Rolle (CAS) mit dem virtuellen Autodiscover-Verzeichnis.

Natürlich verweist "autodisdover.<maildomain>" weiterhin auf Office 365 aber LDAP kommt nun mal zuerst. Outlook ist zwar mittlerweile auch darauf vorbereitet und springt zu Office 365, wenn die lokale Autodiscover-Vermittlung nicht funktioniert aber darauf würde ich mich nicht verlassen. Zertifikatswarnungen und andere Effekte sind mehr als unschöne. Also entfernen wir den SCP mit der Exchange PowerShell.

# Autodiscover ECP abschalten
get-clientaccesserver `
| set-clientaccesserver `
  AutodiscoverInternalURL $null

Datenbankkonfiguration anpassen

Die zweite Einstellung ist sinnvoll, damit ihr Server auf längere Zeit nicht voll läuft. Jeder Exchange 2013+ Server hat nämlich auch immer eine Postfachdatenbank. Die möchte ich entsprechend anpassen, indem ich einmal die Umlaufprotokollierung aktiviere und sie aus dem Provisoining ausnehmen:

# Circular Logging
get-mailboxdatabase `
| set-mailboxdabase `
     -CircularLoggingEnabled $True `
     -IsExcludedFromProvisioning $true `
     -IsExcludedFromInitialProvisioning $true

restart-service msexchangeis

Die Änderung wird erst nach dem Neustart der Datenbank aktiv.

Accepted Domain

Sagen Sie ihrem Exchange Server bitte, für welche Domänen er zuständig ist. Nur für Empfänger dieser Domänen akzeptiert Exchange eingehende Mails. Ich würde hier alle SMTP-Domänen als "Autoritativ" einsetzen, wenn Sie später alle Empfänger sowieso in Exchange verwalten. Bei einer Migration rate ich immer dazu, dass die Empfänger im alten Mailsystem über eine eigene Routingdomäne angesprochen werden

Connectoren

Wenn Sie intern weitere Mailsysteme haben, die über Exchange und eine Routingdomäne erreichbar sein sollen, dann können Sie hier schon einen Send-Connector anlegen. Für den Empfang von intern bietet sich ggfls. ein Receive Connector an. Konfigurieren Sie hier aber keine Connectoren zu Office 365. Das macht später der HCW

Dies benötigen Sie natürlich alles nicht, wenn der Exchange Server rein für das Provisioning genutzt wird.

Empfängerrichtlinie

Nach der Installation vergibt Exchange Mailadressen mit den DNS-Namen ihres Active Directory Forest. Das ist meist nicht passende. Ich lege daher neue Empfängerrichtlinien an, die die späteren Exchange Empfänger gleich richtig mit Proxy-Adressen versehen. Das können Sie recht einfach per Browser auf auf dem Server machen. "https://<fqdn-des-exchange-server/ecp"

Delegierung der Administratorenrechte an Dienstkonto

Der Administrator, welcher Exchange installiert hat, ist zugleich auch der einzige Exchange Administrator. Sie werden sicher weitere Konten berechtigen wollen. Exchange nutzt dazu Windows Sicherheitsgruppen. Zwei Gruppen sind hier besonders relevant:

  • Exchange Administratoren
    Benutzer in dieser Gruppe können Exchange in jeder Hinsicht konfigurieren
  • Recipient Administratoren
    Mitglieder in dieser Gruppe können nur die Empfänger verwalten. Diese Gruppe ist daher ideal für Dienstkonten, die z.B. beim Provisioning genutzt werden.

Exchange Lizenz

Exchange wird auch ohne Lizenzcode weiter laufen. Aktuell ist es ja eine "Trial-Version" die sie aber über den Code aus ihrem Office 365 Portal zu einer sauberen Vollversion machen können.

# Lizenz einspielen
Set-ExchangeServer `
   -ProductKey XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

 

Provisioning

Mit der Installation des lokalen Exchange Servers haben Sie nun auch eine Exchange PowerShell, die Sie für die zukünftige Konfiguration der Exchange Benutzer in der Cloud nutzen können. Wobei "können" schon zu schwach ist, denn sie können in Exchange Online diverse Einstellungen gar nicht einstellen, sobald AADConnect eingerichtet ist.

Sie konnten mit der Installation von AADConnect schon früher Exchange Postfächer in der Cloud haben, weil Office 365 mit der Zuweisung einer Exchange Online Lizenz dem Benutzer in der Cloud auch ein Postfach gibt, selbst es im lokalen AD keine entsprechenden Felder gab. Nun können Sie aber mit der lokalen Exchange PowerShell die dazugehörigen lokalen Benutzer verwalten

Achtung: Exchange Online
Es gibt Firmen, die mit Exchange Online Only starten und die Identitäten in der Cloud ohne AzureADConnect verwalten oder die Benutzer mit AzureAD Verwalten aber die Exchange Einstellungen einfach nur "default" gelassen haben. Diese Firmen müssen vorab eine Liste der Exchange Empfänger in der Cloud extrahieren und die passenden lokalen Objekte entsprechend für Exchange zu provisionieren. Dies werde ich hier nicht weiter beschreiben.

AADConnect

Ich habe schon Umgebungen mit installiertem AADConnect gesehen, bei dem lokal keine Exchange Konfiguration vorhanden war. Die Installation von AADConnect prüft das vorhandene Schema und aktiviert nur die Regeln, die erforderlich sind. Wenn Sie bei der Installation also noch keine Exchange Schema Erweiterung installiert hatten, dann hat AADConnect auch keine Exchange Regeln aktiviert.

Sie müssen bei einem bereits installierten AADConnect also einmal in das Setup gehen und das Schema neu einlesen.

Zudem müssen Sie auch AADConnect sagen, dass es einen Exchange Hybrid-Mode gibt:

Danach gibt es in AzureADConnect auch die Regeln zum Abgleich von Exchange:

Achtung
OnPremise überstimmt Cloud, d.h. wenn Sie Felder wie "mail" oder "ProxyAddresses" schon verwendet haben, die es auch ohne Exchange Schema Erweiterungen gibt. Diese überschreiben dann die Werte in der Cloud

Mailrouting

Der lokale Exchange Server kann und sollte auch als Brückenkopf für das Mailrouting mit lokalen Diensten genutzt werden. Technisch besteht die Konfiguration aus einem Zertifikat auf dem lokalen Server, damit er die Verbindung verschlüsseln und sich gegen Office 365 identifizieren kann.

Achtung
Achten Sie bei allen Konfigurationseinstellungen darauf, dass ihr Exchange Server keine Mails von "fremden" Adressen oder anonym annimmt. Dieser Server sollte nur von Office 365 Servern per Port 25 SMTP erreichbar sein. Das kann eine Firewall absichern.

Und dann gilt es wieder die vier Connectoren einzurichten, damit die beiden Partner miteinander kommunizieren können.

  • On-Premises -> Office 365
    Ein SendConnector lokal sendet alle Mails an die Office 365 Instanz und nutzt dazu zwingend TLS. Auf der Office 365 Seite wird eingerichtet, dass Mails von diesem Server, der sich mit dem Zertifikat ausweist, als vertrauenswürdig angesehen werden
  • Office 365 -> On-Premises
    In der Gegenrichtung legen Sie im lokalen Exchange Server einen Empfangs Connector an, damit Mails von den den IP-Adressen von Office 365 angenommen werden, damit der in Office 365 anzulegende "Outbound Connector"

Der Prozess ist bei mir und Microsoft umfangreich beschrieben. Die Einrichtung übernimmt der Hybrid Configuration Wizard, der auch diverse andere Dinge überprüft.

Nachdem die Verbindung zwischen dem lokalen Server und dem Office 365 Tenant eingerichtet ist, sollten Sie nun auch die internen Systeme eintragen, für die das Setup relevant ist. Hierbei gibt es zwei Gruppen:

  • Einliefernde Systeme
    Alle Systeme, die intern an diesen Server Mails einliefern sollen, müssen über einen lokalen "Receive Connector" bedient werden. Hier können Sie umfangreiche Einstellungen vorschreiben wie z.B. MaxMailSize, MaxRecipients und ob eine Source-IP als Authentifizierung reicht oder der Sender sich anmelden muss.
  • Auslieferung von Mails
    Wenn Sie den Weg auch nutzen, um Mails von Office 365 über den Connector Server zu einem anderen lokalen Server zu senden, dann erfolgt dies mit einem Send-Connector, de Mails an eine Routingdomäne zu der internen IP-Adresse weiter leitet.

Über diese Konfiguration kann nun der komplette Mailfluss innerhalb ihrer Firma auch über interne oder zumindest per TLS gesicherte Verbindungen laufen.

Weitere Links