/
Environmental and Machine Requirements

Environmental and Machine Requirements

This section addresses the technical requirements that you will need to meet in order to install and use VirtaMove. Requirements are both environmental and machine. You will not be able to install VirtaMove or complete a migration if these requirements are not met, depending on the particular requirement.

VirtaMove automatically runs Audit before a migration. The Audit Report lists the results of the environmental and machine audit. Flagged issues may range from Blocking to informational. See Understanding Audit to learn more about issues that may affect the success of a migration.

Supported Windows Operating Systems - Source Machine

The application to be migrated must reside on a supported Source server running the Windows Operating System. The following versions of Windows are currently supported as Source server environments:

  • Windows Server 2003 (32-bit and 64-bit)

  • Windows Server 2003 R2 (32-bit and 64-bit)

  • Windows Server 2008 (32-bit and 64-bit)

  • Windows Server 2008 R2

  • Windows Server 2012

  • Windows Server 2012 R2

  • Windows Server 2016

  • Windows Server 2019

Supported Windows Operating Systems - Destination Machine

VirtaMove Software must be run on a supported destination server running the Windows Operating System. The following versions of Windows are currently supported on a destination machine:

  • Windows Server 2016

  • Windows Server 2019

  • Windows Server 2022

For information about VirtaMove Support Policies, see Support Policies for VirtaMove Products.

Cross-Architecture Tethering

You can tether an application that is installed on a machine running Windows Server 2003 Service Pack 2 x86 or greater to a destination machine running Windows Server 2012 R2 x64, Window Server 2016, Windows Server 2019 or Windows Server 2022.

VirtaMove does not support migrating an application in the reverse direction, that is, from a 64-bit machine to a 32-bit machine.

Operating System Viability

The operating system of the destination machine must be equal to or newer than that of the source machine. VirtaMove does not support downleveling.

The operating systems of the destination and source machines must both be server operating systems. Desktop operating systems are not supported.

VSS Requirements - Source Machines

VirtaMove uses an optimized VSS storage configuration. Instead of storing the VSS snapshot of a drive in that drive itself, the feature automatically picks the most suitable storage drive for each client drive.

The default VSS requirements for source machines are:

  • The free space of each storage drive must be a minimum of 2 GB.

  • The free space of each storage drive needs to be at least 20% of the sum of the disk capacity of all its client drives.

VirtaMove picks the storage drive in descending order of free space.

Example:

The source machine has 4 drives:

C:, D:, E:, and F:

  • Drive F:
    Has the most free space. VSS for C: D: E: F: will be stored on drive F: if F: has a minimum of 2 GB free space and its free space is at least 20% of the sum of the disk capacity of C: D: E: F:.

  • Drives C: D: E:
    Does not have to meet the 2 GB and 20% requirement.

VirtaMove Field Engineers can change default values using the virtatetheradmin command on the destination:

VIRTATETHERADMIN.EXE /HOST Hostname /VssFreeSpaceInPercentage value
VIRTATETHERADMIN.EXE /HOST Hostname /VssFreeSpaceInGB value

Notes:

  • If these values are modified, the Source Agent will need to be restarted.

  • VSS requirements may change in future releases of VirtaMove.

Destination Server Capacity

Make sure that the destination server or servers have adequate capacity to run the applications you are migrating. That is, the destination servers must have equivalent or greater storage capacity and compute resources than the source server:

  • equal or greater number of CPU cores

  • equal or greater available memory (RAM)

  • equal or greater available disk space, or if you will be running Dissolve, twice the available disk space

  • same number of disks, each of them with equal or greater size and with the same drive letter as on the source server

Make sure that the drive on the destination server where the container will be created (by default, C:\appliances) has enough space to contain the entire application, meaning the sum total of all drives used by the application.

Credentials

VirtaMove Source Agent and Credentials for the Source Machine

If VirtaMove Source Agent is installed on the source machine, you will not require Administrative login credentials. Additionally, VirtaMove will automatically export service users and any other selected users local to the source server. However, if credentials are required for logging into the application and/or accessing the database, you will need to know the passwords ahead of time.

Credentials for Destination and Source Machines without VirtaMove Source Agent

Make sure that you have credentials (username and password) for the accounts that will be used during the migration and by the application. You will require accounts with administrative rights on both destination and source machines. VirtaMove best practice is to always use the built-in Administrator account (local user account with SID ending in 500) of the machine. When this is not possible, an account with direct membership in the built-in Administrators group (local group with SID ending in 544) will be needed. A local user account is preferable under these circumstances. Use a domain account with direct membership in this group only as a last resort. A domain administrator account must be explicitly added to a local Administrators group.

You will also require credentials for any service accounts used by the application you are migrating.

A user may proceed with a migration if:

  • For Windows Server 2003 source machines, they are a member of the Administrators Group

  • For Windows Server 2008 R2 and Windows Server 2012 R2, they are a member of the Administrators Group AND if User Account Control (UAC) is enabled, the registry key

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy

    is set to 1 to allow the user to be elevated.

    • Alternatively, you can add the key value by means of a .reg file located in the extras folder. Copy add_LocalAccountTokenFilterPolicy.reg to the source machine and then double-click the file. To remove the key value, copy remove_LocalAccountTokenFilterPolicy.reg to the source machine and then double-click the file.

For assistance with administrator credentials, contact your system administrator.

For all migrations, the account that is being used to migrate must be part of the Distributed COM Users group.

.NET Framework Requirements

The VirtaMove software requires the following versions of the .NET framework installed on the destination machine before installation:

  • .NET Framework 3.5

  • .NET Framework 4.0+

The .NET Framework of the source machine cannot be higher than that of the destination machine. If it is, install the appropriate versions before performing the migration.

Shortnames Enabled on C

Shortnames must be enabled on the C:/ drive are enabled on the destination machine. You cannot create a container on a drive where shortnames have been disabled.

To enable short names:

  • In the Administrator Command Prompt window, execute the following:

    fsutil 8dot3name set 0

Note that this will give short names to files and directories created after the command is run. Files and directories that exist before you run the command will not have short names. 

For more information about this command, see https://technet.microsoft.com/en-ca/library/ff621566.aspx.

What if I add a drive after a migration starts?

If you add a drive after a migration starts and run fsutil, the command will not pick up the global change. To resolve this issue:

  1. Run fsutil 8dot3name set 2. This disables the global setting and lets you perform the action on a per drive basis.

  2. Run fsutil for each of the physical drives. For example: 

    fsutil 8dot3name set C: 0 fsutil 8dot3name set D: 0 fsutil 8dot3name set E: 0

For Best Results

Clean Destination Machine

For the best possible results, VirtaMove requires a clean destination machine. This is typically a server where the operating system has the latest Windows updates and patches applied, and VirtaMove is the only software package installed.

Antivirus Software

Do not install and run antivirus software or "endpoint security" agents on the destination machine.

Antivirus software or "endpoint security" agents interfere with VirtaMove software on the destination machine.

Note: Many of these agents have self-restart logic and similar safeguards; temporarily disabling them is therefore not sufficient.

  • Do not install such software on the destination machine until after the migration, including Dissolve, is complete.

  • After you have run Dissolve successfully on the final destination machine, you can install antivirus software.

  • These agents can be installed and run on the source machine without affecting VirtaMove software or application migration.

Antivirus Sanity Checks

VirtaMove performs a sanity test to check that it can intercept the system calls properly. Sanity tests occur:

  • Each time you dock a container. If a sanity test fails, the docking process is halted.

  • Periodically, to make sure that antivirus self-restart has not occurred. This occurs for docked containers only.

The default interval for periodic tests is every 1 hour. You can change the default interval by modifying the AntivirusCheckInterval registry key in HKLM\Software\VirtaMove Settings\Controller.

If an antivirus is detected, an error is displayed. You will not be able to dock, run, or sync the container until the antivirus software is removed from the destination machine.


TCP and UDP traffic on Port 9665

Port 9665 traffic is required to establish a connection between the Destination Server and the VirtaMove Source Agent on the Source Server. Two inbound rules must be created on the Source Server: one for the TCP and one for the UDP port (both 9665).