Project type "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 therefore mounted in the DFS. Thereby it is ensured 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

Fashion

Project Name

Here is 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 will receive additional attributes, which includes 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 Create 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 read our Operation Instructions: How to 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 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 one 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"

Project2: "\\ server \ data \ administration \ purchase"

The share "data" is the level 0, the directory "administration" the level1, etc. This is especially 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 In our example, the permissions of the directories "Data", "Administration", and "Finance" will be ignored. If permissions for the target path (eg "bookkeeping") are needed, you have to set them manually. Only directories located below the source path (eg, "finance") want to be scanned and approved.

Why two paths for the target: Target and Deploy Path?

The target-path is the final name of the target-path, which can therefore be the source -path name. As one should not write in the source and there can not 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 alternate-optional-name and the deploy-path receives this share-name. And the time the user registers on his desktop he receives the new structure under the old name.

Even if in the start of the program for 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 should be received.
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. Thus you can easily identify the domain of the permission groups.
  • 8MAN works with the groups-description field. There is the complete path with servers, release and directories. In the adapted configuration migRaven creates 8MAN-compatible groups.

Deploy Path

If the target path to the path, and you would like to specify another deploy-path in the function "Deploy ACL", with this you will 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 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 wants to be checked.
  • 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. You should choose 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 the directories or the permissions are read.

Data Server

Scanning of a single server

Data DFS

Scanning of a DFS

2.3. Optional: Group Type and AD-OU

This data has already been determined in the configuration. However it can only be changed for this project. Here you can modify the AD-OU in which the permission groups are placed. It is then definitely meaningful, if you have the data-owner, who allocates the permissions in your region and then the same should be written 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 of the permission group, the ingredient parts and their sequence.

Name

2.5. optional: List Permissions

Here, deviating from the configuration, you can determine whether or not the list should be placed in which level.

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 how many 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 the processor load through the Java process.

Number of Files and Sizes to be collected

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

Start Reading

After we have filled 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.

Permanent link to this post: https://help.migraven.com/en/migrating-by-scan-add-project/