List of automated migration activities - AWS CloudEndure Migration Factory Solution

List of automated migration activities

The AWS CloudEndure Migration Factory Solution deploys automated migration activities that you can leverage for your migration projects. You can follow the migration activities listed below and customize them based on your business needs.

Before starting any of the activities, verify that you are logged on to your migration execution server as a domain user with local administrator permission on the in-scope source servers.

Note

All the activities listed in this appendix require you to be logged in as an administrator.

Use the following procedures, in order, to conduct a complete test run of the solution using the sample automation script and activities.

Import the application and server data

To start the migration process, navigate to the 0-Migration-intake-form.csv file located in the c:\migrations\scripts folder. This file is used as the migration intake form to import the attributes for the in-scope source servers.

Note

The .csv file and the sample automation scripts were part of the package you unzipped in Step 3.

You can customize this form for your migration, by replacing the sample data with your specific server and application data. The following table depicts the data you need to replace to customize this solution for your migration needs.

Field Name Required? Description
wave_id Yes

The wave number which is based on priority and application server dependencies. Obtain this identifier from your migration plan.

app_name Yes

The names of the applications that are in-scope for migration. Confirm that your application grouping includes all the applications sharing the same servers.

cloudendure_projectname Yes

The project name(s) you created in CloudEndure containing the AWS account destination for the migration.

aws_accountid Yes

A 12-digit identifier for your AWS account located in your account profile. To access, select your account profile from the upper-right corner of the AWS Management Console and select My Account from the dialog menu.

server_name Yes The name of the on-premises servers that are in-scope for migration.
server_os Yes The operating system (OS) that is running on the in-scope source servers. Use either windows or linux since this solution supports only these operating systems.
server_os_version Yes The version of the OS running on the in-scope source servers.
Note

Use the OS version, not the Kernel version, for example, use RHEL 7.1, Window Server 2012 R2, or CentOS 7.5, 7.6. Do not use Linux 3.xx, 4.xx, or Windows 8.1.x.

server_fqdn Yes The source server’s fully qualified domain name, which is the server name followed by the domain name. For example, server123.company.com.
server_tier Yes A label to identify whether the source server is a web, app, or a database server. We recommend designating the source server as app if the server functions as more than one tier, for example, if the server runs web, app, and database tiers together.
server_environment Yes A label to identify the server’s environment. For example, dev, test, prod, QA, or pre-prod.
subnet_IDs Yes The subnet ID for the target Amazon EC2 instance for the migration post-cutover.
securitygroup_IDs Yes The security group ID for the target Amazon EC2 instance for the migration post-cutover.
subnet_IDs_test Yes The target subnet ID for the source server that will be tested.
securitygroup_IDs_test Yes The target security group ID for the source server that will be tested.
instanceType Yes The Amazon EC2 instance type identified in the discovery and planning effort. For information about EC2 instance types, refer to Amazon EC2 Instance Types.
tenancy Yes The tenancy type, which is identified during the discovery and planning efforts. Use one of the following values to identify the tenancy: Shared, Dedicated, or Dedicated Host. You can use Shared as the default value unless an application’s license requires a specified type.
  1. Signed in as an administrator, open a command prompt (CMD.exe).

  2. Navigate to the c:\migrations\scripts folder and run the following Python command.

    python 0-Import-intake-form.py --Intakeform "<file-path>"
  3. Replace <file-path> with the correct intake form location, for example, c:\migrations\scripts\0-Migration-intake-form.csv.

  4. Sign in to the solution with your username and password.

    
                        Migration factory login

    Figure 35: Migration factory login

    The script loads the CSV data and then creates the waves in the solution.

    
                        Migration factory creating the waves

    Figure 36: Migration factory creating the waves

    After the waves are created, the script automatically creates the applications and servers based on the information from the CSV file.

    
                        Migration factory creating the applications and servers

    Figure 37: Migration factory creating the applications and servers

Check the prerequisites

Connect with the in-scope source servers to verify the necessary prerequisites such as TCP 1500, TCP 443, root volume free space, .Net framework version, and other parameters. These prerequisites are required for CloudEndure replication.

Before you can conduct the check, the CloudEndure agent must be installed manually on one source server. After installation, CloudEndure creates the CloudEndure replication server in Amazon Elastic Compute Cloud (Amazon EC2). You will need to verify the TCP port 1500 from the source server to the CloudEndure replication server in this activity. For information about installing the CloudEndure agent in your source servers, refer to Install the CloudEndure Agents manually.


                Search for CloudEndure replication server in Amazon EC2

Figure 38: Search for CloudEndure replication server in Amazon EC2

Use the following procedure while signed in to the migration execution server to check for the CloudEndure prerequisites.

  1. Signed in as an administrator, open a command prompt (CMD.exe).

  2. Navigate to the c:\migrations\scripts folder and run the following Python command.

    python 0-Prerequisites-checks.py --Waveid <wave-id> --CEServerIP <ces-server-ip>

    Replace <wave-id> and <ces-server-ip> with the appropriate values:

    • The Waveid is a unique integer value to identify your migration waves.

    • The CEServerIP value identifies the CloudEndure replication server IP address. Change this value to the Amazon EC2 IP address. To locate this address, sign in to the AWS Management Console, search for CloudEndure Replication, select one of the replication servers, and copy the private IP address. If the replication occurs over the public internet, use the public IP address instead.

  3. Sign in to the solution with your username and password.

    
                        Migration factory login

    Figure 39: Migration factory login

    The script automatically retrieves a server list for the specified wave and CloudEndure projects.

    
                        Retrieve a server list for the specified wave

    Figure 40: Retrieve a server list for the specified wave

    The script then checks the prerequisites for Windows servers and returns a state of either pass or fail for each check.

    
                        Windows servers prerequisite checks

    Figure 41: Windows servers prerequisite checks

    Next, the script checks the Linux servers.

    
                        Linux servers prerequisite checks

    Figure 42: Linux servers prerequisite checks

    Once the checks are completed, the script will return a final result for each server.

    
                        Windows servers prerequisite check results

    Figure 43: Windows servers prerequisite check results

    
                        Linux servers prerequisite check results

    Figure 44: Linux servers prerequisite check results

If the server failed one or more prerequisites checks, you can identify the faulty server by either reviewing the detailed error message provided at the completion of the check or by scrolling through the log details.

The script will also update the solution’s migration_status in the Migration Factory web interface. Use the following procedure to check the status details.

  1. Log in to the Migration Factory web interface and select Resource List from the drop-down menu on the upper-right corner of the page.

    
                        Migration Factory menu options

    Figure 45: Migration Factory menu options

  2. Choose the Server List tab and enter the wave name in the search field. In the following screenshot of an example project, we searched for Wave 1.

    
                        Search for a server in the Server List tab

    Figure 46: Search for a server in the Server List tab

    A list of source servers targeted in Wave 1 displays on the page.

  3. Choose the settings icon on the upper-right corner of the page.

    
                        Settings icon

    Figure 47: Settings icon

  4. In the Show/Hide Columns dialog box, scroll down the Server Attributes options, and select migration_status.

    
                        Select migration_status from Server Attributes options

    Figure 48: Select migration_status from Server Attributes options

  5. Choose Update View. The migration_status column will display.

When the check is successful, the migration_status will show Pre-requisites check : Passed as shown in the following screenshot of an example project.


                        Prerequisites check results

Figure 49: Prerequisites check results

Install the CloudEndure agents

Use the following procedure to automatically install the CloudEndure agents in the in-scope source servers.

  1. In the migration execution server, signed is as an administrator, open a command prompt (CMD.exe).

  2. Navigate to the c:\migrations\scripts folder and run the following Python command.

    python 1-CEAgentInstall.py --Waveid <wave-id>

    Replace <wave-id> with the appropriate Wave ID value to install the CloudEndure agent on all servers in the identified wave. The script will install the agent on all source servers in the same wave one by one.

  3. Log in to the solution with your username and password.

    
                        Migration factory login

    Figure 50: Migration factory login

  4. Enter the CloudEndure API token.

    Note

    To find your CloudEndure API token, navigate to the CloudEndure console, choose Setup & info, choose Other Settings, then choose API Token. If the token does not exist, select Generate token.

    
                        Migration factory CloudEndure API token prompt

    Figure 51: Migration factory CloudEndure API token prompt

The script generates a list identifying the source servers included for the specified wave. In addition, servers that are identified in multiple projects and for different OS versions may also be provided.


                Migration factory server list

Figure 52: Migration factory server list

If there are Linux machines included in this wave, you must enter your Linux sudo username and password to log in to those source servers.


                Migration factory Linux login

Figure 53: Migration factory Linux login

The installation starts on the Windows machines, then proceeds to the Linux machines for each project.


                Install CloudEndure agents

Figure 54: Install CloudEndure agents

Results are displayed after the script finishes installing the CloudEndure agents. Review the results for error messages to identify servers that failed to install the agents. You will need to manually install CloudEndure agents on the failed servers. If manual installation does not succeed, go to the AWS support center and log a CloudEndure case.


                Check CloudEndure agent install results

Figure 55: Check CloudEndure agent install results

The script also provides the migration_status in the Migration Factory web interface as shown in the following screenshot of an example project.


                Migration factory web interface showing migration_status

Figure 56: Migration factory web interface showing migration_status

Push the post-launch scripts

CloudEndure supports post-launch scripts to help you automate OS-level activities such as the install/uninstall of software after launching target instances. This activity pushes the post-launch scripts to Windows and/or Linux machines, depending on the servers identified for migration.

Push the post-launch scripts for Windows

Use the following procedure from the migration execution server to push the post-launch scripts to Windows machines.

  1. Signed in as an administrator, open a command prompt (CMD.exe).

  2. Navigate to the c:\migrations\scripts folder and run the following Python command.

    python 1-FileCopy-Windows.py --Waveid <wave-id> --Source <file-path>

    Replace <wave-id> with the appropriate Wave ID value and <file-path> with the full file path for Source, where the script is located. For example, c:\migrations\scripts. This command copies all files from the source folder to the destination folder.

  3. Log in to the solution with your username and password.

    
                            Migration factory login

    Figure 57: Migration factory login

The script copies the files to the destination folder. If the destination folder does not exist, the solution creates a directory and notifies you of this action. In the following screenshot of an example project, the solution created a directory labeled post_launch.


                    Copy files to post_launch folder

Figure 58: Copy files to post_launch folder

Push the post-launch scripts for Linux

Use the following procedure from the migration execution server to push the post-launch scripts to Linux machines.

  1. Signed in as an administrator, open a command prompt (CMD.exe).

  2. Navigate to the c:\migrations\scripts folder and run the following Python command.

    python 1-FileCopy-Linux.py --Waveid <wave-id> --Source <file-path>

    Replace <wave-id> with the appropriate Wave ID value and <file-path> with the full file path for Source, where the script is located. For example, c:\migrations\scripts. This command copies all files from the source folder to the destination folder.

  3. Log in to the solution with your username and password.

    
                            Migration factory login

    Figure 59: Migration factory login

  4. Enter your Linux sudo username and password to copy the files to the in-scope source servers.

    
                            Migration factory Linux login

    Figure 60: Migration factory Linux login

You will receive the following message if the files were successfully copied to the source servers.


                    Successful copy files to post_launch folder message

Figure 61: Successful copy files to post_launch folder message

Verify the CloudEndure replication status

This activity verifies the replication status for the in-scope source servers automatically. The script repeats every five minutes until the status of all source servers in the given wave changes to a continuous data replication status.

Use the following procedure from the migration execution server to verify the CloudEndure replication status.

  1. Signed in as an administrator, open a command prompt (CMD.exe).

  2. Navigate to the c:\migrations\scripts folder and run the following Python command.

    python 2-Verify-replication.py --Waveid <wave-id>

    Replace <wave-id> with the appropriate Wave ID value to verify the replication status. The script verifies the replication details for the CloudEndure projects and updates the replication_status attribute for the source server identified in the solution.

  3. Log in to the solution with your username and password.

    
                        Migration factory login

    Figure 62: Migration factory login

  4. Enter the CloudEndure API token.

    Note

    To find your CloudEndure API token, navigate to the CloudEndure console, choose Setup & info, choose Other Settings, then choose API Token. If the token does not exist, select Generate token.

    
                        Migration factory CloudEndure API token prompt

    Figure 63: Migration factory CloudEndure API token prompt

The script generates a list identifying the servers included for the specified wave.


                Migration factory server list

Figure 64: Migration factory server list

The expected status for the in-scope source servers that is ready to launch is Continuous Data Replication. If you see a different status for a server, then it is not ready for launch yet. Other server status include:

  • Initial sync in progress: the server has not finish initial replication

  • Booting_replication_server: the initial sync has not started

The following screenshot of an example project shows that all servers in the current wave have finished replication and are ready for testing or cutover.


                Replication status for servers

Figure 65: Replication status for servers

Optionally, you can verify status in the Migration Factory web interface.

  1. Log in to the Migration Factory web interface and select Resource List from the drop-down menu on the upper-right corner of the page.

    
                        Migration Factory menu options

    Figure 66: Migration Factory menu options

  2. Choose the Server List tab and enter the wave name in the search field.

    
                        Search for a server in the Server List tab

    Figure 67: Search for a server in the Server List tab

  3. Choose the settings icon on the upper-right corner of the page.

    
                        Settings icon

    Figure 68: Settings icon

  4. In the Show/Hide Columns dialog box, scroll down the Server Attributes options and select replication_status.

    
                        Select replication_status from Server Attributes options

    Figure 69: Select replication_status from Server Attributes options

  5. Choose Update View. The replication_status column displays.

Create the admin user

Create the local admin user for a Windows environment

This activity creates a local admin user on Windows machines. This user may be needed to troubleshoot issues that may occur after migration cutover from the in-scope source servers to AWS. The migration team will use this user to log in to the target server when the authentication server (for example, the DC or LDAP server) is not reachable.

Note

This activity is not required if you have a local admin user and log in credentials for all source servers.

Use the following procedure to create a local admin user.

  1. Use a remote desktop protocol (RDP) client to log in to the migration execution server with domain credentials. This user needs admin permissions to all source Windows machines.

  2. Signed in as an administrator, open a command prompt (CMD.exe).

  3. Navigate to the c:\migrations\scripts folder and run the following Python command to create a local user and add the user to the local administrator group.

    python 2-UserMgmt-Windows.py --Waveid <wave-id>

    Replace <wave-id> with the appropriate Wave ID value to create a local admin user for all the Windows servers in that wave.

  4. Select option 1 to create a user.

    
                            Create a local admin user

    Figure 70: Create a local admin user

  5. Log in to the solution with your username and password.

    
                            Migration factory login

    Figure 71: Migration factory login

  6. Enter a new local admin username and password. A local admin user for all source Windows servers in the specified wave is created.

    
                            Local admin user for Windows servers

    Figure 72: Local admin user for Windows servers

    Note

    The migration team will use this user to log in to the target server when the authentication server (for example, the DC or LDAP server) is not reachable, for troubleshooting purposes.

You will receive the following message when the user is successfully created.


                    Local admin user created confirmation message

Figure 73: Local admin user created confirmation message

Create a local sudo user for a Linux environment

This activity creates a local sudo user on Linux machines. This user role may be needed to troubleshoot issues that may occur after migration cutover from the in-scope source servers to AWS. The migration team will use this role to log in to the target server when the authentication server (for example, the DC or LDAP server) is not reachable.

Note

This activity is not required if you have a sudo user and log in credentials for all source servers.

Use the following procedure to create a local sudo user.

  1. Use a remote desktop protocol (RDP) client to log in to the migration execution server with domain credentials.

  2. Signed in as an administrator, open a command prompt (CMD.exe).

  3. Navigate to the c:\migrations\scripts folder and run the following Python command to create a local sudo user and add the user to the local administrator group.

    python 2-UserMgmt-Linux.py --Waveid <wave-id>

    Replace <wave-id> with the appropriate Wave ID value to create a local sudo user for all the Linux servers in that wave.

  4. Select option 1 to create a user.

    
                            Create a local sudo user

    Figure 74: Create a local sudo user

  5. Log in to the solution with your username and password.

    
                            Migration factory login

    Figure 75: Migration factory login

  6. Enter a new Linux sudo username and password. A local sudo user for all source Linux servers in the specified wave is created.

    
                            Local sudo user for Linux servers

    Figure 76: Local sudo user for Linux servers

You will receive the following message when the user role is successfully created.


                    Local sudo user created confirmation message

Figure 77: Local sudo user created confirmation message

Launch instances for testing or cutover

This activity launches all target machines for a given wave in CloudEndure either in test mode or cutover mode.

Use the following procedure to launch instances for either testing or cutover.

  1. Log in to the Migration Factory web interface.

  2. Select Tools from the drop-down menu on the upper-right corner of the page.

    
                        Migration Factory menu options

    Figure 78: Migration Factory menu options

  3. Choose the CloudEndure tab.

  4. On the CloudEndure Launch configuration page, take the following actions:

    • In the CloudEndure API Token field, enter your CloudEndure API token.

      Note

      To find your CloudEndure API token, navigate to the CloudEndure console, choose Setup & info, choose Other Settings, then choose API Token. If the token does not exist, select Generate token.

    • For Dry run, select the drop-down arrow and select yes.

    • For Launch Type, select the drop-down arrow and select test.

      Note

      To launch the servers in cutover mode, select cutover.

    • Select Launch Servers to validate the CloudEndure blueprint.

      
                            CloudEndure launch configuration page

      Figure 79: CloudEndure launch configuration page

      When validation is successful, you will receive the following message: Dry run was successful for all machines.

      Note

      If validation is not successful, you will receive the following error message:

      ERROR: Updating blueprint failed for machine: <your-server-name>, invalid blueprint config.

      The errors may be due to invalid data in the server attribute such as an invalid subnet_IDs, securitygroup_IDs, or instanceType.

      You can switch to the Pipeline page from the Migration Factory web interface and select the problematic server to fix the errors.

  5. On the CloudEndure Launch configuration page, in the Dry run field, select the drop-down arrow and select no.

  6. Choose Launch Servers to create a job in CloudEndure.

When the servers are successfully launched in CloudEndure, you will receive a confirmation message: Test Job created for <machine-names> or Cutover Job created for <machine-names>, depending on your launch type.

If there are more than one CloudEndure project in the specified wave, repeat the steps for each CloudEndure project. The CloudEndure job and boot up process takes approximately 30 minutes to an hour to finish.

Verify the target instance status

This activity verifies the status of the target instance by checking the boot up process for all in-scope source servers in the same CloudEndure project. It may take up to 30 minutes for the target instances to boot up. You can check the status manually by logging into the Amazon EC2 console, searching for the source server name, and checking the status. You will see a health check message stating 2/2 checks passed, which indicates that the instance is healthy from an infrastructure perspective.

However, for a large-scale migration, it’s time-consuming to check the status of each instance, so you can run this automated script to verify the 2/2 checks passed status for all source servers in a given wave.

Use the following procedure from the migration execution server to verify the status of the target instance.

  1. Signed in as an administrator, open a command prompt (CMD.exe).

  2. Navigate to the c:\migrations\scripts folder and run the following Python command.

    python 3-Verify-instance-status.py --Waveid <wave-id> --CloudEndureProjectName <project-name>

    Replace <wave-id> with the appropriate Wave ID value and <project-name> with the CloudEndure project name to verify instance status. This script verifies the instance boot up process for all source servers in a CloudEndure project. If there are more than one CloudEndure project in a wave, you can run this script for each project.

  3. Log in to the solution with your username and password.

    
                        Migration factory login

    Figure 80: Migration factory login

  4. Enter the CloudEndure API token.

    Note

    To find your CloudEndure API token, navigate to the CloudEndure console, choose Setup & info, choose Other Settings, then choose API Token. If the token does not exist, select Generate token.

    
                        Migration factory CloudEndure API token prompt

    Figure 81: Migration factory CloudEndure API token prompt

    The script returns a listing of the server list and Instance IDs for the specified wave.

    
                        Migration factory server list

    Figure 82: Migration factory server list

  5. Enter the AWS access key and secret access key.

    Note

    Your AWS access key will need to have Amazon EC2 read only permission in the target AWS account.

You will receive instance status checks that indicates whether your target instances passed the 2/2 health checks.

Note

If your target instances fail the 2/2 health checks the first time, it may be due to the boot up process taking longer to complete. We recommend running the health checks a second time about an hour after the first health check. This ensures that the boot up process completes. If the health checks fail this second time, go to the AWS support center to log a CloudEndure case.


                    Instance status check results showing failed checks

Figure 83: Instance status check results showing failed checks


                    Instance status check results showing passed checks

Figure 84: Instance status check results showing passed checks

Terminate the test instances

This activity terminates all the test instances in a given wave. After testing, you can manually terminate the instances from the Amazon EC2 console to avoid charges. However, it is more efficient to terminate all instances by using the single automation script.

Use the following procedure from the migration execution server to terminate the test instances.

  1. Signed in as an administrator, open a command prompt (CMD.exe).

  2. Navigate to the c:\migrations\scripts folder and run the following Python command.

    python 3-Terminate-test-instance.py --Waveid <wave-id>

    Replace <wave-id> with the appropriate Wave ID value to terminate the test instances. The script terminates the test instances for all CloudEndure projects.

  3. Log in to the solution with your username and password.

    
                        Migration factory login

    Figure 85: Migration factory login

  4. Enter the CloudEndure API token.

    Note

    To find your CloudEndure API token, navigate to the CloudEndure console, choose Setup & info, choose Other Settings, then choose API Token. If the token does not exist, select Generate token.

    
                        Migration factory CloudEndure API token prompt

    Figure 86: Migration factory CloudEndure API token prompt

The script returns a server list and a cleanup job for each CloudEndure project.


                Server list and cleanup jobs

Figure 87: Server list and cleanup jobs

Shut down the in-scope source servers

This activity shuts down the in-scope source servers involved with the migration. After you verify the source servers’ replication status, you are ready to shut down the source servers to stop transactions from the client applications to the servers. You can shut down the source servers in the cutover window. Shutting down the source servers manually could take five minutes per server, and, for large waves, it could take a few hours in total. Instead, you can run this automation script to shut down all your servers in the given wave.

Use the following procedure from the migration execution server to shut down all the source servers involved with the migration.

  1. Signed in as an administrator, open a command prompt (CMD.exe).

  2. Navigate to the c:\migrations\scripts folder and run the following Python command.

    python 4-Shutdown-all-servers.py --Waveid <wave-id>

    Replace <wave-id> with the appropriate Wave ID value to shut down the source servers.

  3. Log in to the solution with your username and password.

    
                        Migration factory login

    Figure 88: Migration factory login

After you are logged in, the script first shuts down Windows servers in the specified wave.


                Shut down Windows servers

Figure 89: Shut down Windows servers

After the Windows servers are shut down, the script proceeds to the Linux environment and prompts for the login credentials. After successful login, the script shuts down the Linux servers.


                Shut down Linux servers

Figure 90: Shut down Linux servers

Retrieve the target instance IPs

This activity retrieves the target instance IPs. If the DNS update is a manual process in your environment, you would need to get the new IP addresses for all the target instances. However, you can use the automation script to export the new IP addresses for all the instances in the given wave to a CSV file.

Use the following procedure from the migration execution server to retrieve the target instance IPs.

  1. Signed in as an administrator, open a command prompt (CMD.exe).

  2. Navigate to the c:\migrations\scripts folder and run the following Python command.

    python 4-Get-instance-IP.py --Waveid <wave-id> --CloudEndureProjectName <project-name>

    Replace <wave-id> with the appropriate Wave ID value and <project-name> with the CloudEndure project name to get the new IP addresses for the target instances.

  3. Log in to the solution with your username and password.

    
                        Migration factory login

    Figure 91: Migration factory login

  4. Enter the CloudEndure API token.

    Note

    To find your CloudEndure API token, navigate to the CloudEndure console, choose Setup & info, choose Other Settings, then choose API Token. If the token does not exist, select Generate token.

    The script returns a server list and the target instance ID information for the specified project.

    
                        Migration factory CloudEndure API token prompt, server list, and target instance ID information

    Figure 92: Migration factory CloudEndure API token prompt, server list, and target instance ID information

  5. Enter the AWS access key and secret access key for the target account.

    
                        AWS access key and secret key prompt

    Figure 93: AWS access key and secret key prompt

    Note

    Your AWS access key will need to have Amazon EC2 read-only permission in the target AWS account.

The script exports the server name and IP addresses information to a CSV file (<wave-id>-<project-name>-IPs.csv) and places it in the same directory as your migration script (c:\migrations\scripts).

The CSV file provides instance_name and instance_IPs details. If the instance contains more than one NIC or IP, they will all be listed and separated by commas. If you have more than one CloudEndure project in the specified wave, you can repeat this activity for each project.


                CSV file showing instance_name and instance_IPs

Figure 94: CSV file showing instance_name and instance_IPs

Verify the target server connections

This activity verifies the connections for the target server. After you update the DNS records, you can connect to the target instances with the host name. In this activity, you check to see if you can log in to the operating system by using Remote Desktop Protocol (RDP) or through Secure Shell (SSH) access. You can manually log in to each server individually, but it is more efficient to test the server connection by using the automation script.

Use the following procedure from the migration execution server to verify the connections for the target server.

  1. Signed in as an administrator, open a command prompt (CMD.exe).

  2. Navigate to the c:\migrations\scripts folder and run the following Python command.

    python 4-Verify-server-connection.py --Waveid <wave-id>

    Replace <wave-id> with the appropriate Wave ID value to get the new IP addresses for the target instances.

    Note

    This script uses the default RDP port 3389 and SSH port 22. If needed, you can add the following arguments to reset to the default ports: --RDPPort <rdp-port> --SSHPort <ssh-port>.

  3. Log in to the solution with your username and password.

    
                        Migration factory login

    Figure 95: Migration factory login

    The script retrieves the server list.

    
                        Server list

    Figure 96: Server list

  4. Enter the Linux sudo username and password for source servers.

    
                        Linux sudo user login prompt

    Figure 97: Linux sudo user login prompt

    The script returns the test results for both RDP and SSH access.