Instructions: migrating a file system

1. Create project and read in directories

1.1. Create new project - read in directories and authorizations

In migRaven, one always works with projects. A project is a logical unit, which is to be processed, for example a share or a directory below a share. Best is the point which is mounted in case of users or integrated into the DFS. Thus one ensures that all Authorizations - including the list of authorizations - are correctly created by migRaven, Via the title "Administer projects", you arrive at the point, where new projects can be created, processed or deleted.

The prerequisite for creating new projects is at least the domain was scanned once.

Project Start

1.2. Best Practice: Create a new project by share.

If you define the individual shares as independent projects, then you have time to process it in peace and copy the data into new directories "Step by Step" and then assign to the users.

For example Project1: "\\ server \ data \ management \ accounting"

Project2: "\\ server \ data \ management \ purchase" etc.

Then enter the UNC path till the directory (project) to be scanned. Please check once again if this path is attainable, above all with your login data.

Please consider: According to your Windows login, MigRaven can only scan the directories, which you may access, therefore you must execute the program always as administrator.

1.3. Scan depth and threads for scan:

These settings have significant effects on the size of the database and the speed of the scan.

1.4. Scan depth:

The scan depth should be as low as you can to select and set the authorizations in the folders. (The more deep a scan is, the longer it takes to scan and the larger becomes the database.)

1.5. Threads for scanning:

The more threads you select, the higher the process load is. Recommendation: max. 2 threads / core. You immediately experience while scanning there are too many threads. This makes the java process noticeable.

2. Revise / redefine authorizations

2.1. Via the "Work & Design" screen, you can check, process or redefine all explicit authorizations.

Select here the directory depth relevant for you. If you want to assign 3rd level authorizations only then select 3 in the field "Export till level". Via the button "Fill table", the data is loaded from the database.

Only change directories of this type in the list:

  • With explicit available authorizations
  • Only standard authorizations
  • Only domain accounts (Local and "Well Known" users / groups are hidden; well known accounts are the standard accounts, which Microsoft always includes.)

In this regard, all relevant authorizations can be defined in the respective directories.

For this enter the appropriate account in the column, which represents the desired right. Here are two variants are selected:

  1. The groups, which are entered there, are thus written directly in the ACL. This enables the reuse of already available authorization groups.
  1. Accounts and groups are entered, which then become members of an authorization group migRaven, This can be set via the group configuration

In the table you can:

  • Insert new rows, for directories, which are authorized, but are not yet included
  • Remove accounts from columns
  • Add new accounts / groups in columns in the format: Domain \ Login name (SAM) -> test \ f.Kafka
    (If you want to authorize several accounts / groups, then these are to be separated with a semicolon.)
  • Sort, filter columns
  • Add and delete rows

After the processing, the "validation" takes place. Thereby the values ​​of the table are checked for consistency. One tries to cancel the directory paths and the accounts. This happens against the real systems.

After the successful validation, the data are transferred into the database. At the same time the status of the project is upgraded in the database, and the prerequisite for this is the next steps can be carried out.

3. Prepare new groups in migRaven

3.1. In this step the groups are formed and nested by migRaven within the database.

In addition to this, the following must be determined in the group configuration:

  • The type of group
  • The naming of the groups
  • How far should the list be right
  • The storage location of the (OU) groups

The last step does not take place in the AD and / or on the file system, whichever

  • The groups of migRaven are automatically created and nested in AD and
  • The actual implementation takes place in the file system.

Hereby one complies with the group configuration (domain local or universal groups, list authorizations or not, etc.)

4. Create and nest new groups

In this step, the groups are finally created and nested in the AD.

4.1. migRaven carries out the following steps:

  • The groups are created LIVE in the AD,
  • The authorization groups with the list groups are nested and
  • The users / groups are included in the authorization groups.
  • The authorization / list groups are automatically stored in OU, which must be defined in the group configuration.

If these steps are completed, it has been completed in the next step through migRaven, Please be cautious of the fact that only the number of group memberships of the users increase. Please focus on the size of the Kerberos token.
Deploy Groups

5. Create Green Meadow

5.1. Creates a blank, completely authorized duplicate of the directories

In order to design the complete process as easy as possible, the authorizations are not written on the original path, but migRaven creates a blank copy of the directory tree with the new authorizations.

Via the point "Deploy ACL", a new, fully authorized, but blank duplicate of the directory tree is created. This is the new final storage location for your data.

In case of this step, only the directories, which have received explicit authorizations via migRaven, are re-created and authorized with the appropriate already available groups.

5.2. Preparation

A path must be prepared, which is the new data storage location after the replication of the data. This can be a complete new share or directory in an available share. When you set DFS, it recommends creating a new share, which must be linked to the DFS.

Only the directories are generated in the new path, which were processed before.

If source is \\ server \ share \ and is then below directories, then these are written under the new path: \\ server_new \ share \

For the new storage location, please fill in the predefined mandatory field.

Deploy ACL

There are two possible approaches for using the "Green Meadow":

  1. The "Green Meadow" includes the old data and functions as new storage location.
  2. The "Green Meadow" serves as a buffer and control storage location. After everything is controlled and found "OK, then the new ACLs are transferred to the old location.

6. Write new authorizations in the directories

In this step, the new directories are created and the rights are given.

6.1. Following steps are processed:

  • The directories are created, for which authorizations are provided.
  • Directories are provided for which list rights are only available for this folder.
  • Underlying directories are created according to our configuration with authorization groups. The groups have been created for the authorization end point, but only here.
  • In case of authorized directories, several authorization groups can be entered, one with read-execute-rights, one with read-write-rights and one with modify-rights. Authorization groups with full control rights should have exceptions.
  • These rights are transmitted to the secondary directories.
  • Secondary directories can get further authorization groups.

7. Result control

Control the newly generated authorization in the green meadow with the expectations

After successfully generating the "Green Meadow" through migRaven, the result should be verified. This is just possible when one generates a new project with the newly created directory tree.

Green meadow

In the "View" area of migRaven, the result can be viewed.

8. Replicate old data in the new directory tree

If the "Green Meadow" should be used as a new share, then the data must be replicated in the new area. This can not take place directly via migRaven.

Please control all new generated authorizations, whether they correspond with your expectations. Only after the replication of the data should be initiated. It is here importantthat the old authorizations are not taken along!

The replication can take place through various channels. Robocopy of Microsoft is offered with less amounts of data. If the directory includes lot of data, then we have had a good experience with peer sync. This is a tool that enables a clear real-time byte-level replication without the fact that the source and the target have always been compared. A further advantage of Peer Sync is the support for NetApp.

The command with Robocopy is:
Robocopy [Source] [Target] / E / Copy: DAT

If the "Green Meadow" should not become the new storage location, then the new ACLs can be transferred to the old area.

9. Exchange shares for user access

Original problem what it would mean to share a share in the same server. The target share, because we have given it an arbitrary name for the moment, like "Green Meadow". After the complete structuring of the target share with sub-directories, authorizations and data, the last step takes place. The source share gets now an arbitrary name and the target share gets the original name of the source share.

Permanent link to this post: https://help.migraven.com/en/instructions-migrating-file-system/