Ressource Forest Konsolidierung

Inhaltsverzeichnis

Worum geht es?
Kurzfassung Ressource Forest?
Umzug in die Cloud
Rückbau Ressource Forest
Grobplanung
Weitere Links

Gehören Sie zu den Firmen, die eine "Ressource Forest Konfiguration" betreiben und mit der Migration der meisten Exchange Postfächer zu Exchange Online den nun quasi leeren lokalen Exchange Forest loswerden wollen? Dann ist diese Seite für sie passend:

Worum geht es?

Es gibt Umgebungen, in denen das Anmeldekonto eines Anwenders in einem so genannten "Account Forest" liegt während die Exchange Postfach-Informationen und Exchange Server in einem zweiten separaten Resource-Forests vorgehalten werden.

Mit der Migration zu Exchange Online wird dieser Ressource Forest immer unwichtiger und am Ende möchten Sie vielleicht einfach diesen Forest eliminieren.

Kurzfassung Ressource Forest?

Die vermutlich überwiegende Anzahl der Exchange Installationen erfolgten im gleichen AD-Forest, in dem auch die Benutzer als AD-Konten verwaltet werden. Es gibt aber auch Firmen, in denen die Dienste "Exchange" und damals auch "OCS/Lync/Skype for Business" in einen eigenen Forest ausgelagert wurden. Viele Firmen hatten vor dem Jahr 2000 noch Exchange 5.5 und NT4-Domains mit Vertrauensstellungen und weil damals WAN-Bandbreiten kostbar waren oder verschiedene Firmen eines Konzepts autarke Administratoren hatten, wollte man diese Domains nicht in einem Forest zusammenfassen. Man wollte aber schon die Vorteile einer gemeinsamen "Exchange Organisation" nutzen und so wurden dann die Exchange UC-Server in einem eigenen Ressource Forest installiert während die Anmeldekonten und Computer in separaten Forests unter dezentraler Zuständigkeit und Administration betrieben wurden.

Ich habe dazu gerne "Lauter kleine Königreiche" gesagt, weil jede Tochtergesellschaft oder Landesgesellschaft seine Eigenständigkeit bewahren wollte.

Technisch hat der Exchange Ressourceforest dann dem Anmeldekonto vertraut und die Exchange Administratoren haben für jeden Benutzer einen eigenen Disabled Account angelegt und als LinkedMailbox konfiguriert. Über das Feld "msExchMasterAccountSID" wurde die Verbindung zum eigentlichen Anmeldekonto hergestellt.

Umzug in die Cloud

Wenn nun so eine Umgebung zu Exchange Online migriert werden soll, dann können Sie den Tenant quasi wie einen Ressource Forest ansehen, nur dass hier die Anmeldekonten und die Exchange Informationen zusammengeführt werden müssen. In Microsoft 365 gibt es keine Möglichkeit, die Anmeldekonten in einem separaten Tenant zu verwalten und denken Sie erst gar nicht darüber nach, so etwas mit einem "Gast-Account" abbilden zu wollen.

Wenn Sie mir das nicht glauben, dann können wir gerne mal an einem große Whiteboard die ganzen Abhängigkeiten und ihre Fragen und Vorstellungen auf die Umsetzbarkeit prüfen.

Sie haben nun aber zwei Optionen, in die Cloud zu migrieren und damit letztlich ihren Exchange Ressource Forest zu eliminieren:

Cross Org Migration vor Cloud Migration
Es gabe eine Zeit vor der Cloud und hierbei wir eine Ressourceforest-Topologie im Rahmen einer Domain- und Forest-Konsolidierung zusammengeführt und damit auch die Anmeldekonten aus mehreren Forest z.B. mit ADMT -Active Directory Migration Toolkit konsolidiert und/oder die Exchange Organisation mit einer CrossOrg-Migration und Prepare-Moverequest.ps1 in den gewünschten Forest überführt. Der finale "Single AD-Forest mit Exchange" kann dann wieder klassische mit Microsoft 365 verbunden werden.
"Cloud Migration first" und Rückbau
Wenn Sie aber heute noch eine Ressourceforest-Umgebung verwenden, dann würde ich lieber direkt die Postfächer in die Cloud migrieren und eine zusätzliche CrossOrg-Migration vermeiden.

Vermutlich haben Sie sogar schon mit ihrer Ressourceforest-Umgebung eine Anbindung an Microsoft 365 und Exchange Online mittels ADSync hergestellt. Das ist gar nicht mal schwer, wenn ihre Stammdaten sauber gepflegt sind und sie bei der Einrichtung von ADSync/Entra ID Connect ein paar Besonderheiten beachtet haben. Wenn Sie alles richtig gemacht haben, dann sollten sie im AzureAD für jede Identität genau einen Benutzer haben, der aus dem jeweiligen Account Forest die Informationen zu Vorname, Nachname, UPN, Kennwort, Gruppenmitgliedschaften erhält und die für Exchange relevanten Informationen aus dem Exchange Ressource Forests beigeliefert werden. Die beiden folgenden Seiten beschreiben diese Anforderungen ausführlicher.

Rückbau Ressource Forest

Im Idealfall sind am Ende alle Postfächer in Exchange Online und im lokalen Exchange Ressource Forest gibt es nur noch die Verteilergruppen und die deaktivierten Benutzer als "Remote Linked Mailbox". Sie brauchen den lokalen Exchange Server eigentlich nur noch für folgende drei Aufgaben:

Management per ECP mit RBAC Rollen oder Anbindung als IDM
Größere Firmen, die damals überhaupt nur einen Ressourceforest umgesetzt haben, verwalten ihre Konten in der Regel nicht manuell sondern automatisiert per Identity Management, welches seinerseits die Exchange PowerShell nutzt. Die Umstellung solcher Prozesse kann einige Zeit dauern, auch wenn mit der Exchange Management Rolle mittlerweile eine Verwaltung ohne Exchange Server möglich ist.
"Sichereres“ Mailrouting für interne Systeme
Auch wenn die Postfächer alle in Exchange Online sind, haben viele Firmen lokale Dienste, die per SMTP Mails einliefern oder bekommen und nicht direkt mit dem "Internet" oder Microsoft 365 kommunizieren dürfen oder einfach die Anmeldung per OAUTH2 / Modern Authentication/ Exchange Online Authentifizierung nicht unterstützen und daher einen Art Hybrid Connector Server weiter betreiben. Für diesen Rumpfserver möchten Sie aber vermutlich keinen Ressource Forests-Betrieb aufrechterhalten
Sonder-Postfächer
Zudem kann es besondere Postfächer geben, die z.B. aufgrund der Größe, des Zugriffs oder Datenschutzfragen nicht zu Exchange Online verschoben werden können. Sie auch Exchange Online Message Rate Grenzen

In vielen Fällen müssen Sie sich Gedanken über den Betrieb eines LES - Last Exchange Server machen, der dann aber nicht alleine in einem Ressource Forest stehen muss. Also müssen wir für die wenigen verbliebenen Diensten überlegen, wie wir diese in die Zielplattform umziehen. Ich skizziere einmal die wichtigsten Schritte, die aber keine Blaupause darstellen können.

Solche Kombinationen aus Ressourceforest mit CrossOrg-Migration und gleichzeitigem Betrieb als Hybrid mit Ressource Forest sind keine "Standardinstallationen". Wir können aber gerne im Rahmen eines Auftrags sie bei der Planung und Umsetzung unterstützen. -> Net at Work und MSXFAQ

Zur Vereinfachung gehe ich mal davon aus, dass ihr Exchange Ressoure Forest aktuell noch zur Verwaltung von Empfängern und zum Mailrouting verwendet wird, aber keine Postfächer oder gar öffentlichen Ordner mehr vorhanden sind. Eine CrossOrg von Postfächern während schon parallel ein Hybrid mit Ressource Forest konfiguriert ist, sprengt den Rahmen dieser Seite. Dann müssten Sie z.B. für jede Mailbox im Ressource Forest einen MailUser im Accountforest z.B. durch Prepare-Moverequest.ps1 anlegen lassen, der aber noch nicht durch ADSync beachtet wird. Ansonsten würden sich die Exchange Attribute überschreiben. Auch mit Mitgliedschaft in Gruppen und deren Abgleich zwischen zwei Forests mit einem ADSync und einem Tenant muss sauber geplant werden. Wenn dann noch ein Identity-System involviert ist, können wir die Komplexität fast endlich steigern.

Grobplanung

Wenn Sie aber wirklich nur die Funktion "Recipient Management" und vielleicht Mailrouting umstellen wollen, dann könnte folgende Vorgehensweise funktionieren:

Schritt	Erledigt
ADSync Healtchcheck Zuerst sollten wir sicherstellen, dass die ADSync Konfiguration korrekt ist, d.h. aus dem Account Forest müssen die Daten für Vorname, Nachname, Company aber auch UPN kommen während alle Exchange Informationen zu den "Linked Remote Mailboxen" aus dem Ressource Forest kommen. Die eigentliche Exchange Hybrid Konfiguration mit Connectoren und FreeBusy etc. haben nichts mit ADSync zu tun.
Migration zu Exchange Online Sofern sie noch Postfächer finden, die lokal liegen und sowieso zu Exchange Online migriert werden sollten, dann ist nun der Zeitpunkt dies zu tun. Ansonsten müssen Sie später bei der Umstellung diese Postfächer per CrossOrg migrieren. Auch beim Mailrouting bitte ich sie genau zu prüfen, ob der Ressource Forest noch SMTP/IMAPPOP/MAPI/EWS-Dienste für Systeme bereitstellt und ob diese Funktion auch nach der Abschaltung des Ressource Forest noch erforderlich ist. Wenn Sie es jetzt schon migrieren oder abschalten können, dann ersparen sie die Neuinstallation eines Exchange Server im Account Forest und die Migration der Dienste.
Exchange im Account Forest Sie müssen auch nach der Abschaltung des Ressoure Forest beim Einsatz des Verzeichnisabgleichs mit ADSync/Entra ID Connect/Entra ID CloudSync weiterhin die Exchange Empfänger im lokalen AD verwalten. Daher müssen wir im Account Forest mindestens die Exchange Management Rolle installieren. Wer auch das Mailrouting bereitstellen muss oder die Exchange Remote PowerShell für das Provisioning mit RBAC - Role Based Access Control benötigt, installiert am besten einen Exchange Server, der später mit dem HCW - Hybrid Configuration Wizard als reiner Hybrid Connector Server ohne Postfächer lizenziert wird. Achtung Ein neuer Exchange Server veröffentlicht sich im AD mittels SCP und die Client finden den Server. Siehe auch Autodiscover und SCP. Sie sollten umgehend den SCP wieder löschen oder die Internal/ExternalURLs konfigurieren. Da der neue Server später vermutlich unter den gleichen URLs und IP-Adressen erreichbar sein soll, können Sie aus dem Ressource Forest schon die Konfiguration übernehmen. Ich denke da an: Empfängerrichtlinien Damit die zukünfigen Empfänger auch die gleichen Adressen wieder bekommen. Ggfls. müssen Sie hier aber Anpassungen vornehmen, wenn die OU-Struktur oder Filterkriterien abweichen. RemoteDomains Auch hier wird zwar der HCW später seine Domain addieren, aber ich lege diese schon vorher an und achte auf auf das Feld "RemoteRoutingDomain", damit ich später ein Enable-RemoteMailbox machen kann. Empfangsconnectoren Auch hier wird der HCW später die "CloudServiceMail"-Schalter setzen, aber vieleicht haben Sie noch weitere eigene Connecetoren, damit z.B. ein ERP-System über Exchange als Relay ins Internet darf. Sendconnectoren Wenn Sie bestimmte Domains im Ressource Forest z.B. an ERP-Systeme oder Partner abweichend routen, dann sollten Sie dies im Account Forest identisch einrichten. Internal/External URLs Auch hier sollten sie dem neuen Server direkt die URLS geben, die auf den Ressource Forest verweisen und später auf ihn umgestellt werden. Zertifikate Anfangs wird kein Client den neuen Server fragen aber für das spätere Mailrouting mit Exchange Online und den Zugriff per HTTPS sind gültige Zertifikate notwendig. Mit etwas Glück können Sie diese auf dem Quellserver einfach samt privatem Schlüssel exportieren. Dies hilft dann auch den Client, die nun vermutlich per SCP schon die neuen Server "sehen". In dem Zuge wird auch das AD Schema um die Exchange Felder erweitert. Wenn der Server später wieder Postfächer betreiben muss, dann brauchen Sie passenden Lizenzen und natürlich auch Datensicherung, Monitoring etc.
EntraID Connect und Schema Die Schema-Erweiterung des Account Forest wird von Entra ID Connect nicht automatisch erkannt. Sie müssen über das Setup das Schema neu einlesen, damit dann auch die "Exchange Synchronization Rules" für den Account Forest addiert werden. Das bedeutet in der Regel ein "Full Sync". Es sollte aber nichts passieren, da die neuen Felder im Account Forest ja noch "leer" sind. Sie sind aber in der Reihenfolge "vor" dem Exchange Ressource Forest und das ist wichtig.
Copy/Sync Recipient Properties Nun geht es darum, alle Exchange Informationen der Linked Remote Mailboxen und Verteiler aus dem Ressource Forest auf die "passenden" Felder des Account Forest zu kopieren. Es gibt hier keine "fertigen Skripte" von Microsoft aber im Grunde sind bei einer Remote Linked Mailbox nur folgenden Felder relevant. msExchRemoteRecipientType und msExchRecipientTypeDetails Die müssen Sie nicht von Hand setzen, da ein "Enabled-RemoteMailbox" diese setzt. Mailnickname (Alias) Auch das Feld ist essentiell für Exchange und wird oft als Baustein bei den Empfängerrichtlinien verwendet. Daher kopiere ich es mit. Mailadresse Idealerweise ist diese Adresse im Account Forest schon vorhanden und kann zum Matching genutzt werden. Ansonsten muss man die msExchMasterAccountSID nutzen. ProxyAddresses Natürlich werden wir alle zusätzlichen Adressen ebenfalls mitnehmen. Wer es perfekt macht, erweitert die durch Enable-RemoteMailbox schon gesetzten Felder und addiert auch den alten LegacyExchangeDN als zusätzliche X500-Adresse. Exchange Online ist dies aber relativ egal. RemoteRoutingAddress Diese Adresse muss die gleich MOERA-Adresse enthalten, wie der Ressource Forest, wenn der neue Exchange Server im Account forest auch Mails entsprechend routen soll. Die Connectoren sind aber noch nicht konfiguriert aber noch sendet ja auch niemand etwas an die Exchange Server im Account Forest Ich exportiere mir die Werte aus der Quelle einfach mit "Get-Recipient" bzw. "Get-RemoteMalbox" in eine CSV-Datei, um diese dann im Ziel wieder als Quelle für einen Schleife mit "Enabled-RemoteMailbox/Set-RemoteMailbox" zu nutzen. Ich werde das Skript hier nicht posten, da mir das Risiko zu groß ist, dass jemand die Checkliste ohne tieferes Verständnis stumpf abarbeitet, dann scheitert und am ende mir die Schuld zuschieben möchte. Wer das Thema verstanden hat, sollte in wenigen Minuten die passenden Befehle selbst geschrieben und getestet haben. Vergessen Sie bei all diesen Optionen nicht die Verteiler und Mail Contacts und andere Exchange Empfänger, die es vielleicht nur im Ressource Forest gibt. Eventuell müssen Sie diese auch im Account Forest ebenfalls anlegen.
Frozen Zone/Meilenstein Wenn Sie bislang alle srichtig gemacht haben, dann sollte ADSync nun die Exchange Informationen aus dem Account Forest lesen und diese die Einstellungen im Ressource Forest überstimmen. Sie können die ja mal mit einem Testbenutzer prüfen. Wenn Die so ist, dann bedeutet dies, dass Sie ab sofort die Exchange Empänger nur noch im Account Forest verwalten sollten und der Ressource Forest quasi immer weiter veraltet. Also muss er möglichst bald entfernt werden.
Mailrouting/Hybrid Sollten Sie im Account Forest wirklich wieder einen Exchange Server aufgebaut haben, so muss dieser nun die Hybrid-Verbindung und die Connectoren betreiben. Eine sinnvolle parallele Konfiguration von zwei Exchange Organisationen mit Hybrid Bereitstellung ist bei der gleichen SMTP-Domain eigentlich nicht möglich und sie sollten daher einen Zeitraum, meist weniger als 1h, vorsehen, um die Dienste umzustellen. Sie könnten z.B. den Exchange Servern im Ressource Forest "in Wartung" setzen und das Leerlaufen der Queues abwarten, ehe Sie diesen dann die IP-Adressen entfernen und diese dem neuen Server übertragen. Nun können Sie auch die Hybrid Konfiguration mit dem neuen Server im Account Forest durchführen, der ja quasi unter den gleichen Namen erreichbar ist.
ADSync Connection Wenn das Routing und Hybrid über die neuen Server im Account Forest laufen, dann hat der Ressource Forest nichts mehr zu tun, Eher wir aber dort die Empfänger alle deaktivieren, entfernen wir in Entra ID Connect die Verbindung zum Ressource Forest. Das ist für viele ein heikler Moment, denn beim nächsten "Full Import" wir Entra ID Connect auch einen "DELETE" durch den Wegfall erkennen aber da die gleichen Daten aus dem Account Forest kommen, sollte zur Cloud keine Änderung geschrieben werden. Dennoch mache ich diesen Schritt immer erst einmal manuell, d.h. ich schalte den DirSync ab oder stelle ihn auf "Staging" und kontrollieren, was als "Pending Export" in die Cloud ansteht.
Rückbau Ressource Forest Skype/Lync Denken Sie daran, dass das "Ressource Forest"-Modell nicht nur für Exchange sondern auch für OCS/Lync/Skype for Business genutzt wurde und der Forest vieleicht noch für andere Dienste erforderlich ist. Ich überlasse es ihnen, ob sie danach alle Exchange Empfänger mit "Disable-RemoteMailbox" im Ressource Forest entfernen um danach die Exchange Server zu deinstallieren und schlussendlich den Trust und die Domain zu löschen. Einige Firmen fahren die Server einfach alle herunter und formatieren Sie nach einer Wartezeit. Den Trust im Account-Forest können Sie jederzeit löschen. Es mag etwas längerer dauern, aber ich betrachte mir die eigentlich "untätigen" Server noch einige Tage, ob wirklich alle Mailversendet und Clientzugriffe umgeschaltet wurden. Das Messagetrackinglog nud das IIS-Log sind hier gute Quellen, ehe ich dann den Server klassisch deinstalliere.