Migrate Tectia® SSH for Windows Users and Data

This article explains how to use CopyRight2 to migrate Tectia SSH for Windows® including user accounts along with their passwords, their Windows® user profiles, groups, group memberships and data including permissions. Tectia®, originally named SSH Communications Security, was founded by SSH's inventor and Finland native Tatu Ylönen, in response to a password-sniffing attack at his university.

Table of Contents:

1. Overview
2. Before the Migration
3. Migration of User and Group Accounts
4. Migration of Windows User Profiles
5. Data Migration
6. Pre-Copy Phase
7. Final-Copy Phase /  Cutover
8. After the Migration
9. Conclusion

Overview

The Tectia® SSH service allows users to logon remotely using a SSH client. It supports authentication with a Windows® account and its password. Users can logon with a local user account or a domain account. Access to data is controlled by NTFS permissions set on files and folders. To migrate between two Windows® systems running the Tectia® SSH service, a migration of users, groups and data is required. Additionally you may also want to migrate the user profiles just like you would with a RDP application server to migrate the user environments to the target server.

This task can be accomplished by using a single or multiple separate jobs. In this article we describe how to perform the migration in three separate steps, first the users and groups, then the user profiles and finally the data including permissions. Besides of splitting the task into three jobs, you could use two jobs, combining the profile and data migration or a single Data Migration job combining all three if you configure the Data Migration job to automatically migrate any accounts found in NTFS or share level permissions.

This article assumes that the source and target servers are running as domain members in the same domain. CopyRight2 supports migrations from or to workgroup mode configured systems and members in different domains as well. The three defined jobs will be run initially, as a pre-copy to reduce downtime during the final-copy phase. The source server is a Windows® 2016 server and the target a Windows® 2019 server. Both are a member of the same domain and have the Tectia® SSH service installed. Besides of the users and groups and the user profiles, there is a Data folder containing group shares for the Accounting, Marketing and Sales departments.

CopyRight2 was previously installed on the source server and the data is pushed to the target server (push configuration). It is of course also possible to install it on the target server (pull configuration).

Before the Migration

Before the migration users can remotely logon with a SSH client by providing their local or domain user account along with their password. There is a DNS record "ssh.domaine.com" defined that points to the source server.

Source SSH Logon

You can see that the user got logged on successfully and is initially located in the corresponding user profile folder.

Migration of User and Group Accounts

In a first step the local user and group accounts are migrated by defining and running a User and Group Migration job.

There are three local groups and ten local user accounts on the source server as you can see below.

Local User Accounts on Source

To migrate the user accounts a new User and Group Migration job is defined with the name "User and Group Migration":

User and Group Migration - Name and Description

We provide the source and target servers name in the Source and Destination page:

User and Group Migration - Source and Target Servers

Next the local users and groups that should be migrated are selected:

User and Group Migration - Account Selection

Now we configure the filter defining which type of objects should get migrated and how to treat objects that already exist on the target. We set users to Add/Update/Remove to add objects that do not yet exist, update existing accounts and remove accounts that were migrated previously but do not exist on the source anymore:

User and Group Migration - Account Filter

Finally we complete the job definition by configuring the settings to migrate users including passwords and their group memberships:

User and Group Migration - Settings

After defining the User and Group Migration job's settings, we can run it:

Running the User and Group Migration Job

After running the job, we can see that the users and groups have been created on the target system:

Local User Accounts on Target

Migration of Windows User Profiles

The second step is the migration of user profiles. We can see that there are Windows user profiles for local and domain accounts in the source server's "c:\users" folder:

Windows User Profiles on Source Server

We define a Data Migration job to migrate these Windows profiles to the target server:

User Profile Migration - Name and Description

Next we go to the Source and Destination page and click on the Add button to add the source and target folders to the job:

User Profile Migration - Adding Source and Target Folders

After adding the folders we change the Synchronization option to Add/Update/Delete in order to let the job perform a synchronization if running the same job again at a later time:

User Profile Migration - Source and Target Folders

In the ACL and Owner Permissions page we enable the "Assign security identifiers of groups and users on the source computer automatically to identically named groups and users on the destination computer" option. Otherwise CopyRight2 would ask for a confirmation before making any permission replacement. This option would not be needed if the Data Migration job would perform the user and group migration, but in this scenario we opted for the definition of a separate User and Group Migration job:

User Profile Migration - ACL and Owner Permissions

To migrate the user profiles, for example the NTUser.Dat file of each user, mounted as HKEY_CURRENT_USER during Windows logon we need to enable the "Reacl NTUser.Dat registry permissions". This will ensure that the migrated accounts can access their profiles and prevent Windows from creating a new profile during logon:

User Profile Migration - User Environment

Finally we enable the "Ignore errors resulting from locked files" option in the Error Processing page to not treat locked files as errors. This is needed during the pre-copy phase, where users are still working and may have files locked. For the final-copy, run before the cut-over takes place, this option needs to be disabled:

User Profile Migration - Error Processing

Data Migration

The third and final step is the migration of data including NTFS permissions and file shares including permissions. Just like all CopyRight2 jobs, we begin the definition of the job by providing a job name:

Data Migration - Name and Description

Next we provide the source and target folders. In this case the content of the source server's "E\Data" folder should be migrated to the target server's "E:\Data" folder. This is how it should look like after adding the source and destination pair to the job:

Data Migration - Source and Destination

Identical to the previously defined job to migrate the Windows user profiles, we enable the "Assign security identifiers of groups and users on the source computer automatically to identically named groups and users on the destination computer" option. This will prevent CopyRight2 from asking for confirmation before replacing source with target accounts in share and NTFS permissions:

Data Migration - ACL and Owner Permissions

Next we enable the migration of file shares to automatically migrate the department shares located below the specified "E:\Data" folder. We select Add/Update to update the file share permissions every time the job is executed:

Data Migration - File Shares

Finally we enable the "Ignore errors resulting from locked file" option in the Error Processing page, to let the program skip locked files without producing an error during the pre-copy phase. Just like the previously defined job to migrate the user profiles, this option needs to be disabled during the final-copy phase before the cut-over:

Data Migration - Error Processing

Pre-Copy Phase

During the pre-copy phase, before users start working with the target system, you can run the jobs as many times as you deem necessary to update the migrated accounts, data and permissions. It is important that you execute all three jobs in the following order:

1. The User and Group Migration job, to migrate users and groups so they can be used in permissions.
2. The Profile Migration job, to migrate the local and domain Windows profiles.
3. The Data Migration job, to copy the actual data including permissions.

During that phase and with the "Ignore errors resulting from locked files" option enabled, any locked files will be skipped. You can see in the job's log file how many and which files were skipped because they were locked.

Final-Copy Phase / Cutover

During the final-copy phase you will need to disable the "Ignore errors resulting from locked files" option to ensure all data is migrated. It is important that users do not make any changes to the data during this period. In order to keep this period as short as possible, the data was already copied to the target in the pre-copy phase. CopyRight2's real-time synchronization could be used to further shorten this period.

Then all three jobs are executed for the last time before the cutover takes place:

1. The User and Group Migration job, to migrate users and groups so they can be used in permissions.
2. The Profile Migration job, to migrate the local and domain Windows profiles.
3. The Data Migration job, to copy the actual data including permissions.

After the final-copy phase has been completed without any errors you may want to either move the IP address over to the target system or make corresponding changes in DNS to ensure that users attempting to connect will reach the target instead of the source server.

After the Migration

After the migration has been performed users will not notice that the underlying server has been migrated and they can logon using their known passwords. For example with one of the local user account:

Destination SSH Logon - Local User Account

Or with a domain user account:

Destination SSH Logon - Domain User Account

Conclusion

After reading this article you should now have a better understanding of how to migrate a Tectia SSH Server for Windows including users, their passwords, groups, group memberships, user profiles, data, NTFS permissions, shares and share level permissions.

If you should have any feedback, positive or negative or some follow-up questions, please let us know in the comments below. Thank you.