Migration vom Account-Forest in den Exchange-Resource-Forest

Dieser Artikel erläutert die Migration von Active-Directory Benutzern einer sogenannten Account-Forest-Domäne in eine Domäne des Exchange-Ressourcen-Forest, einschließlich der Umwandlung von verknüpften in reguläre Postfächer.

Das Betreiben einer Exchange-Installation in einem separaten Forest hat den Vorteil, dass Exchange-Schemaerweiterungen vollständig vom Account-Forest getrennt sind, zu der die Kontendomäne gehört. Es ist auch eine Verwaltungsgrenze, wenn beispielsweise Exchange von einem Hosting-Unternehmen bereitgestellt wird.

Andererseits steigt die Komplexität der Umgebung und zusätzliche Domänencontroller werden benötigt, um die man sich kümmern muss.

Inhaltsverzeichnis:

1. Überblick
2. Vor der Migration
3. Migration der Benutzer und Konvertierung der Postfächer
4. Nach der Cross-Forest Migration
5. Fazit

Überblick

Dieses Szenario basiert auf einer tatsächlichen Kundenanfrage, die wir kürzlich erhalten haben. Es gibt zwei Forests, einen sogenannten Account-Forest, mit Benutzerkonten, Gruppen und OUs, und einen zweiten Forest, den Exchange-Resource-Forest, in dem Microsoft Exchange installiert ist und Postfächer gehostet werden. Der Kunde stand vor der Aufgabe, die Domäne des Kontenforests mit der Domäne des Exchange-Ressourcenforests zu konsolidieren, mit dem Ziel die Kontendomäne abzuschaffen.

Wenn Exchange in einem eigenen Active-Directory Forest betrieben wird, werden Postfächer als so-genannte verknüpfte Postfächer eingerichtet. Jedes Postfach hat ein deaktiviertes Benutzerkonto in der Domäne des Exchange Forests und die Postfächer sind so konfiguriert, dass dem entsprechenden Benutzerkonto aus dem Konten-Forest Zugriff gewährt wird.

Während der Migration müssen die Postfächer von verknüpften Postfächern in reguläre Postfächer umgewandelt werden. Das deaktivierte Benutzerkonto in der Zieldomäne muss mit dem Benutzer aus der Kontodomäne zusammengeführt werden. Beispielsweise muss das displayName-Attribut des Kontos in der Zieldomäne beibehalten werden, das in den Exchange-Adressbüchern verwendet wird, während das Benutzerkennwort mit dem der Quelldomäne aktualisiert wird.

CopyRight2 wurde auf einem Server der Exchange-Ressourcendomäne installiert. Optional kann es auch auf einem Domänencontroller installiert werden, um die Performance zu maximieren. Neben der Ausführung in der Zieldomäne (Pull-Konfiguration) können Sie die gleichen Einstellungen verwenden, wenn Sie die Ausführung in der Quelldomäne bevorzugen (Push-Konfiguration).

Zusätzlich zu CopyRight2 wurden das CopyRight2 Password Migration Add-On und das PowerShell Integration Add-On auf demselben Server installiert, um die Migration von Benutzerpasswörtern und die Verwendung der Exchange PowerShell Commandlets zu ermöglichen.

Obwohl dies auch ganz ohne PowerShell möglich ist, indem einfach die entsprechenden Active Directory-Attribute geändert werden, bevorzugen wir, den von Microsoft empfohlenen Ansatz zu verfolgen. Dies gibt uns zusätzlich die Möglichkeit zu zeigen, wie man PowerShell Commandlets mit CopyRight2's PowerShell Integration Add-On aufruft.

Vor der Migration

Vor der Migration melden sich Benutzer mit ihrem entsprechenden, sich in der Domäne des Account-Forests befindenen Konto an. Die verknüpften Postfächer gewähren Berechtigungen, die es ihnen ermöglicht, mit Microsoft Outlook auf ihre Postfächer zuzugreifen.

Migration der Benutzer und Konvertierung der Postfächer

Um die eigentliche Migration durchzuführen, müssen Sie zunächst einen Benutzer- und Gruppenmigrationsauftrag in CopyRight2 definieren:

Auf der "Source and Destination" Seite geben wir die NetBIOS-Namen des Quell- und des Zieldomänencontrollers an:

Nun müssen wir die Benutzerkonten auswählen, die in die Zieldomäne migriert werden sollen:

Auf der "Filter" Seite aktivieren wir die Migration von Benutzern. Der Einfachheit halber migrieren wir keine anderen Objekttypen, wie z.B. domänenlokale Gruppen, globale Gruppen, universelle Gruppen, Verteilerlisten oder Kontakte. Es ist wichtig, den Objekttyp als Hinzufügen/Aktualisieren zu konfigurieren, da wir möchten, dass der Auftrag das vorhandene und derzeit deaktivierte Postfachkonto in der Zieldomäne aktualisiert:

Als nächstes aktivieren wir auf der "Settings" Seite die Migration von Passwörtern:

Um die OU-Hierarchie in die Zieldomäne zu migrieren, wird die entsprechende Option der "Active Directory Options" Seite ausgewählt. In diesem Beispiel wird die Hierarchie unterhalb des Stammverzeichnisses der Zieldomäne kopiert. Alternativ könnte die Hierarchie auch unterhalb einer bestimmten Organisationseinheit migriert werden. CopyRight2 migriert die übergeordneten Organisationseinheiten jedes migrierten Objekts automatisch:

Auf der "AD Attribute" Seite entfernen wir displayName aus der Liste der zu migrierenden Attribute. Dies geschieht, um den Anzeigenamen der deaktivierten Konten zu erhalten, die mit jedem Postfach in der Zieldomäne verbunden sind, da der Anzeigename in Adressbüchern verwendet wird. Wenn weitere Attribute beibehalten werden sollen z. B. Vorname, Nachname usw., können diese ebenfalls entfernt werden:

Auf der "Advanced" Seite muss die Option "Map security identifiers with a predefined mapping table" aktiviert werden, um die Beziehung zwischen dem samAccountName von Konten in der Quell- und der Zieldomäne zu definieren. Die Zuordnung ist nicht erforderlich, wenn das Attribut samAccountName in beiden Domänen identisch ist:

Die Mapping-Datei ist eine einfache Textdatei mit einer Zeile pro zugeordnetem Benutzerkonto im folgenden Format:

Source-Domain-NetBIOS-Name\Account-Name;Destination-Domain-NetBIOS-Name\Account-Name;3

Um Exchange Management Commandlets aufrufen zu können, müssen wir zunächst Add-PSsnapin von PowerShell aufrufen. Dies geschieht in einem Skript des Typs "Job Start", welches bei jeder Ausführung des CopyRight2-Auftrags einmalig ausgeführt wird:

Dem Aufruf ist ein "#“ vorangestellt, um anzuzeigen, dass es sich um einen PowerShell-Befehl handelt, und um ihn von normalem VBScript (Scripting Host) zu unterscheiden. Hier ist die Codezeile in ihrer Gesamtheit:

#Add-PSsnapin -Name "Microsoft.Exchange.Management.PowerShell.SnapIn" -ErrorAction "SilentlyContinue"

Als Nächstes ändern wir den Skripttyp in "Transform Users", um das Scriptlet zu definieren, das einmal für jedes migrierte Benutzerobjekt ausgeführt wird:

Das Skript übergibt das "mail" Attribut des Quellkontos, welches die SMTP-Adresse enthält, an den "identity" Parameter des PowerShell Commandlet "set-user". Um den Inhalt des "mail" Attributs zu ermitteln, wird CopyRight2's Scripting-Host-Funktion Source() mit dem Attributsnamen als Parameter verwendet:

#set-user -Identity Source("mail") -LinkedMasterAccount $null

Sie könnten dasselbe erreichen, ohne auf PowerShell zurückzugreifen, indem Sie stattdessen das folgende Skript verwenden. Dieses Skript verwendet die Funktion Destination(), welche wie Source() den Attributsnamen als Parameter hat, um auf die Attribute des Zielobjekts zuzugreifen:

Destination("msExchRecipientDisplayType")=0
Destination("msExchRecipientTypeDetails")=1
Destination("msExchMasterAccountSid")=Empty

Dies ist jedoch nicht empfehlenswert und sollte als Hack betrachtet werden, da sich beispielsweise die betroffenen Attribute ändern könnten. Die Liste der oben genannten Attribute wurde ermittelt, indem ein LDIFDE-Export für ein Konto vor und nach der Ausführung des Commandlets "set-user" durchgeführt und die Ergebnisse verglichen wurden.

Nach der Cross-Forest Migration

Nach Ausführung des Migrationsauftrags werden Sie feststellen, dass das zuvor deaktivierte Konto in der Zieldomäne, das mit dem entsprechenden Postfach verknüpft ist, nun aktiviert ist und dass dieses Postfach nun als reguläres statt als verknüpftes Postfach angezeigt wird. Außerdem wurde das Kennwort migriert, so dass sich die Benutzer tatsächlich mit diesem Konto anmelden und auf das Postfach zugreifen kann.

Fazit

Nach der Lektüre dieses Artikels sollten Sie nun wissen, wie Sie Migration einer Domäne des Account Forests zu einer Exchange-Resource-Forest-Domäne realisieren können. Sie werden auch erfahren haben, wie PowerShell-Skripte in die CopyRight2 Scripting Host-Implementierung integriert werden können.

Sollten Sie positives oder negatives Feedback oder weitere Fragen haben, lassen Sie es uns bitte in den Kommentaren unten wissen. Danke schön.