Modern Hybrid Rückbau

Diese Seite beschreibt meine Analysen bei der Deinstallation oder dem Rückbau des Hybrid Agent, der bei Exchange Modern Hybrid App Proxy installiert wird.

Einleitung

Für die Koexistenz von Exchange Online und Exchange OnPremises ist eine EWS-Verbindung zwischen den Umgebungen erforderlich. Exchange Online ist natürlich erreichbar und wenn ihr lokale Exchange Server eine Information von Exchange Online besorgen möchte, dann muss er nur "surfen" können. In die Gegenrichtung stehen Sie als Exchange Administrator natürlich vor der Überlegung, wie Sie ihren Exchange Server "sicher" für Exchange Online erreichbar machen. Bei "Classic Hybrid" veröffentlichen Sie ihren Exchange Server einfach per HTTPS über eine Firewall und Reverse Proxy.

Modern Hybrid ist die Alternative, wenn Teams keinen Zugriff auf das lokale Exchange Postfach benötigt. Über den HCW - Hybrid Configuration Wizard wird komplett automatisch dann ein Exchange Hybrid Agent installiert. Exchange Online kommuniziert dann nicht direkt mit ihrem Exchange Server sondern über einen AzureAppProxy in Verbindung mit einem lokalen Agenten.

Normalerweise bauen Sie so eine Umgebung nicht oder erst ganz am Ende ihrer Exchange Migration zu Exchange Online ab, wenn Sie auch noch den LES - Last Exchange Server entfernen wollen und mit der Exchange Management Rolle verwalten oder ganz ohne Microsoft Verzeichnisabgleich ihre Exchange Online Objekte verwalten.

Bitte deinstallieren sie nie die Agenten über die Systemsteuerung!

Deinstallation

Damit stellt sich die Frage, wie und wo sie den Exchange Hybrid Mode auflösen und wie der geregelte Prozess zur Deinstallation der verschiedenen Einstellungen ist. Während Sie einen selbst verwalteten Azure AD Application Proxy über das Entra ID-Portal steuern, ist das beim Exchange Hybrid Agent nicht so einfach möglich. Es gibt keine Verwaltung in der Cloud und lokal ist nur der HCW - Hybrid Configuration Wizard und in Grenzen die HybridManagment.psm1-PowerShell vorhanden.

Microsoft beschreibt aber ganz klar, wie die Deinstallation erfolgen sollte:


Quelle: https://learn.microsoft.com/en-us/exchange/hybrid-deployment/hybrid-agent#uninstall-the-hybrid-agent

Zufrieden bin ich mit der Aussage leider nicht, denn dass HCW für die Einrichtung genutzt wird, kann ich verstehen. Dass ich aber erst einmal die Hybrid Bereitstellung auf "Classic" umstellen muss, damit sich der HybridAgent auch korrekt deregistriert wird, verstehe ich nicht ganz. Es kann ja sein, dass der Exchange Server schon gar nicht mehr vorhanden ist oder die Deregistrierung fehlschlägt. Das hatte ich schon mehr als einmal, dass bei der Installation einer neuen Modern Hybrid Konfiguration die Registrierung eines Agenten daran scheiterte, dass es noch Altlasten gab. Das System "Hybrid Agent" besteht aus mehreren Bausteinen:

  • Hybrid Agent als Dienst auf ihrem Server
    Den könnten Sie einfach per Systemsteuerung deinstallieren.
  • AzureAppProxy Connector Group und Connector
    In EntraID wird der lokale Agent natürlich auch in einer Konfiguration abgebildet und Agenten werden in Gruppen zusammengefasst.
  • AppProxy Application
    Die Applikation ist dann die Konfiguration, welche Cloud-URL veröffentlicht wird und über welche Connector Group die Anfragen zu welchem Agenten gesendet wird. Der öffentliche Name ist dann das Ziel für den Exchange Migration Endpoint.
  • Migration Endpoint
    In Exchange Online wird dann diese URL als "OnPremises"-Migrations Endpunkt hinterlegt. Den Migrations-Endpunkt können Sie in der Exchange Online PowerShell sehen.

Unschön dabei ist, dass Sie all diese Konfigurationsobjekte nicht im Entra ID-Portal sehen können. einen Teil sehen sie über die PowerShell.

Deinstallation mit HCW

Wenn sie natürlich den geregelten Rückbau nutzen können, dann sollte der HCW beim Umstellung von "Modern" zu "Classic" den Hybrid Agenten entfernen und deregistrieren.

Interessanteweise lädt er dazu den Agenten frisch herunter, dass es die aktuelle MSI-Datei nutzt. Danach deinstalliert HCW erst den lokalen Service und dann kommt die eigentliche Deregistrierung. Die Deinstallation des Dient können Sie im Application-Eventlog nachverfolgen.

Erst danach startet HCW dann erst die weiteren Schritte zur Konfiguration des "Classic Hybrid".

Fiddler Analyse

Natürlich habe ich HCW nicht ohne Aufsicht arbeiten lassen. Mich hat insbesondere interessiert, wie er die Deregistrierung macht. Hier sehen Sie die beiden Downloads der MSI-Pakete aber dann zwei Graph-Aufrufe, die für die Deregistrierung zuständig sind:

Der erste Aufruf liefert die im Tenant konfigurierten Connectoren. Allein durch die Deinstallation des Diensts werden die Einträge nicht entfernt.

https://graph.microsoft.com/beta/onPremisesPublishingProfiles/applicationProxy/connectorGroups?$expand=members

Es gibt also den "EX01.UCLABOR.DE" noch als eigetragenen Connector. Der zweite Aufruf entfernt den Connector:

 

Ein einfacher Graph-Aufruf mit einen "PATCH" auf die TenantGUID und die AppID-GUID mit der folgenden Payload entfernt die Application

{
   "onPremisesPublishing":null
}

Das können Sie mit den entsprechenden Berechtigungen sogar per PowerShell selbst machen:

Connect-MgGraph `
           -TenantId msxfaqlab.onmicrosoft.com `
           -Scopes AuditLog.Read.All,Directory.AccessAsUser.All,email,openid,profile

Invoke-MGGraphRequest `
   -Uri "https://graph.microsoft.com/beta/463e98ae-b7d4-4af2-8ef8-3eda0b4d8a7c/applications/eb92551b-9c63-4472-a8dc-2be7fcf00313" `
   -Method PATCH `
   -Body '{"onPremisesPublishing": null}'

Das Entfernen der App ist aber kein Entfernen des registrierten Agenten!

Sie sollten immer wissen, was sie mit ihren Privilegien anstellen. Solche direkten Änderungen sind nur eine letzte Option, wen die regulären Wege nicht greifen und sie keine Zeit haben, das Problem mit einem Supporter durchzugehen.

Fehler durch Migrationjob

Bei meiner ersten Deinstallation im Lab habe ich übersehen, das ich noch einen "Pending Move Request" aktiv hatte. Ein Testpostfach wurde über den vorhandenen Migration Endpoint grade zu Exchange Online migriert. Daher konnte der HCW den Migration Endpoint nicht löschen.

Das ist schade, denn nun hatte ich eine Installation, in der es zwar keinen Hybrid Agent aber noch einen Migration Endpoint gibt. HCW prüft also vor der Deinstallation des HybridAgenten nicht, ob es noch aktive Verschiebeanforderungen mit dem Migrationsendpunkt gibt.

Das Ergebnis war, dass die Migration beim nächsten Lauf auf einen Fehler gelaufen ist. Ich musste die Migration dann abbrechen und löschen, damit ich auch den Migrationsendpunkt löschen konnte. Die Fehlermeldung ist aber aussagekräftig genug, dass die Ursache, hier der Batch "mig1" gefunden und dann mit einem "Retry" der Schritt wiederholt werden kann.

Warnung:
Warten Sie nicht zu lange mit dem Retry, den wenn das AuthToken im Hintergrund nach ca. 90 Minuten abläuft, dann kommt der HCW weder vor noch zurück. Beenden Sie dann HCW und starten sie neu

Dann läuft es doch daraus hinaus, den MigrationEndpoint per PowerShell manuell zu deinstallieren.

Offen

Aktuell sehe ich, dass HCW bei der Deinstallation die AzureAD Proxy Application entfernt, die in Entra ID die Verbindung der öffentlich erreichbaren URL zum Agenten entfernt. Auch der lokale Agent wird deinstalliert aber ich habe noch nicht gesehen, dass der Agent auch deregistriert wird. Wenn er sich aber nicht mehr bei Microsoft 365 meldet, wird er in den Status "inaktiv" versetzt.

Auf Hybrid Agent Installation habe ich die Installation beschrieben, bei der auch ein "Register-AppProxyConnector" ausgeführt wird. Dazu passend gibt es auch einen "Unregister-AppProxyConnector", der aber auch nur den lokalen Dienst deaktiviert aber keine Deregistrierung in AzureAD vornimmt.

Vielleicht wird er ja nach einiger Zeit Inaktivität bereinigt. Ansonsten stört er aber nicht und wenn Sie auf dem gleichen Server wieder einen Hybrid Agent installieren, dann wird der Eintrag einfach wieder reaktiviert.

Das Problem haben aber wohl auch andere. Manchmal blockiert dies sogar die Installation neuer Agenten.

Weitere Links