Promigra Server Migrator

Photo Credits:Marcin Wichary

When it comes to file copying you can choose from a wide variety of utilities. Rather than create another one we’ve decided that Promigra Server Migrator should use what already exists and has been proven to work. Promigra Server Migrator can work with most of the proven industry standard tools. It can be used with any tool that can be run from the command line and can accept appropriate parameters. Out of the box it generates scripts that make use of RoboCopy, ICACLS and PowerShell to migrate data.
Additionally, you can prepare templates that use some other utility to prepare scripts for Active Directory security group creation, creation of folders, and assignment of permissions and file copying.
To prepare a template for your favorite tool write a command that would execute the tool and perform some operation. Then replace parts of the command with place holders described below. During the script creation Promigra Server Migrator will pick the template and replace the placeholders with real values.
Example of a template:
icacls "[[TargetLocationPath]]" /grant "[[DomainName]]\[[SafeTargetLocationPath]]_R":(OI)(CI)(RX)
Placeholders that can be used with Promigra Server Migrator:
[[TargetLocationPath]]

This placeholder is used to mark the position where FSC should put the path to a folder in new folder structure. It is used in templates for creating new folders, copying data to new folders, etc.

[[SourceLocationPath]]

When Promigra Server Migrator creates scripts it replaces this placeholder with a path to a folder on an existing file share. It is used in templates for copying source data to new locations.

[[TargetLocationOwner]]

This place holder is used to mark where in the script FSC should put new folder owner’s user name.

[[ExcludedLocations]]

This term tells FSC where to put paths of source locations that must be excluded from the migration process.

[[ExcludedSublocation]]

This place holder will be replaced by one excluded sub location. It is used for creating a group of excluded source folders.

[[ParentContainer]]

With this place holder you can indicate where in the script FSC should put Active Directory container. It is used in templates for the creation of security groups in Active Directory.

[[DomainName]]

This term represents the target domain name.

[[SafeTargetLocationPath]]

Not all characters can be used to name Active Directory security groups. If you need a name of a target folder with the forbidden characters removed you can use this placeholder. FSC will take the target folder name and replace all forbidden characters with underscores. It is used in script templates for security group creation and in script templates for assigning permissions on target folders.

[[UserName]]

This placeholder is used in scripts that add individual users to Active Directory security groups. When creating a script FSC replaces this term with user’s user name.

Custom defined templates

In addition to the script templates provided with Promigra Server Migrator you can also use your own templates.
To replace a template that is included in FSC start a text editor and open the App.config file in the administration client. In this file you can find one line for each of the migration scripts. Find the template you would like to change and replace it with your version.
Whether you use the templates that are included with Promigra Server Migrator or your own, you have to test the resulting scripts in your own environment!

There are two FSC Client applications:

· User client: It allows end users to show where in the new folder structure they want to migrate their data. It is very simple to use. It gets deployed with ClickOnce technology. The Administrator sends users a link for starting the application.

· Administration client: This application is intended to be used by administrators. With this client administrators can create new projects, adjust project parameters and create migration scripts at the end of the project.

Promigra Server Migrator uses ClickOnce technology for user client deployment. This technology makes it possible to run a project without installing any additional software on client computers. Administrators can send users a link via e-mail, which they use to run the application.

Client deployment is possible from a shared folder or from a web server. Deployment from a shared folder is simpler, because there is no web server configuration necessary. One drawback is that ClickOnce does not allow adding parameters to a link for launching the client application. The result is that we can concurrently collect the data only for one project; however, this project can still contain multiple source servers and shared folders. This approach is more appropriate for various work group scenarios.

For larger projects it is better to use a web server to deploy user clients. The configuration is a little more complex, but allows us more options. With this approach the link for starting user client can contain parameters with project identification number and FSC server name. It makes it possible to concurrently reform many shared folders using the same FSC server. Like with the first approach we can also rebuild the structure of more than one file server.

Whether you use file shares or web servers to deploy the user client, all that a user needs to do is click on a link sent from a project leader.

Photo Credits:henning

Promigra Server Migrator is very flexible when it comes to folder security organization. Each folder or sub folder can have different security settings. But usually the simplest security systems are the best. The default setting in FSC is that security settings are defined only on the first level of user defined folders. All sub folders inherit security settings from the parent. At first this approach might look restrictive, but it often proves itself useful. For example, there could be problems when a child folder has different security settings than the parent folder. By changing the security settings on a parent folder an administrator can also reset the settings on child folders. That means that a child folder could have completely different permission settings than it should have. It can quickly happen that a user doesn’t have access to data that he should have. It can be even worse if somebody gets access to the data that he shouldn’t have! Important information can quickly leak.

That is the reason the FSC by default allows security settings only on one level.

Windows with NTFS permissions allows very detailed permission definitions, which can be granted to users or user groups. This flexibility is useful, but we rarely need that many options. Too many options can quickly become an obstacle. An inexperienced administrator, or a user, will be overwhelmed with that many options. The FSC enables folder owners to decide who has certain permissions to data by themselves. For this to be possible permission granting in FSC has to be as simple as possible. The folder owner has exactly two options: add a colleague to a group with read access, or add a colleague to a group with write access. If a person is in none of those groups he doesn’t have access to the data in that folder. Users in the write user group can create new folders and files, change them and also delete them. Users in the read only group can only read data in that folder. They cannot make any changes.

For each folder with defined security settings FSC creates two security groups, then puts users as members of those two groups. When permissions get granted on folders they are not granted to individual users, but rather to those two groups. This approach brings several benefits. First, security settings are much clearer. Namely, there are no mixed security settings for groups and different users. Another big advantage is that for granting or revoking permissions from users, the administrator does not need access to the file server. It is enough that the administrator has access to the Active Directory Users and Computers Console, where he can add or remove a user from the relevant group. This makes user provisioning in larger systems much easier.

Photo Credits:Syntopia

Initial structure of the new folder organization is very important. The reason you are thinking about rearranging your shared folders is likely because they are chaotic, the data is mixed up or saved to wrong places. You probably do not want to have the same problem in the new shared folder structure. There is no single right base structure. Construct the base folder structure in such way that your users feel comfortable using it, keeping in mind that not every user will be satisfied with the structure you select. The more users take part in the decision process the harder it is. Get together a small group of key users and decide on folders that will form the base for the new structure. Keep in mind that the new structure should make it easier to find the data, so be careful to not make the structure too complicated.

Pay the same amount of attention to rules for naming folders. When users start creating their folders they need simple and easy-to-use rules in place for folder naming. This is especially important in multilingual organizations. Sometimes it is very difficult to understand somebody that speaks your language, but with a foreign accent. Imagine that you are an administrator and a user asks you to change permissions on a folder. It is very important that you understand correctly what he wants. It is even more difficult when a user asks you to change permissions on a folder that is in foreign language. The folder name might even use characters you don’t have on your keyboard! In global organizations it might be easier if you have defined one language as the official corporate language. In that case, you can require that all folders that should have defined permissions must be written in that language. For folders deeper in the structure that inherit security settings from their parents you can allow users more freedom.

When Promigra Server Migrator prepares scripts for folder rearrangement it also creates scripts for building Active Directory security groups. It builds security group names from actual folder names. As you can use characters in folder names that are not allowed in Active Directory it has to replace those characters with underscores. The administrator’s life will be much easier if you try to have AD security group names and folder names as close as possible. Keep that in mind when you prepare folder naming standards.

However you decide your standards to be, keep them as simple as possible.