Preparing to Migrate

Article
05/07/2012

Applies To: Microsoft iSCSI Software Target

This topic discusses the tasks that are necessary before you start the iSCSI Target migration process.

Install migration tools

Windows Server Migration Tools in Windows Server 2008 R2 allows an administrator to migrate some server roles, features, operating system settings, shares, and other data from computers that are running certain editions of Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2 to computers that are running Windows Server 2008 R2.

Complete installation, configuration, and removal instructions for Windows Server Migration Tools are available in the Windows Server 2008 R2 Technical Library. For more information, see Migrate Server Roles to Windows Server 2008 R2 (https://go.microsoft.com/fwlink/?LinkID=128554).

Migration documentation and tools that are provided ease the process of migrating server role settings and data from an existing server that is running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2 to another computer. By using these tools to migrate roles, you can simplify migration, reduce migration time, increase accuracy of the migration process, and help eliminate conflicts that could otherwise occur during the migration process.

Using Windows PowerShell cmdlets

Cmdlets are built-in commands that are included with Windows PowerShell and installed by default as part of Windows Server 2008 R2. For more information about Windows PowerShell and how cmdlets work, see Scripting with Windows PowerShell (https://go.microsoft.com/fwlink/?LinkID=122931).

Except where specifically noted, Windows PowerShell cmdlets are not case-sensitive. You can obtain detailed Help about specific syntax, parameters, and usage guidelines for any installed Windows PowerShell cmdlet by typing Get-Help <cmdlet_name> -full in a Windows PowerShell session, where cmdlet_name represents the name of the cmdlet for which you want help.

Although most commands for iSCSI Target migration are Windows PowerShell cmdlets, you can run executable files in a Windows PowerShell session by adding an ampersand (&) before the executable file name. The ampersand is the call operator in Windows PowerShell.

If the executable file is not in the current directory, add the absolute path name, as shown in the following examples. If an executable file name contains spaces, enclose the file name in quotation marks. If you are running the executable file from the current directory, precede the file name with .\.

Executable file that is not in the current directory: PS C:\> & C:\Windows\System32\notepad.exe
Executable file that is in the current directory: PS C:\Windows\System32> & .\notepad.exe
Executable file name that contains a space and is in the current directory: PS C:\Windows\System32> & ".\executable test.exe"

Prepare your destination server

The destination server is a computer that is configured and shipped by an OEM with Windows Storage Server 2008 R2 pre-installed.

Hardware requirements for the destination server are as follows:

The amount of free disk space on the destination server must be sufficient to host the iSCSI virtual disk from the source server with adequate room for the snapshot storage.
For clustered configurations, the resource groups that are created in the destination server must have associated cluster disks with adequate free space to host the iSCSI virtual disk from the source server.
The destination server must have one or more network interfaces to be utilized for the iSCSI network traffic.

If Microsoft iSCSI Software Target 3.3 is being installed for evaluation purposes, the following steps must be followed:

Install the failover cluster

Installing the Failover Cluster feature in Windows Storage Server 2008 R2 is required if the source server was configured with failover clusters. For more information, see the Failover Cluster Deployment Guide (https://go.microsoft.com/fwlink/?LinkID=179364).

Install iscsitarget.msi

Locate the path to iscsitarget.msi in your installation media.
Invoke the installation process by using the following Windows PowerShell command:PS > & msiexec.exe /i “<path to installation source>\iscsitarget.msi” /qr
Validate that the WinTarget service is running by using the following Windows PowerShell command:PS > & sc.exe query wintarget
Validate that the service is listening by default on all available IP addresses of the server by using the following Windows PowerShell command:PS > & netstat –nao | findstr 3260

Back up your source server

Before you start migration, as a best practice, we recommend that you back up the source server.

For information about backing up Windows Server 2003, see Backing up and restoring data (https://technet.microsoft.com/en-us/library/cc738632(WS.10).aspx).
For information about backing up Windows Server 2008 and Windows Server 2008 R2, see Backup and Recovery (https://go.microsoft.com/fwlink/?LinkID=195054).

Prepare your source server

This step should be completed by the server role team. The team should eescribe how to prepare the source server for migration. Consider what services must be stopped before you can begin migration. Discuss when the users will need to be disconnected (if required). While preparing these instructions, focus on minimizing the downtime and the user impact.

Cluster resource group configuration

Gather the resource groups that have iSCSI Software Target resources by using the following Windows PowerShell command:

PS > Import-Module FailoverClusters
PS > $iSCSITargetResources = Get-ClusterResource | Where-Object { ( $_.ResourceType.Name -eq "Host" ) –or ($_.ResourceType.Name -eq "WTDisk") }
PS > $iSCSITargetResources

From the cluster resources obtained in the previous step, gather the cluster disk dependencies by using the following Windows PowerShell command:
```
PS > $Dependencies = &{ $iSCSITargetResources | Get-ClusterResourceDependency  }
PS > $Dependencies
```

If the source server is running Windows Storage Server 2008, the following steps can be followed to gather the equivalent information.

Gather the iSCSI Software Target resources, and then gather the groups by using the following Windows PowerShell command:

PS > $iSCSITargetResources = Get-WmiObject -NameSpace root\mscluster -Authentication PacketPrivacy -Class MsCluster_Resource -Filter "Type = `"WTDisk`" or Type = `"Host`""
PS > $iSCSITargetResources
PS > $Groups = &{foreach($res in $iSCSITargetResources) { Get-WmiObject -NameSpace root\mscluster -Authentication PacketPrivacy -Query "associators of {$($res.__RELPATH)}  WHERE ResultClass = MSCluster_ResourceGroup" }}
PS > $Groups

From the cluster resources obtained in the previous steps, gather the cluster disk dependencies by using the following Windows PowerShell command:

PS > $Dependencies = &{foreach($res in $iSCSITargetResources) { Get-WmiObject -NameSpace root\mscluster -Authentication PacketPrivacy -Query "associators of {$($res.__RELPATH)}  WHERE ResultClass = MSCluster_Resource ResultRole = Dependent" }}
PS > $Dependencies

The resource groups obtained in step 1 have network name resources and IP addresses that need to be migrated to the destination server.

For information about how to migrate these settings, see Migrating Settings to a Failover Cluster Running Windows Server 2008 R2 (https://go.microsoft.com/fwlink/?LinkID=142796).

The cluster disk that you obtained in step 2 is the physical disk where the volumes that are hosting the iSCSI Software Target virtual disks reside.

To obtain the volumes from the cluster disk, use the following steps:

Obtain the disk signature of the cluster disk by using the following Windows PowerShell command:
```
PS > & cluster.exe res "<cluster resource name>" /priv
```

Obtain the Win32_DiskDrive object from the disk signature by using the following Windows PowerShell command:

PS > $DiskObj = Get-WmiObject -Namespace root\cimv2 -Class Win32_DiskDrive -Filter "Signature = <disk signature>"
PS > $DiskObj

Obtain the Win32_DiskDriveToDiskPartition association by using the following Windows PowerShell command:

PS > $DiskToDiskPartition = Get-WmiObject -Namespace root\cimv2 –Class Win32_DiskDriveToDiskPartition | Where-Object { $_.Antecedent -eq $DiskObj.__PATH }
PS > $DiskToDiskPartition

Obtain the Win32_LogicalDiskToDiskPartition association that points to the volume association by using the following Windows PowerShell command:

PS > Get-WmiObject -Namespace root\cimv2 -Class Win32_LogicalDiskToPartition | Where-Object { $_.Antecedent -eq $ DiskToDiskPartition.Dependent }

Steps 2 through 4 need to be applied on the source server cluster node that currently owns the physical disk cluster resource.

Target portal configuration

Gather the configured portals association for the iSCSI Software Target server by using the following Windows PowerShell command:
```
PS> Get-WmiObject -Namespace root\wmi -Class WT_portal | Format-List -Property Address,Listen,Port
```
The IP addresses that have the Listen state set to True are the IP addresses that an iSCSI initiator can use to reach the server. For more information about migrating the IP addresses, see the IP Configuration Migration Guide (https://go.microsoft.com/fwlink/?LinkID=128513).

iSNS configuration

Gather the configured iSCSI Naming Services (iSNS) association for the iSCSI Software Target server by using the following Windows PowerShell command:

PS> Get-WmiObject -Namespace root\wmi -Class WT_ISnsServer | Format-List -Property ServerName

The server names that are listed need to be added to the list of iSNS servers that can be used to retrieve information about the iSCSI initiators in the enterprise.

CHAP and Reverse CHAP configuration

Gather the UserName and ReverseCHAPUserName association for the iSCSI Software Target servers that are configured with CHAP and Reverse CHAP by using the following Windows PowerShell command:

PS > Get-WmiObject -Namespace root\wmi -Class WT_Host | Where-Object { ( $_.EnableCHAP ) -or ( $_.EnableReverseCHAP )  } | Format-List -Property Hostname,CHAPUserName,ReverseCHAPUserName

The passwords that are used in conjunction with the credentials listed previously cannot be retrieved from the iSCSI Software Target server settings, and they must be known through other mechanisms.

Snapshot storage configuration

The snapshot storage configuration can be obtained by using the following Windows PowerShell command:

PS > & vssadmin.exe list shadowstorage

This command shows the volume snapshot shadow storage configuration for the entire source server. Not all the volumes listed may be relevant to the current iSCSI Software Target server configuration.

For the volumes that are relevant (that is, the volumes that host iSCSI virtual disks), the associated shadow storage volume is listed, in addition to the amount of disk space used with the maximum amount of configured space.

Locally surfaced virtual disk configuration

The list of locally surfaced disks can be obtained by using the following Windows PowerShell command:

PS > $LocalMountDisks = Get-WmiObject -Namespace root\wmi -Class WT_Disk | Where-Object { $_.DVMountStatus -ne 0 }
PS > $LocalMountDisks

The paths where the disks have been locally surfaced can be obtained by using the following Windows PowerShell command:

PS > Get-WmiObject -Namespace root\wmi -Class WT_DvMountedPath

The set of virtual disks that are locally surfaced needs to be manually recreated on the destination server after the volume letter assignment and volume mount-point strategy have been implemented.

Disconnect the iSCSI initiators

Follow the instruction in the following section to disconnect the iSCSI initiators: Prepare other computers in the enterprise.

Capture the existing settings: standalone configuration

All of the settings on the iSCSI Software Target server that are not hardware configuration specific and are not dependent on an IP address and the network identity of the server can be captured with the following Windows PowerShell command:

PS > cd “$ENV:Programfiles\Microsoft iSCSI Software Target”
PS> .\ iSCSITargetSettings.PS1 –Export –FileName <settings XML file>

If the procedure is performed on a source server that is running Microsoft iSCSI Software Target 3.2 from a destination server that is prepared as illustrated in the previous sections, and the destination server is running Microsoft iSCSI Software Target 3.3, the settings can be captured using the following Windows PowerShell command:

PS > cd “$ENV:Programfiles\Microsoft iSCSI Software Target”
PS> .\ iSCSITargetSettings.PS1 –Export –FileName <settings XML file> -ComputerName <source server computer name>

At the end of the settings capture process, the Windows PowerShell script will display the set of VHD files that are eligible for migration. This list is needed for the destination server during migration.

Capture the existing settings: clustered configuration

Before capturing the iSCSI Software Target server settings that are not hardware configuration specific, we recommend that all the resource groups with iSCSI Software Target resources are moved to a single node in the cluster.

This can be accomplished by using the following Windows PowerShell commands. These commands assume that you previously followed the steps in the following section: Cluster resource group configuration.

PS > $iSCSITargetResources | Format-List -Property OwnerGroup
PS > foreach($Res in $iSCSITargetResources) { & cluster group  $Res.OwnerGroup /moveto:$ENV:COMPUTERNAME }

After all the resource groups have been moved to a single node, the settings can be gathered by using the following Windows PowerShell commands:

PS > cd “$ENV:Programfiles\Microsoft iSCSI Software Target”
PS> .\ iSCSITargetSettings.PS1 –Export –FileName <settings XML file>

If the procedure is performed on a source server that is running Microsoft iSCSI Software Target 3.2, the resources can be moved to a single node by using the following Windows PowerShell command:

PS >  $Groups = &{foreach($res in $iSCSITargetResources) { Get-WmiObject -NameSpace root\mscluster -Authentication PacketPrivacy -Query "associators of {$($res.__RELPATH)}  WHERE ResultClass = MSCluster_ResourceGroup" }}
PS > foreach($Group in $Groups) { & cluster group $Group.Name /moveto:<node name source server> }

The Microsoft iSCSI Software Target settings need to be gathered from a destination server that is prepared as illustrated in the previous sections, and that is running Microsoft iSCSI Software Target 3.3. Run the script for a source server that is running Microsoft iSCSI Software Target 3.2 by using the following Windows PowerShell command:

PS > cd “$ENV:Programfiles\Microsoft iSCSI Software Target”
PS> .\ iSCSITargetSettings.PS1 –Export –FileName <settings XML file> -ComputerName <source server computer name>

In this command, the source server computer name is the name of the node. At the end of the settings capture process, the Windows PowerShell script will display the set of VHD files that are eligible for migration. This list is needed for the destination server during migration.

Remove the network identity of the iSCSI Software Target server

In a network with an iSCSI Software Target server, the identity of the server is known to iSCSI initiators in the form of NetBIOS names, fully qualified domain names (FQDN), or IP addresses. When a server is being replaced, as part of planning, a strategy to replace the server network identity must be devised. Possible scenarios include:

Transfer the NetBIOS and fully qualified domain names to the destination server, and then assign new IP addresses to the destination server.
Create new NetBIOS and fully qualified domain names for the destination server, and then assign the existing IP addresses to the destination server.
Create new NetBIOS and fully qualified domain names for the destination server, and then assign new IP addresses to the destination server.

Each scenario requires potentially updating information in the DNS server, Active Directory, or DHCP server, according to the methodology that is used to assign IP addresses and network names to the servers in the enterprise.

The intent of this step is to ensure that upon completion of the migration steps, the iSCSI initiators are able to locate the destination server (either through explicit reconfiguration, or implicitly through the computer name or IP address re-assignment).

For more information, see the IP Configuration Migration Guide (https://go.microsoft.com/fwlink/?LinkID=128513).

Prepare other computers in the enterprise

The other computers in the enterprise that are affected by migrating Microsoft iSCSI Software Target are the iSCSI initiators. The users of the computers that are acting as iSCSI initiators should be sent an outage notification. If the iSCSI Software Target is being used as a boot node for the iSCSI initiator computers, the computers may be completely unusable for the duration of the migration.

Capture the session information

The information regarding the active session for an iSCSI Software Target server can be obtained by using the following Windows PowerShell command:

PS > & iscsicli.exe sessionlist

This information is needed to disconnect the session in the following step.

Disconnect the session

The session can be disconnected by using the following Windows PowerShell command:

PS > & iscsicli.exe LogoutTarget <session id>