Microsoft iSCSI Software Target Migration Guide

Documentation and tools that are provided by the Microsoft iSCSI Software Target Migration Guide ease the migration of server role settings and data from an existing server to a destination server that is running Windows Server® 2008 R2 or Windows Storage Server® 2008 R2. By using the tools that are described in this guide, you can simplify the migration process, reduce migration time, increase the accuracy of the migration process, and help eliminate possible conflicts that might otherwise occur during the migration process. For more information about installing and using the migration tools on the source server and the destination server, see the Windows Server Migration Tools Installation, Access, and Removal Guide (https://go.microsoft.com/fwlink/?LinkId=134763).

Target audience

The following organizational roles will find the information in this guide useful:

  • IT architects who are responsible for computer management and security throughout an organization

  • IT operations engineers who are responsible for managing and troubleshooting networks, servers, client computers, operating systems, or applications.

  • IT operations managers who are accountable for network and server management

What this guide does not provide

This guide does not provide instructions for the following scenarios:

  • Migrating certain clustering scenarios

  • Upgrading multiple roles on the same computer

  • Migrating more than one server role

Supported migration scenarios

This guide provides IT professionals with instructions to migrate an existing server that is running Microsoft® iSCSI Software Target 3.2 or 3.3 (as included with Windows Storage Server 2008 or Windows Storage Server 2008 R2) to a server that is running Microsoft iSCSI Software Target 3.3 (as included with Windows Server® 2008 R2 or Windows Storage Server 2008 R2).

This guide does not contain instructions for migration when the source server is running multiple roles. If your source server is running multiple roles, we recommend that you design a custom migration procedure specific to your server environment, based on the information that is provided in other role migration guides. For more information, see Migrate Server Roles to Windows Server 2008 R2 (https://go.microsoft.com/fwlink/?LinkID=128554).

Warning

If your source server is running multiple roles, some migration steps in this guide, such as those for computer name and IP configuration, can cause other roles that are running on the source server to fail.

Supported operating systems

Source server processor

Source server operating system

Destination server operating system

Destination server processor

x64-based

Windows Storage Server 2008, full installation options

Windows Storage Server 2008 R2, full installation options

x64-based

x64-based

Windows Storage Server 2008 R2

Windows Storage Server 2008 R2

x64-based

x64-based

Windows Server 2008 R2

Windows Server 2008 R2

x64-based

The versions of operating systems that are listed in the preceding table are the oldest combinations of operating systems and service packs that are supported. Newer service packs, if available, are supported.

All applicable editions of Windows Storage Server are supported as a source server or a destination server.

Migrations between physical operating systems and virtual operating systems are supported.

Migration from a source server to a destination server that is running an operating system in a different system UI language (that is, the installed language) than the source server is not supported. For example, you cannot use Windows Server® Migration Tools to migrate roles, operating system settings, data, or shared resources from a computer that is running Windows Server 2008 in the French system UI language to a computer that is running Windows Server 2008 R2 in the German system UI language.

Note

The system UI language is the language of the localized installation package that was used to set up the Windows operating system.

x64-based migrations are supported for Windows Storage Server 2008, Windows Storage Server 2008 R2, and Windows Server 2008 R2. All editions of Windows Storage Server 2008 R2 and Windows Server 2008 R2 are x64-based.

x86-based migrations are not supported because Windows Storage Server 2008 is not offered in the x86 platform.

Supported role configurations

This migration guide is applicable to standalone and clustered configurations, with certain limitations.

The following general restrictions are applicable to all the supported configurations:

  • Authentication settings for iSCSI initiators that use CHAP and Reverse CHAP settings are not automatically migrated.

  • Snapshot storage settings for each virtual disk in the configuration are not automatically migrated.

  • Configuration settings for virtual disks that are derived from snapshots are not automatically migrated.

  • For clustered configurations, the migration process includes iSCSI Software Target settings that are scoped to the virtual computer object, to a cluster node, or to the cluster node that owns the code cluster group.

  • For clustered configurations, the migration of resource groups, network name resources, IP addresses, and cluster disks that are associated with resource groups is outside of scope for this guide, and it needs to be performed independently as a preliminary step.

  • iSCSI Naming Services (iSNS) settings for Microsoft iSCSI Software Target are not automatically migrated.

  • iSCSI Software Target portal settings (such as IP addresses that are used by the iSCSI Software Target service to listen for incoming network connections) are not automatically migrated.

  • The schedule for snapshots of virtual disks is not migrated.

The following configurations are supported:

  • Migration from a non-clustered configuration to a non-clustered configuration

  • Migration from a clustered configuration to a standalone configuration (with the restrictions listed previously regarding the scope of the settings).

  • Migration from a clustered configuration to a clustered configuration (with the restrictions listed previously regarding the scope of the settings).

Supported role services and features

Microsoft iSCSI Software Target 3.3 (as included with Windows Storage Server 2008 R2) does not have role dependencies or feature dependencies.

It is possible to install Microsoft iSCSI Software Target with failover clustering, and this configuration is supported with the limitations listed previously.

Migrating multiple roles

If you are migratign one clustered configuration to a different clustered configuration, the Failover Clustering feature needs to be migrated or set up prior to migrating the iSCSI Software Target settings.

Migration scenarios that are not supported

The following migration scenarios are not supported:

  • Migration from Windows Unified Storage Server 2003 R2. Migration is supported for only one version previous to Windows Storage Server 2008 R2.

  • Migration from a standalone configuration to a clustered configuration. This migration is not supported because there is no default mechanism to associate target and virtual disk settings to resource groups without knowing how the file paths are mapped to the cluster disk and how IP Addresses are mapped to resource groups.

  • Snapshots of virtual disks are not automatically migrated. Snapshots are based on a snapshot of the volume that contains the virtual hard disk (VHD) file at the time the snapshot was taken. Their existence and implementation depends on the volume of the computer from which the migration process happens, and it cannot be replicated or exported.

  • Snapshot storage settings for virtual disks are not automatically migrated. The snapshot storage settings (such as volume and maximum size per volume) are dependent on the hardware and software configuration of the computer that the settings are being migrate to, and they cannot automatically be migrated. For detailed information about how to manually migrate the snapshot storage settings, see Migrating Microsoft iSCSI Software Target.

  • The configuration settings of the iSCSI Software Target portal are not automatically migrated. The iSCSI Software Target portal configuration is based on the IP addresses of the destination server, and those settings cannot be migrated outside the knowledge of the network configuration of the computer that the settings are being migrate to. For detailed information about how to manually configure the portal settings, see Migrating Microsoft iSCSI Software Target.

  • iSNS settings are not automatically migrated. The iSNS settings are based on the network infrastructure and configuration of the destination server, and those settings cannot be migrated outside the knowledge of the network configuration of the computer that the settings are being migrate to. For detailed information about how to manually configure iSNS settings, see Migrating Microsoft iSCSI Software Target.

  • Settings for virtual disks that are surfaced as local disks on the iSCSI Software Target source server are not automatically migrated. The ability to surface a disk locally is expected to be a temporary operation that can be replicated if. For detailed information about how to configure settings for virtual disks that are to be surfaced as local disks, see Migrating Microsoft iSCSI Software Target.

  • The schedule for snapshots of virtual disks is not migrated. The snapshot schedule settings are only set through the Microsoft Management Console (MMC) snap-in, and they cannot easily be discovered or automatically replicated. Those settings must be manually discovered and replicated from the source to the destination server.

iSCSI Software Target server migration overview

This section describes the migration process for the iSCSI Software Target server. At high level, the iSCSI Software Target server migration process involves harvesting configuration settings from the source, moving the virtual disks from the source server to the destination server, and restoring the configuration settings.

Migration planning

The migration planning phase involves gathering the following information:

  • Are the source server and destination server are configured in a cluster?

  • If the servers are configured in a cluster, what are the virtual computer objects or client access points that contain the iSCSI Software Target resources?

  • Is the storage system of the destination server capable and configured appropriately to host the virtual disks of the source server, and does it have appropriate space to store the volume snapshots?

  • Are there any iSCSI initiators that have a critical dependency on iSCSI Software Target for the duration of the migration process (such as a computer that uses iSCSI boot nodes, or clusters that use iSCSI Software Target for shared storage)?

  • Are there any IP address or portal settings that are unique to the source server that need to be accounted for (such as IP addresses that are known to the firmware of devices)?

  • Are there any iSNS settings that need to be manually recorded and migrated?

  • Are there any virtual disks surfaced as local disks that might need to be exposed?

Preparing to migrate

The preparation to migrate data from the source server to the destination server involves the following steps:

  • If the destination server will have a clustered configuration, install the Failover Clustering feature and form a cluster before performing the migration.

  • If the destination server will have a clustered configuration, create a number of cluster resource groups with client access points and cluster disks as appropriate to replicate the existing configuration. If possible, use the same resource group names for the source clusters and the destination clusters.

  • Install and enable iSCSI Software Target on the destination server.

  • Disconnect all the iSCSI initiators that use iSCSI Software Target. This step is required to maintain consistent data on the virtual disks while they are being moved.

  • Run the Windows® PowerShell™ script, iSCSITargetSettings.ps1, to capture the existing settings on the source server in an XML file. For a cluster, run the script on each node in the cluster or on each virtual computer object, as appropriate for the scope of the planned migration.

    The Windows PowerShell script displays the virtual disks that are eligible for migration and those that are not (for the snapshot-based reasons discussed previously).

Migration

The actual migration process consists in the following steps:

  • Move the files for all the virtual disks that are eligible for migration from the source server to the destination server. If there are anyfile path changes, note the source to destination mapping.

  • In a cluster configuration, ensure that the destination path of the file copy is on a cluster disk and that the cluster disk has been assigned to a resource group. Note of the resource group that owns the path.

  • If the file paths have changed between the source and the destination servers, open the settings .xml file in a text editor, and identify the <MigrationDevicePath> tags that need to be changed to reflect the new path.

  • In a cluster configuration, if the file path or the resource group name have changed between the source server and the destination server, open the settings .xml file in a text editor, and identify the <MigrationResourceGroup> tags that need to be changed to reflect the new resource group.

  • Run the Windows PowerShell script, iSCSITargetSettings.ps1, to import the settings to the destination server. In a cluster configuration, the destination server can be specified as a cluster node or as a virtual computer object. The cluster node or virtual computer object must be the owner of the resource group that is indicated in the settings .xml file.

  • If there are snapshot storage settings relevant to the new configuration, apply those settings manually.

  • If there are virtual disks that need to be surfaced as local disks, performe those actions.

  • If there are any iSNS settings that are relevant to the new configuration, apply those settings manually.

  • If there are any iSCSI Software Target portal settings that are relevant to the new configuration, apply those settings manually.

  • If there are any iSCSI initiators that are configured to authenticate by using CHAP and Reverse CHAP, manually restore those settings.

Verification

The verification process for the migration involves the following steps:

  • Validate the iSCSI Software Target portal settings by opening a Command Prompt window and typing netstat.exe –nao | findstr 3260. (This assumes that the default TCP port for the iSCSI protocol 3260 is used). Alternatively, type Get-WmiObject –Namespace root\wmi –Class WT_Portal to cross-check the results.

  • Inspect the iSCSI Software Target configuration by using the Windows PowerShell cmdlet, Get-WinIScsiTarget, in the MicrosoftISCSITarget module.

  • Inspect the iSCSI virtual disk configuration by using the Windows PowerShell cmdlet, Get-WinIScsiVirtualDisk in the MicrosoftISCSITarget module.

  • Validate the configuration for each iSCSI initiator that you expect to use with iSCSI Software Target by using the iscsicpl.exe UI tool or the iscsicli.exe command line tool.

Impact of migration

The migration process does not impact or affect the source server. There are no resources or configuration settings that are altered or deleted as part of the migration process.

No servers in the enterprise, other that the destination servers, will be affected by the migration.

Client computers that are running iSCSI Software Target are iSCSI initiators. The iSCSI initiators are expected to be explicitly disconnected during the migration to ensure data integrity. During the migration, the source server will be unavailable. When the migration process is complete, it is expected that the iSCSI initiators will log on to destination server without any issues.

The downtime for the iSCSI initiators is expected to be proportionate to the time it takes to move the virtual disk files from the source server to the destination server, plus the time needed to restore the configuration settings and to establish the network identity of the destination server.

Permissions required to complete migration

Local Administrator permissions are required on the source and the destination server.

If the iSNS server has additional access control policies, permission to alter the iSNS settings are required as appropriate for the iSNS server.

To perform the migration process for the iSCSI initiators, permissions to log on and log off iSCSI sessions are required. For the Microsoft iSCSI Initiator, Local Administrator permissions are required. If your iSCSI initiators is running another operating system, consult the iSCSI initiator guide for each operating system for additional information.

For iSCSI initiators that are firmware based, such as a network interface with the option to boot from iSCSI, being at the actual console may be required to configure logon credentials or the network identity of the destination server if the authentication settings (CHAP and Reverse CHAP) have changed.

Estimated duration

Planning

The planning phase is expected to be influenced by the following factors:

  • Standalone versus a cluster configuration. A cluster setup may require one to two hours to configure if all the validations are performed. For more information, see Migration of a Windows Server 2008 Failover Cluster to Windows Server 2008 R2 (https://go.microsoft.com/fwlink/?LinkID=142796).

  • Storage configuration. Understanding and configuring a storage array to host potentially huge files requires that you plan the spindle and volume configurations so that they use the tools that are provided by the storage array vendor.

  • Network identity. This planning involves understanding if the source server has specially or purposely configured IP addresses, if configuring Level-2 components (such as switches) is required, and if specific DNS or NetBIOS names need to be known to and cached by the iSCSI initiators.

Preparation

The preparation process involves understanding which settings (that are specific to the source server) cannot be automatically migrated, and gathering those settings. For each step in the preparation phase, the mechanism that is used to retrieve the settings depends on which step is applicable and which tool is used to recover those settings.

  • Cluster resource group names and configuration. These settings can be gathered from the cluster administration tools and the user interfaces.

  • iSCSI Software Target portal configuration. These settings can be gathered by typing the following code at a command prompt:

    PS > Get-WmiObject –Namespace root\wmi –Class WT_Portal

  • iSNS Server settings. These settings can be gathered by typing the following code at a command prompt:

    PS > Get-WmiObject –Namespace root\wmi –Class WT_ISnsServer

  • CHAP and Reverse CHAP authentication settings. These settings cannot be automatically retrieved because the iSCSI Software Target server does not offer a mechanism to retrieve passwords. These settings have been stored elsewhere in the enterprise, and they need to be retrieved independently.

  • Locally mounted virtual disk settings.

Migration

The estimated time for the actual migration process is largely dominated by the time that it takes to move the virtual disk files from the source server to the destination server.

A network-based file copy, using a 1 GB link used at 50% for 1 TB of data, is estimated to take over five hours. Techniques that use a file transfer process involving external media, such as an External Serial Advanced Technology Attachment (eSATA) device, may take less time.

The execution of the Windows PowerShell import script is estimated to take few minutes for approximately 100 resources (with a combination of iSCSI Software Target settings and virtual disk settings).

Verification

The estimated time for the verification is proportionate to the time it takes to reconnect or log on to the iSCSI initiators.

For each iSCSI initiator, the target portal needs to be reconfigured (in case the iSCSI Software Target has changed its network identity), credentials related to authentication settings must be entered (if required), and the sessions have to be logged on.

The estimated time is 5 to 15 minutes to verify each iSCSI initiator, depending on the process that is being used. iSCSI initiators can be verified through the iscsicpl.exe UI, through the iscsicli.exe command line tool, or through ad hoc Windows Management Instrumentation (WMI)-based scripts).