«

»

Project typ “Scan Resources”

1. For each Share a new project

1.1. Reading directories and permissions

In migRaven one always works with a project. This is the logical unit, which is to be processed. This can, for example, be a share or a directory below a share. In ideal cases it is the point, which is also mounted by the users or is connected in the DFS. Thereby it is ensured, that all permissions – including the list permissions – are correctly created by migRaven.

1.2. Best Practice: for each Share a new project is placed

When you define the individual shares as standalone projects, then you have time to process this in peace and “Step by Step” to copy the data in the new directories and then provide these to the users.

2. The Tabs

2.1. Project name and –mode

Mode

Project Name

Here a clear project name is to be entered. Give the project a name, which tells you something, for example “book keeping” or “purchase”. Every project must have a different name.

Chose: Standard Mode or Project Mode

The permission groups are created in the standard mode.

If you click on “Prepare for immediate use in 8MAN…”, the permission group receives additional attributes, which 8MAN requires for his work. And in the directories.id.8MAN-files are placed for 8MAN.

If migRaven is to be used together with 8MAN, then special settings are to be noted:

  • The naming must be identical with 8MAN
  • The OU, in which migRaven creates new groups, must be identical with that in 8MAN. Thereby it should be noted, that the OU, which is automatically generated by migRaven, needs to be entered in 8MAN together with the server name.
  • For this purpose please also read our Operation Instructions: How do migRaven and 8MAN work together

In the project mode no additional or new permission groups are placed. migRaven then reuses the existing permission groups.

 

2.2. Data – Source- and Target Path

Target:  DFS or single server

You can choose between the migration on an single server or in a DFS.

Source path, target- and deploy-path

Here the source and target is given.

The path is given in the UNC-format. Thereby at least a server and share is to be provided. Below that the directory-name is given.

General Form:

\\Server\Share    or   \\Server\Share\index1\…

Project1: “\\Server\data\administration\bookkeeping”

Projekt2: “\\Server\data\administration\purchase”

The share “data” is the level 0, the directory “administration” the level1, etc. This is particularly important in the configuration of the list groups.

Example:

Source path:        „\\Server\Data\Administration\Finance“

Target path:          „\\Server\Data\Administration\bookkeeping“

Please note, that migRaven will neither read permissions directly from the source path nor write them directly on the target path. In our example, the permissions of the directories “Data”, “Administration”, and “Finance” will be ignored. If permissions for the target path (e.g. “bookkeeping”) are needed, you have to set them manually. Only directories located below the source path (e.g. “finance”) will be scanned and permissions will be set on the target path only below “bookkeeping”.

Why two paths for the target:  Target- und Deploy-Path?

The target-path is the final name of the target-path, which can also be the source –path name.  As one should not write in the source and there cannot be two Shares with the same names, we added the Deploy-path. In this the permission structure is written by migRaven. Then the data can be copied. First then the Share-name of the source-path is changed into an alternate optional name and the deploy-path receives this Share-name. And the time the user registrates on his desktop he receives the new structure under the old name.

Even if in the start of the program for both the same name is given, then during the writing of a new directory structure, in deploy ACL, a deviating deploy-path can be given. The deploy-path should never be the same as the source-path.

Target-Path

This is the name, which our migrated Share should finally receive.
This name can correspond to the starting path– this is the most frequent case. It can also contain another name, if the final Share-name should not correspond to the starting path.

Why is this name important?

  • The directory name and the share name are used for the naming of the permission groups, if you have selected that recommended option in the group configuration. Thus you can easily recognize the domain of the permission groups.
  • 8MAN works with the groups-description field. In the field of description for every permission group there is the complete path with server, release and directories. In the adapted configuration migRaven creates 8MAN-compatible groups.

Deploy-Path

If the target path corresponds to the starting path, and you would also want to maintain the Share-name, then you must specify another deploy-path in the function “Deploy ACL”, with this you do not write the new permission structure in you starting directory. The name of this alternative target path does not matter; it could be the same as in the starting directory, but you can also give it the name “Green Meadows”.  After successful migration and copying of the data you can rename the starting -Share and the target path (“Green Meadows”) can be adopt its name.

It should be noted that

  • the given path will be checked on its existence before scanning.
  • Corresponding to your Windows account´s permissions, migRaven can scan only the directories on which you have access.
  • On the deploy path and the OU for the permission groups you must have the write permission, therefore you must execute the program always as an administrator.

Scan Depth

The scan depth is pre-set on 5 levels under the Share. You can change this value, if you would like to read the explicit permissions lying below. You should select the scan depth as deep as you want to read and set the permissions in the folders. The deeper a scan is targeted, the longer the scan takes and the larger the database grows. Below the given scan depth neither the directories nor the permissions are read.

Data Server

Scanning of an single server

 

Data DFS

Scanning of a DFS

2.3. Optional: Group Type and AD-OU

This data has been already determined in the configuration. However it can be exclusively changed for this project. Here you can modify the AD-OU, in which the permission groups are to be placed. It is then definitely meaningful, if you have the data-owner, who allocates the permissions in his region and then the same should also be written only in your OU.

Type

2.4. Optional: Structure of the Group Name

Even these details were already established in the configuration. You can change it here for this project. You can change the structure of the name for the permission groups, the ingredient parts and their sequence.

Name

2.5. Optional: List Permissions

Here, deviating from the configuration, you can determine, whether the list groups should be placed and in which levels.

List permissions

2.6. Summary and Start

On the last tab the selected parameters are summarized and displayed.

Threads for Scan

Before the start you can determine, as to how many threads migRaven should use. This depends on the number of CPU cores of your computer. We recommend 4 threads per Core. The more threads you select, the higher is the processor load through the Java-process.

Number of Files and Sizes to be collected

If you select this function, migRaven counts also the number of directories and files and their sizes. In the view and in the project statistics you can display of the results that are calculated. In large Shares this function however costs additional time.

Start Reading

After we have filled in the fields, we can start the project.

The directories and permissions of the specified source directory are read and placed in the migRaven database.

Summery

After the scan, the program automatically switches to the View mode, visualizing the structure that was read.