Hybrid beeinflusst OnPremises Exchange

Inhaltsverzeichnis

Was ändert die Hybrid Konfiguration?
Outlook Zugriff auf Server
Mögliche Probleme
Hybrid temporär deaktivieren
MAPI/HTTP ist immer noch problembehaftet
Weitere Links

Vor der Einrichtung von Exchange Hybrid stellen mir Kunden gerne einmal die Frage, welches "Risiko" diese Konfiguration für eine bestehende lokale Exchange Installation bedeuten kann und ob es Einflüsse, insbesondere auf die Performance, geben kann.

Was ändert die Hybrid Konfiguration?

Eine Exchange Hybrid Konfiguration ist eine Voraussetzung für einen reibungslosen und fehlerfreien Betrieb von Exchange OnPremises und Exchange Online und die Migration von Postfächern zwischen beiden Welten, die nach außen wie aus einem Guss aussehen sollen. der HCW konfiguriert ihre lokale Exchange Umgebung um, damit diese den Weg in die Cloud kennt und von dort angesprochen werden kann. Weiterhin passt der HCW auch ihren Exchange Online Tenant an, damit er dem lokalen Exchange Servern vertraut und den Weg zu diesen Servern kennt. Die vier großen Komponenten sind dabei.

Verzeichnisabgleich mit Entra ID Connect oder Cloud Sync
Hier hilft ihnen der HCW übrigens gar nicht, sondern hier sind sie als Administrator oder Consultant gefragt, dass alle Exchange Empfänger (Postfächer, Verteiler, Kontakte etc.) in beiden Umgebungen synchron sind. Einen Einfluss auf Outlook und Exchange Performance kann ich nicht erkennen.
Mailrouting mit Connectoren
Über die Konfiguration von Inbound-, Outbond-, Send- und Receive-Connectoren erreicht der HCW ein optimales Mailrouting zwischen den beiden Welten. Da SMTP komplett unabhängig von Outlook und einem Client-Zugriff ist, sollten Anwender hier nichts merken.
Eigenes Postfach und Adressbücher
Der Client greift natürlich auf sein Postfach über MAPI/EWS/OWA/IMAP4/POP3/SMTP zu. Ob es nun zusätzlich einen Exchange Online Service gibt ist nur relevant, wenn der Anwender auch auf Postfächer in der Cloud zugreift. Dann muss der Outlook Client natürlich das andere Postfach direkt erreichen. Dabei umgeht er aber den lokalen Exchange Server und baut eine direkte Verbindung auf. Das entlastet also eher den lokalen Server, wenn ein Raum-Postfach, eine Shared Mailbox oder ein zu vertretendes Benutzerpostfach schon nach Exchange Online verschoben wurde.
Free/Busy, Mailtipps etc.
Hier wird es nun interessant, denn ein lokaler Anwender nutzt primäre die Umgebung seines Postfachs, um bei Termineinladungen die Frei/Belegt-Zeiten zu ermitteln. Der angesprochene Exchange Server besorgt dann die Daten im Auftrag des Benutzers aus der Cloud. Der eigene Exchange Server muss daher per HTTPS mit dem jeweils anderen System Kontakt aufnehmen können und die Anfragen kann auch einige Sekunden dauern. Das betrifft aber nicht die normale Arbeit mit eigenen Mails, Terminen oder Kontakten

Allerdings müssen Sie aufpassen, dass durch die ebenfalls geänderte Erreichbarkeit von Exchange Online korrekt funktioniert. Ihr Client sollte bei Zugriffen auf lokale Postfächer nicht irrtümlich über einen Proxy nach draußen und dann wieder zurück nach drinnen geroutet werden. ProxyAusnahmen und DNS-Auflösung

Outlook Zugriff auf Server

Dennoch gibt es natürlich die Frage, wie Outlook mit Exchange OnPremises arbeitet und an welchen Stellen ein lokale Outlook mit lokalem Exchange Postfach durch eine Hybrid-Bereitstellung beeinflusst werden kann. Wir schauen uns dazu die verschiedenen Zugriffe von Outlook an:

MAPI/http auf das eigene OnPremises Postfach.
Hier sollte Exchange Online und Hybrid keinen Einfluss haben. Der Client sollte per Autodiscover oder den SCP-Eintrag per LDAP die lokalen Exchange Server finden und als Antwort auch die lokalen Exchange Zugriffspunkte finden und nutzen. Das hat nichts mit Hybrid zu tun.
EWS/http auf Free/Busy-Zeiten von anderen OnPremises Postfächern
Wenn ich als OnPremises-Benutzer einen Termin mit anderen OnPremises Postfächern plane, dann fragt Outlook den Server des aktiven Benutzers, welcher dann die Frei/Belegt-Zeiten von den anderen OnPremises Postfächern besorgt. Exchange Hybrid hat hier keine aktive Rolle
Adressbuch/HTTP
Wenn Outlook das Adressbuch abfragt, erfolgt das über den Postfachserver des Anwenders, der lokal ist und ich kann keine Abhängigkeit zur einer Hybrid-Bereitstellung sehen.

Das sind quasi die ersten vier Verbindungen von oben auf dem Bild bis zur gestrichelten Linie

Interessant wird es es erst, wenn der Outlook-Client auf Informationen zugreifen muss, die nicht der lokalen Exchange Server bereitstellen kann. Hier gibt es eigentlich nur die Aspekte:

MAPI-Zugriff auf Exchange Online Postfächer oder als Stellvertreter auf ein anderen Postfach, Shared Mailbox oder Raum, die in EXO liegen.
Outlook wird vom lokalen Autodiscover-Dienst über die MOERA - Microsoft Online Email Routing Address zur Cloud geleitet und bekommt so den direkten Zugangspunkt zum Cloud Postfach. Sie sehen das auch in Outlook, wenn Sie mit „CTRL+Rechte Maustaste" das Outlook-Icon in der Tray-Leiste anklicken und den Verbindungsstatus anschauen. Dort erscheinen die Exchange Online Server Server
EWS/http zum lokalen Exchange für Free/Busy-Zeiten von Cloud-Postfächern
Outlook fragt immer seinen "Heimatserver" hinsichtlich Frei/Belegt-Zeiten, Mailtipps, Abwesenheitsmeldungen. Der Server geht dann los und besorgt, und cached, die Daten für die Clients. Wenn das Postfach lokal liegt, wird die Anfrage zum passenden Postfachserver per EWS weitergeleitet. Bei einem Postfach in Exchange Online nutzt Exchange seit Okt 2025 die Dedicated Hybrid Application, um die Informationen per HTTP von Exchange Online abzufragen.

In beiden Fällen kann natürlich eine schlechte Verbindung zur Cloud auch die Reaktion von Outlook verzögern oder Fehler melden. Aber das dürfte dann nur Free/Busy, Mailtipps-Anfragen betreffen. Die Anzeige von Kalendern in Teams und den davon abhängigen Status für OnPremises Benutzern erfolgt "außen herum", d.h. der Teams Client fragt nicht direkt den Exchange OnPremises Server, sondern immer das Teams Backend, welches sich dann zum Postfachserver des Benutzers verbindet.

Mögliche Probleme

Auch wenn die Einrichtung des Hybrid-Mode eine Kommunikation zwischen Exchange OnPremises und Exchange Online einrichtet, sollten der Einfluss auf die Performance des lokalen Servers minimal sein. Es gibt aber durchaus einen Einfluss oder mögliche Fehlkonfigurationen, von denen ich einige einmal aufführen möchte:

Teams Kalenderzugriff und Präsenz
Sie haben gesehen, dass der Kalender in Teams einen zusätzlichen Zugriff von extern auf ihren OnPremises Server verursacht. Das sind aber keine großen Datenmengen oder Verbindungen. Insofern sollte der Einfluss minimal sein
Migration
Der Umzug von Postfächern zwischen Exchange OnPremises und Online wird durch den Mailbox Replication Service in der Cloud gesteuert, welcher den lokalen MRSProxy anspricht. Hier werden schon mal Gigabytes gelesen oder geschrieben und speziell eine Migration zurück nach OnPremises generiert dort schon einiges an Disk-IO. Aber die Cloud bekommt vom lokalen Server mit jedem Request auch Telemetriedaten, und Microsoft verspricht, dass der Cloud-Service den lokalen Server nicht überlasten würde. Wenn Sie ihren lokalen Server natürlich im Monitoring (CPU, RAM, DISK, Latenzzeiten) haben, dann sollten Sie dies auch sehen können.

Interessanter sind aber etwaige Fehlkonfigurationen oder Probleme, die durch die Nutzung von Exchange Online gerne passieren können.

Autodiscover Konfiguration
Jahrelang hat "Classic Outlook" eine LDAP-Abfrage nach einem Service Connection Point (Autodiscover und SCP) gemacht, um einen Exchange Zugangspunkt zu finden. Ohne den Eintrag hat Exchange nach "autodiscover.<maildomain>" gesucht. Neuere Outlooks such aber immer auch in Exchange Online nach einem Postfach. Es könnte ja sein, dass ein lokaler Administrator noch ungültige Reste übriggelassen hat. Das kann aber hier nun ein Problem werden, wenn sie bisher nur den lokalen Server genutzt haben und Autodiscover nicht perfekt war. Kontrollieren Sie lieber mal, ob der SCP noch korrekt ist und keine alten Exchange Einträge und Server vorliegen. Mit “Get-ClientAcccessService | fl Autodiscover*” kann man die URL ermitteln, die ein Client per LDAP erfragen kann
DNS-Fehler
Es ist auch sinnvoll die anderen URLs, welche Sie für den Zugriff auf die lokalen Exchange Server nutzen, im DNS zu prüfen. Nslookup autodiscover.msxfaq.de
Internet Proxy
Wenn Clients die Cloud-Dienste nutzen, dann konfigurieren Sie meist einen HTTP-Proxy per Gruppenrichtlinie oder WPAD - Proxy im Browser einstellen. Haben Sie ihren internen Exchange Server als Ausnahme definiert oder greifen ihre Anwender von innen durch den Proxy nach außen und dann wieder nach intern zu?
LoadBalancer
Die zusätzlichen Verbindungen von Exchange Online und Teams für Kalender, Free/Busy und die ein oder andere Migration sollten den Loadbalancer nicht überlasten. Aber vielleicht war er schon vorher "knapp" an der Auslastungsgrenze und die wenigen Exchange Hybrid Verbindungen bringen nun das Fass zu überlaufen?
MAPI/HTTP
Seit vielen Jahren ist MAPI/HTTP das neue und aktuelle Protokoll. Ich finde aber immer mal wieder Clients die MAPI/HTTP nicht dürfen und RCP/HTTP versuchen. Das geht schon in der Cloud nicht aber mit Exchange OnPremises auch nicht mehr wirklich. Vielleicht haben Sie aber für Hybrid extra einen neuen Exchange SE Server installiert, der manchmal von den Clients als Frontend erreicht wird?
Kontrollieren Sie auf dem Client den Schlüssel „HKEY_CURRENT_User\Software\Microsoft\Exchange\MapiHttpDisabled". Das sollte nicht auf 1 stehen.

Hybrid temporär deaktivieren

Nehmen wir an, dass alle bisherigen Tipps nicht geholfen haben und Sie Hybrid nur temporär mal deaktivieren wollten, dann ist auch das relativ einfach möglich.

Entra ID Connect/Cloud Sync
Aus meiner Sicht ist es nicht möglich, dass diese Komponente eine Exchange Hybrid Bereitstellung hinsichtlich Performance beschädigt. Es ist eher umgekehrt, dass nur ein partieller Abgleich zu unvollständigen Empfänger in Exchange Online führt und daher Mailverteiler nicht komplett sind und Berechtigungen fehlen könnten. Bitte deaktivieren Sie nicht den Verzeichnisabgleich aber kontrollieren Sie gerne, dass alle Elemente auch wirklich synchronisiert werden. Siehe auch Compare-GAL
SMTP-Connectoren
Auch hier sehe ich keinen direkten Einfluss auf Clients oder Exchange Server Performance. Einzige eine unerkannte "Mail-Loop" könnte temporär eine hohe Last erzeugen. Das sollten Sie aber schon bei der Analyse ermittelt haben. Wenn Sie aber die durch den HCW eingerichteten Connectoren deaktivieren, dann beschädigen Sie sehr sicher ihren internen Mailfluss. Also auch hier gilt: "Finger weg"
Migration Endpoint
Auch diese Konfiguration sehen die Clients eigentlich nicht. Allerdings kann eine aktive Migration natürlich einen Einfluss auf die Performance des Servers nehmen. Hier haben sie als Administrator natürlich die Möglichkeit eine Migration auch mal zu pausieren oder auf die Nachstunden zu verschieben, wenn ihre OnPremises-Umgebung aus Firewall, Loadbalancer, Exchange, Hypervisor und Storage-Subsystem deswegen ein Problem haben sollte.
Server zu Server Kommunikation
Also bleibt der Zugriff bei Frei/belegt-Seiten, Mailtipps etc, wenn ein Client den lokalen Server um die Informationen bittet und dieser die Werte von Exchange Online beziehen muss. All diese Prozesse laufen aber asynchron ab und nutzen EWS. Es sollte daher keinen MAPI-Verkehr betreffen. Das könnten Sie aber einfach temporär in der lokalen Exchange Umgebung deaktivieren und schauen, ob die Probleme danach weg sind. Sie müssen beide deaktivieren, denn der IntraOrganizationConnector nutzt OAUTH und wird immer zuerst genutzt. Wenn er aber nicht da oder deaktiviert ist, dann fällt Exchange auf den OrganizationRelationship mit DAUTH zurück-
Get-IntraOrganizationConnector | Set-IntraOrganizationConnector -Enabled $false
Get-OrganizationRelationship | Get-OrganizationRelationship -Enabled $false
Ich denke aber nicht, dass dies eine Auswirkung auf die Performance hat.

Vergessen Sie aber nicht alle Änderungen wieder rückgängig zu machen.

MAPI/HTTP ist immer noch problembehaftet

Dann müssen wir uns wirklich die HTTPS-Verbindung von Client zum Server über MAPI/http genauer anschauen. Auch da gibt es einige Mitspieler. Wir bewegen uns nun aber komplett "OnPremises" und haben quasi keine Anknüpfungspunkte mehr zu Exchange Online. Daher verweise auch auf zwei schon ältere Seiten der MSXFAQ

Ansonsten hier nur noch ein paar Strichpunkte:

Netzwerk Routing
Zuerst muss natürlich sicher sein, dass die Verbindung von Client zum Server keine Umwege läuft. Eine Kontrolle von DNS, WPAD, Proxy, aber auch Netzwerklaufzeiten ist immer angebracht.
Der Client selbst und darauf installiert „Endpoint Schutzlösungen“
Das ist eher selten aber hatte ich schon, dass ein Malwarescanner sich als HTTP-Proxy eingeschliffen hat, um zu kontrollieren.
Load-Balancer
Wer mehrere Exchange Server hinter einem LB betreibt, sollte man die "Source Ports In Use" kontrollieren, wenn Exchange nicht den Client sondern nur den Loadbalancer sieht. Es gibt da so ein 65535 Port-Limit, welches in Verbindung mit TCP Session Timeout / TCP Idle Timeout / TCP KeepAlive sporadische Probleme verursachen kann.
Kontrollieren Sie dazu auch die Einstellung auf dem Windows Server. Siehe https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/TCPIPSettingsCheck/
Exchange Server und Perfmon
Zuletzt kann es natürlich immer noch ein Exchange Server Problem sein. Langsame CPUs sind über den Taskmanager noch einfach zu ermitteln. Zu wenig RAM fällt nicht mehr auf, da Exchange eh immer alles nutzt, was er bekommen kann. Hier könnte dann Latenzzeiten mittels Perfmon ermittelt werden oder mit "Test-MAPIConnectivity" von Server zu Server gemessen werden.
IIS/MAPI-Logs
Exchange schreibt alle Zugriffe der Clients im IISLog mit und die einzelnen Dienste schreiben ebenfalls ihre Protokolldateien, welches Hinweise auf Fehler aber auch Latenzzeiten liefern. Allerdings ist die Auswertung nicht direkt ohne Skripte oder Tools möglich. Es sind halt "CSV-Dateien". Wenn ihre Firma diese Informationen schon in einen Datentopf (Grafana u.a.) sendet, dann können sie leichter die Daten bewerten.
Outlook Client
Es ist ja nicht so, dass Outlook keine Telemetrie-Daten schreibt. Sie müssen die Funktion aber erst aktivieren und die ETL-Dateien sind auch nicht gerade einfach auszuwerten. Ehe ich hier an den Client gehen würde, würde ich eher synthetische Tests zum Server fahren und auf Muster nach Subnetz, Standort, Server o.ä. hoffen.

Es gibt massenhaft Skripte und Tools um die Performance von SMTP, POP, IMAP-Services zu prüfen und auch für EWS können Sie relativ einfach eigene Skripte schreiben. Siehe auch End2End EWS und End2End-HTTP. Wenn Sie den Verdacht haben, dass vielleicht ihr Active Directory ein Problem haben könnte, dann wäre End2End-LDAP eine Option und die Performance der Exchange Festplatten könnten Sie mit End2End File genauer untersuchen. Aber für MAPI/HTTP habe ich bislang keine Funktion gefunden, es sei denn die programmieren Outlook per COM-Interop an, um ein Postfach zu öffnen. 3rd Party Tools wie z.B. Redemption funktionieren nur mit installiertem Outlook über eine COM-API, die quasi stirbt.

Wir könnten aber zumindest den MAPI-HTTP-Endpunkt regelmäßig abrufen und die Erreichbarkeit und Latenzzeit von einem Client messen. Das ist zwar kein echter Ersatz einer MAPI-Anfrage auf die Mail in einem Postfach aber könnte Aussetzer bei der Verbindung zu Exchange sehr wohl erkennen.

# Abruf des MAPI-HealthCheck
Invoke-WebRequest "https://mail.domain.tld/mapi/healthcheck.htm"

# Abruf des MAPI-HealthCheck mit Zeitmessung
(Measure-Command {Invoke-WebRequest "https://mail.domain.tld/mapi/healthcheck.htm"]).totalmilliseconds

# Wiederholter Abruf um LB-Verteilung zu sehen
1..100 | %{(Invoke-WebRequest https://owa.msxfaq.com/mapi/healthcheck.htm).headers."x-feserver"} | group -noelement

Auf der Seite End2End-HTTP habe ich dies als ausführliches Skript erstellt, um Webserver kontinuierlich und vor allem Engmaschig zu überwachen. Wer aber nicht nur einmal in der Minute einen "Is Alive"-Check macht, sondern mehrere Messungen pro Sekunde durchführt, sollte die Werte sinnvoll zusammenfassen, z.B. über Percentil statt Mittelwerte. Siehe dazu auch End2End Werte.

Die Probleme eines Exchange Servers können vielfältig sein und oft ist es gar kein Exchange Problem. Wenn Sie immer noch am Problem hängen und Hilfe annehmen wollen, dann sprechen Sie meine Kollegen bei Net at Work oder mich einfach an.
Net at Work und MSXFAQ