«

»

Projektart „Redesign“ im Migration Client

Beim Redesign-Projekt wird ein Share oder ein Share-Unterverzeichnis eingelesen. Die Berechtigungen können Sie sich in der Baumstruktur anzeigen lassen. Im Tabellen- und im Drag&Drop-Modus können Sie die Berechtigungen Ihren Vorstellungen entsprechend aufbauen. Abschließend wird ein Berechtigungs-Sollzustand mit von migRaven erstellten Berechtigungs- und Listgruppen aufgebaut. Diesen können Sie in den Deploy-Pfad schreiben, das kann ein leerer Share oder auch ein DFS sein.

1. Voraussetzungen

Bevor ein Projekt gestartet werden kann, muss ein Resource Scan Service in der Konfiguration angelegt werden.
Notwendig ist auch, zuvor die Berechtigunsggruppen zu konfigurieren.
Sie benötigen Lese-Rechte auf den zu lesenden Share.
Es muss ein Ziel-Share vorhanden sein, auf den Sie Schreibrechte haben. Sie werden dort Verzeichnisse anlegen und Gruppen und Nutzer berechtigen.
Sie müssen Administratorrechte auf die Domäne haben, in der Sie die Berechtigungsgruppen anlegen wollen.

2. Für einen Share oder ein Share-Unterverzeichnis ein Projekt anlegen.

2.1. Verzeichnisse und Berechtigungen einlesen

In migRaven wird immer mit Projekten gearbeitet. Ein Projekt ist die logische Einheit, die bearbeitet werden soll. Z.B. ein Share oder ein Verzeichnis unterhalb eines Shares. Am besten immer der Punkt, der auch bei den Usern gemountet oder im DFS eingebunden wird. Dadurch wird sichergestellt, dass alle Berechtigungen – einschließlich der Listberechtigungen – korrekt durch migRaven erstellt werden. Durch Aufruf einer der drei Projekt-Arten kommen Sie an den Punkt, wo neue Projekte erstellt und abgearbeitet werden können.

2.2. Best Practice: pro Share ein neues Projekt anlegen.

Wenn Sie die einzelnen Shares als eigenständige Projekte definieren, haben Sie Zeit, diese abzuarbeiten und „Step by Step“ die Daten in die neuen Verzeichnisse zu kopieren, um diese dann den Usern zuzuweisen.

2.3. Berechtigungen in eine CSV-Datei ausgeben und diese ggfs. als Grundlage für einen Tabellen-Import nutzen

Im Tabellenmodus ist es möglich, die Berechtigungen des eingelesenen Shares als CSV-Datei auszugeben. Sie können diese Datei nutzen, um Ungereimtheiten in den Berechtigungen zu suchen und zu klären. Nach entsprechender Bearbeitung können Sie sie auch als Grundlage für ein Tabellen-Import verwenden.

3. Die erforderlichen Eingaben

3.1. Projektname und Standard- oder Projektmodus

Redesign-Pro-Start

Projektbezeichnung

Hier ist eine eindeutige Projektbezeichnung einzugeben. Sie sollten einen Projektnamen eingeben, der Ihnen etwas sagt, wie z.B. „Buchhaltung“ oder „Einkauf“. Jedes Projekt muss einen anderen Namen erhalten.

Standardmodus oder Projektmodus

Beim Standardmodus werden Berechtigungsgruppen angelegt.

Wenn migRaven zusammen mit 8MAN eingesetzt werden soll, sind unbedingt spezielle Einstellungen zu beachten:

Es ist der Punkt „Einrichten für die sofortige Verwendung in 8MAN…“ anzuklicken. Damit erhalten die Berechtigungsgruppen weitere Attribute, die 8MAN für seine Arbeit benötigt. Einerseits wird im AD bei den Berechtigungsgruppen das Beschreibungs-Feld mit dem Ziel-Pfad und einem bestimmten Hashcode gefüllt. Und andererseits werden in den Verzeichnissen unter expliziten Berechtigungen .id.8MAN-Dateien für 8MAN angelegt. Weitere Anpassungen sind:

  • Die Namensgebung muss mit 8MAN identisch sein
  • Die OU, in der migRaven neue Gruppen erstellt, muss mit der in 8MAN identisch sein. Dabei ist zu beachten, dass die von migRaven automatisch erstellte OU mit dem Servernamen in 8MAN angegeben werden muss

Lesen Sie dazu unsere Arbeitsanleitung: Zusammenarbeit von migRaven und 8MAN

Beim Projektmodus werden keine zusätzlichen bzw. neuen Berechtigungsgruppen angelegt. migRaven verwendet dann die vorhandenen Gruppen. 8MAN-Kompatibilität wird nicht erzeugt.

3.2. Daten:  Einzelserver oder DFS, Pfadangaben, Scantiefe

Target:  DFS oder einzelner Server

Sie können wählen zwischen der Migration auf einem einzelnen Server oder in einem DFS.

Quellpfad, Ziel- und Deploy-Pfad

Hier müssen Quelle und Ziel angegeben werden.

Dafür wird das UNC-Format verwendet. Dabei sind zumindest Server und Share anzugeben. Es können Verzeichnis-Namen folgen.

Allgemeine Form:

\\Server\Share    oder   \\Server\Share\Verzeichnis1\…

Projekt1: „\\Server\Daten\Verwaltung\Buchhaltung“

Projekt2: „\\Server\Daten\Verwaltung\Einkauf“

Der Share „Daten“ ist die Ebene 0, das Verzeichnis „Verwaltung“ die Ebene 1, usw. Das ist besonders bei der Konfiguration der Listgruppen zu beachten.

Beispiel:

Quell-Pfad: „\\Server\Daten\Verwaltung\Finanzen“
Ziel-Pfad: „\\Server\Daten\Verwaltung\Buchhaltung“

Administrative Freigaben (c$, d$,..) sollten in diesen Pfadangaben nicht verwendet werden.

Dabei ist zu beachten, dass migRaven weder Berechtigungen vom Quell-Pfad übernimmt noch Berechtigungen auf den Ziel-Pfad vergibt. Das betrifft hier die Verzeichnisse „Daten“, „Verwaltung“ und „Finanzen“. Notwendige Berechtigungen auf den Ziel-Pfad, also auf „Buchhaltung“ und darüber, müssen Sie selbst vergeben. Nur die Verzeichnisse unter dem Quellpfad, also unter „Finanzen“, werden gescannt, mit Berechtigungsgruppen versehen und unter den Ziel-Pfad geschrieben.

Warum zwei Pfade fürs Ziel:  Ziel- und Deploy-Pfad?

Der Ziel-Pfad ist der endgültige Name für das Ergebnis der Migration, das kann auch der Quell-Pfad-Name sein.  Da man aber nicht in die Quelle schreiben sollte und es nicht zwei gleichnamige Shares geben kann,  gibt es zusätzlich den Deploy-Pfad. In diesen wird von migRaven die Berechtigungsstruktur geschrieben. Dann können die Daten kopiert werden. Erst dann wird der Share-Name des Quell-Pfads in einen beliebigen Namen geändert und der Deploy-Pfad erhält diesen Share-Namen. Und beim nächsten Anmelden erhalten die Nutzer die neue Struktur unter dem alten Namen.

Wenn beim Programmstart für Quelle und Ziel der gleiche Name angegeben wird, muss für das Schreiben der neuen Verzeichnisstruktur, dem Deploy ACL, ein abweichender Deploy-Pfad angegeben. Der Deploy-Pfad darf auf gar keinen Fall dem Quell-Pfad gleichen.

Ziel-Pfad

Dieses ist der Name, den unser migrierter Share endgültig erhalten soll.
Dieser Name kann dem Ausgangspfad entsprechen – das ist wohl der häufigste Fall. Er kann auch einen anderen Namen erhalten, wenn der endgültige Share-Name nicht dem Ausgangspfad entsprechen soll.

Warum ist dieser Name wichtig?

  • In die Namen der Berechtigungsgruppen fließt der Verzeichnisname ein und auch der Freigabename, wenn Sie ihn in der Gruppenkonfiguration ausgewählt haben. So können Sie leicht die Wirkungsstätte der Berechtigungsgruppe erkennen.
  • 8MAN arbeitet mit dem Gruppen-Beschreibungsfeld. Im Beschreibungsfeld zu jeder Berechtigungsgruppe steht der komplette Pfad mit Server, Freigabe und Verzeichnissen. Bei angepasster Konfiguration erstellt migRaven 8MAN-kompatible Gruppen. Dafür also unverzichtbar.

Deploy-Pfad

Wenn der Zielpfad dem Quellpfad entspricht, Sie also den Share-Namen beibehalten wollen, müssen Sie bei der Funktion „Deploy ACL“ einen anderen Deploy-Pfad angeben, damit Sie die neue Berechtigungsstruktur nicht in Ihr Quellverzeichnis schreiben. Der Name dieses alternativen Zielpfads ist gleichgültig, er darf nur dem Quellverzeichnis nicht gleichen, Sie können Ihm auch den Namen „Grüne Wiese“ geben.

Nach erfolgreicher Migration und Kopieren der Daten können Sie den Quell-Share umbenennen und dem Zielpfad („Grüne Wiese„) den ursprünglichen Namen des Quell-Shares geben.

Zu beachten ist

  • die angegebenen Pfade werden vor dem Scannen auf ihre Existenz geprüft,
  • entsprechend Ihrer Windows-Anmeldung kann migRaven nur die Verzeichnisse scannen, auf die Sie auch zugreifen dürfen,
  • auf den Deploypfad und die OU für die Berechtigungsgruppen müssen Sie Schreibrechte haben, deshalb müssen Sie das Programm immer als Administrator ausführen.

Scantiefe

Ist nicht mehr auswählbar. Es wird bis zur untersten Ebene gescannt. Das ist notwendig, um für die Auswertungen mit dem Web Client alle Verzeichnisse, Berechtigungen und Dateien zu erfassen.

Redesign-Pro-2-S

Share bzw. Share-Unterverzeichnis eines einzelnen Servers scannen

Redesign-Pro-2-D

Scannen eines DFS

3.3. optional: Type  – Gruppentype und AD-OU

Diese Angaben haben Sie schon in der Konfiguration festgelegt, können sie hier aber ausschließlich für dieses Projekt ändern. Hier können Sie die AD-OU, in der die Berechtigungsgruppen abgelegt werden sollen, modifizieren. Das ist sicher dann sinnvoll, wenn Sie Data-Owner haben, die in ihrem Bereich Berechtigungen vergeben und dann auch nur in Ihrer OU schreiben dürfen.

Redesign-Pro-3-T

3.4. optional: Name – Aufbau der Gruppennamen

Auch diese Angaben wurden schon in der Konfiguration festgelegt. Sie können Sie hier  für dieses Projekt ändern. Sie können den Aufbau der Namen für die Berechtigungsgruppen, die Bestandteile und deren Reihenfolge verändern.

Redesign-Pro-4-N

3.5. optional: List-Rechte

Hier können Sie, abweichend von der Konfiguration, festlegen, ob Listgruppen angelegt werden sollen und in welchen Ebenen.

Redesign-Pro-5-L

3.6. Zusammenfassung und Start

Auf dem letzten Reiter werden die ausgewählten Parameter zusammengefasst angezeigt.

Threads zum Scan

Wird bei der neuen Version selbst ermittelt.

Anzahl der Dateien und Größen sammeln

Es werden alle Verzeichnisse und Dateinamen mit Parametern, wie Berechtigungen (ACLs), Dateigrößen und Erstellungsdaten, gespeichert.

Einlesen starten

Nachdem wir die Felder gefüllt haben, können wir das Projekt starten.

 

Redesign-Pro-6-Z

4. Der Projektscan

Die Verzeichnisse und Berechtigungen des angegebenen Ausgangsverzeichnisses werden eingelesen und in der eigenen Datenbank abgelegt.

 

Scan Status Arbeitsschritt Verzeichnis
Scannen… Der Ausgangsshare wird gescannt, die Daten in Dateiform zwischengespeichert. c:\ProgramData\migRaven\ResourceScanService\
Speichert zur Db… Die Daten werden in die Datenbank übernommen. c:\Program Files\migRavenDB\data\databases\graph.db\
Speichern abgeschlossen Der Share wurde gescannt. Sie können ihn sich im View ansehen: AD ansehen

 

5. Mögliche Probleme beim Projektscan

.

Der Projektscan startet nicht
Voraussetzung für den Projektscan ist, dass alle Dienste gestartet sind und zusammenarbeiten. Kontrollieren Sie in der Diensteverwaltung, ob alle Dienste laufen.
Die Verbindung zu einem entferneten Server kann durch eine Firewall verhindert werden. Geben Sie bitte die von migRaven benötigten Ports frei.

 

Fehlermeldung: „Remote Service Errors…“
Durch Anklicken der Fehlermeldung werden Sie zu dem defekten Dienst (rot gekennzeichnet) geleitet. Durch „Aktualisieren“ des Dienstes können Sie den Fehler meist beheben. Dabei wird der Dienst nicht neu gestartet, sondern es wird der Eintrag des Dienstes in der Datenbank aktualisiert.