Share via

Microsoft iSCSI Software Target 3.3: Known Issues and Updates

  • Article

This document provides late-breaking information for Microsoft® iSCSI Software Target 3.3. You can find more information on the Windows Storage Server blog.

In these release notes:

  • Update 1 issue

  • Update 2 issues

  • General issues

  • Uninstallation issues

For details about known issues with iSCSI Software Target 3.3 compliance with industry standards, see the Microsoft iSCSI Software Target 3.3 Implementation Notes.

Update 1 issue

The Microsoft iSCSI Software Target Windows PowerShell cmdlet for setting a CHAP or reverse-CHAP password does not set the value correctly.

The Set-IscsiServerTarget Windows PowerShell cmdlet does not correctly set the value for the CHAP and reverse CHAP password, regardless of the password specified by the user. There is no indication to the user that the specified password was not set properly, other than that CHAP-enabled connections are not accepted.

As a workaround, set the password by using the iSCSI Target MMC snap-in or by using WMI to set the value.

Important

This update contains the complete Microsoft iSCSI Software Target MSI package and is not a patch. This update should be installed by OEMs in Windows Storage Server 2008 R2 factory images or distributed to, or installed by, end users that already have the Microsoft iSCSI Software Target 3.3 installed.

Update 2 issues

Increases the maximum number of concurrent sessions for a single iSCSI target to 140 sessions.

The Microsoft iSCSI Software Target Windows PowerShell cannot display error strings in the following languages: Simplified Chinese, Traditional Chinese, and Brazilian Portuguese.

For these languages, the resource files are not placed in the correct folders during installation, causing the localized strings to not be loaded.

There is no workaround for this issue.

The HPC provider cannot load any resource strings, which prevents the user from getting meaningful error messages from Microsoft iSCSI Software Target when using the HPC Cluster Manager.

The resource files are referenced incorrectly by Microsoft iSCSI Software Target, resulting in any error message reported by the Microsoft iSCSI Software Target not displaying to the user. This issue occurs for all languages, including English.

There is no workaround for this issue.

Important

This update contains the complete Microsoft iSCSI Software Target Windows Installer package and is not a patch. This update should be installed by OEMs in Windows Storage Server 2008 R2 factory images or distributed to, or installed by, end users that already have the Microsoft iSCSI Software Target 3.3 installed.

General issues

These notes apply to administrators of Microsoft iSCSI Software Target 3.3.

  • You cannot set the minimum storage size value on the Snapshot Storage tab of the iSCSI MMC snap-in to a value less than 320 MB.

    Users cannot set the minimum storage size to 320 MB or less, even though the user interface indicates that 300 MB is an acceptable value.

    To work around this issue, set the minimum storage size to a value greater than 320 MB.

  • Hyper-V host backup is not supported.

    You may encounter an error if you run Hyper-V host backup, as this is not supported with the current released version of the VSS hardware provider. For application consistent backup, take a snapshot within the VM guest.

  • The maximum supported size of a parent VHD is approximately 1.99 TB.

    The maximum supported size of a parent virtual hard disk (VHD) when used with a differencing VHD is calculated at 2 TB minus 517 MB (roughly 1.99 TB). This is because of the metadata storage requirements.

  • A firewall message error appears when you install the client on a computer running Windows Server 2003 with SP2.

    The VDS and VSS providers show the following warning when you install the Microsoft iSCSI Software Target client on Windows Server® 2003 SP2:

    Creating firewall rules failed with error code:-2147221164. Setup will continue and please follow Help file to configure firewall rules.

    The Microsoft iSCSI Software Target client will install successfully, but it will not work correctly until you have configured your firewall rules.

    To resolve this issue, see the documentation for your operating system for information about configuring the firewall.

  • iSCSI Target resource is dependent on the physical disk resource type in a cluster configuration.

    In a clustering configuration, where the iSCSI Target is running as a clustered resource on Microsoft failover clusters, the iSCSI Target resource has dependency on Physical Disk, IP Address, IPv6 Address, and Network Name resources. Other resource types will continue to be supported by the iSCSI Target service.

  • The new cluster name does not appear after you rename a failover cluster.

    If you rename a failover cluster after installing Microsoft iSCSI Software Target, you must stop and restart the Microsoft iSCSI Software Target service before the new cluster name will be displayed by the Microsoft iSCSI Software Target console.

  • Unexpected results occur if you try to rename resources outside of the Microsoft iSCSI Software Target console.

    If you rename an iSCSI resource with another tool after it is created, unexpected results may occur. Different naming rules may apply that can lead to issues for Microsoft iSCSI Software Target. For example, the Failover Cluster Management tool permits a resource name to contain a space, whereas Microsoft iSCSI Software Target does not.

    To resolve this issue, if an iSCSI resource has been renamed, delete the resource, stop the Microsoft iSCSI Software Target service, and then restart the service and recreate the resource.

  • After enabling IPsec, communication failures can occur during failover.

    If you enable IPsec on connections from iSCSI initiators to a failover cluster running Microsoft iSCSI Software Target, you should increase the Microsoft iSCSI initiator timeout value. Increasing the timeout value will prevent communication failures when a failover node goes offline and the operation in progress is transferred to another node of the failover cluster.

    To work around this issue, increase the following registry value to 90:

    HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}\<Instance Number>\Parameters

    The values that can be modified are:

    • MaxRequestHoldTime: Increase this value to 90 if MPIO is not installed.

    • LinkDownTime: Increase this value to 90 if MPIO is installed.

  • Removing a shared disk from a resource group may not automatically force virtual disks offline.

    If you remove a disk from a resource group in the Failover Cluster Management tool and move the disk to another resource group, any virtual disks that are hosted on that disk may not be automatically forced offline during the move.

    To work around this issue, you can delete the virtual disks before moving the disk to a new resource group, or you can use the Failover Cluster Management tool to move the virtual disks to the same destination resource group as the hosting disk.

  • Uninstalling Microsoft iSCSI Software Target from a failover cluster may take a long time.

    When you attempt to uninstall Microsoft iSCSI Software Target from the last node of a failover cluster that is currently hosting virtual disk resources in a pending or failed state, the uninstallation may take an unusually long time to complete.

    To resolve this issue, delete the resource groups from the Microsoft iSCSI Software Target console prior to uninstalling the software on the last node of the failover cluster. If the resource groups are not deleted, you must wait for the uninstallation process to complete.

  • Functionality does not restore in the failover cluster when you uninstall Microsoft iSCSI Software Target on a failover cluster node.

    If you uninstall Microsoft iSCSI Software Target from one node of the failover cluster, and then choose to reinstall the snap-in, the Microsoft iSCSI Software Target service can fail to start.

    To resolve this issue, you must uninstall the snap-in, restart the storage appliance, and then reinstall Microsoft iSCSI Software Target on every node of the failover cluster to restore functionality.

  • The Microsoft iSCSI Software Target console does not update when you create a failover cluster.

    If you have the Microsoft iSCSI Software Target console open when you create a failover cluster, the wizards in the console will not display cluster resources.

    To resolve this issue, you must close the Microsoft iSCSI Software Target console and then open it after the cluster has been created to enable the wizards to display the failover cluster resources.

  • Disabling a virtual disk during a rollback terminates the rollback without warning.

    If you disable a virtual disk while performing a rollback operation, the rollback will be silently ended. An event is logged documenting that the rollback was ended.

    There is currently no work around for this issue.

  • Rollback operations on a locally mounted virtual disk may take a long time to complete.

    When you mount a virtual disk locally in read/write mode, any rollback operation performed on that virtual disk will take a long time to complete.

    There is currently no work around for this issue.

  • Locally mounted virtual disks cannot be selected when creating a new virtual disk.

    When you create a new virtual disk, locally mounted virtual disks are displayed in the list of available volumes to host the new virtual disk. However, using a locally mounted virtual disk to store a virtual disk is unsupported, and the Import Virtual Disk Wizard cannot import virtual disks if one or more of the files present on the disk are in use. If you attempt to select the locally mounted virtual disk as the storage location for the new virtual disk, you will receive the following error message:

    The Import Virtual Disk Wizard cannot import one or more virtual disks.

    To resolve this issue, close any opened files, and then run the wizard again.

  • Managing Microsoft iSCSI Software Target while moving a resource group causes instability.

    When you perform operations on a remote Microsoft iSCSI Software Target resource group in Failover Cluster Management, you will see the status of the resource group change to Pending. If you attempt to run another operation while the resource group is pending, you may get unpredictable results.

    There is currently no work around for this issue.

  • The storage appliance stops responding when you make shadow copies of local-mounted volumes.

    When you locally mount a virtual disk, and then try to make a shadow copy of that volume (for example, by using Windows® Explorer), the storage appliance may appear to stop responding. When you create a shadow copy of a locally mounted virtual disk, the local mount driver writes to the volume that hosts the virtual disk. This causes an additional copy on the differencing area of the host volume. The result is a circular series that eventually causes the storage appliance to stop responding.

    To resolve this issue, restart the storage appliance.

  • Configuration issues occur when adding a storage appliance to a failover cluster after uninstalling Microsoft ISCSI Software Target.

    If you have Microsoft iSCSI Software Target installed on a failover cluster, and you destroy that failover cluster, configuration issues will occur. This issue also occurs when a storage appliance is removed from a failover cluster before it is added to a different failover cluster, or when Microsoft iSCSI Software Target is uninstalled on a cluster node (even when the node does not own the resources).

    To resolve this issue, you must uninstall Microsoft iSCSI Software Target, restart the storage appliance, create the new failover cluster or join a node to the failover cluster and then reinstall Microsoft iSCSI Software Target. This forces Microsoft iSCSI Software Target to remove its configuration for the previous failover cluster, and prepares it to recognize the new failover cluster configuration.

    However, to upgrade from a previous version of Microsoft iSCSI Software Target on a cluster node, do not uninstall the previous version. Instead, install Microsoft iSCSI Software Target 3.3 directly on each cluster node.

Note

If you installed Microsoft iSCSI Software Target on a storage appliance before configuring the Failover Clustering feature, or after removing and rejoining a storage appliance to a cluster, configuration settings used to identify logical unit numbers (LUNs) may be not be identical across all nodes in the cluster. Review the VendorSpecificIDLow, VendorSpecificIDHigh (and, if explicitly set, VendorID, ProductID, and ProductRevision) registry values in the HKLM\SOFTWARE\Microsoft\iSCSI Target key to ensure that these values are identical across all nodes in the cluster.

  • The Microsoft iSCSI Software Target console displays an incorrect location for snapshot storage.

    If you have not explicitly set a location for snapshot storage for a volume, the Microsoft iSCSI Software Target console may display the incorrect location. When the location is not explicitly defined, or if the setting has been deleted, the Volume Shadow Copy Service will implicitly set the location to an available volume that might not be appropriate for your configuration, such as a volume that is not part of the same storage group.

    To avoid this issue, you should explicitly define the location of the snapshot storage for the volume. This can be done in the Microsoft iSCSI Software Target console (in Windows Explorer, click Volume Properties), or you can type Vssadmin.exe at a command prompt.

  • Unpredictable results occur when you remove snapshots.

    Using utilities such as Vssadmin.exe or Vshadow.exe to delete a snapshot that was created with Microsoft iSCSI Software Target may cause unpredictable results.

    To resolve this issue, always use the Microsoft iSCSI Software Target console to remove snapshots.

  • Cluster nodes may not be available after failover.

    When the operating systems for the nodes of a cluster are not on the same partition, the nodes are not available after failover.

    To resolve this issue, install the Windows Storage Server 2008 R2 operating system on the same partition on each node, typically the C drive.

  • Snapshot status value is delayed.

    When you locally mount a snapshot, the snapshot status value in the WMI class WT_Snapshot instance and the Status property does not immediately receive the DVMounted status when the DVMount method returns.

    To resolve this issue, wait briefly and the status should resolve.

  • Error messages appear when you attempt to uninstall then reinstall Microsoft iSCSI Software Target.

    You may encounter errors in Event Viewer when attempting to uninstall Microsoft iSCSI Software Target 3.2 and subsequently reinstalling.

    To resolve this issue, stop the Microsoft iSCSI Software Target service prior to uninstalling the software. If the software has already been uninstalled, you should restart the computer prior to reinstalling Microsoft iSCSI Software Target.

  • Attempting to manage a client running Microsoft iSCSI Software Target 3.3 from a client running Microsoft iSCSI Software Target 3.2 will fail.

    You cannot use the Microsoft iSCSI Software Target 3.2 snap-in to remotely manage network-attached storage appliances that are configured with Microsoft iSCSI Software Target 3.3. However, you can use the Microsoft iSCSI 3.3 Target snap-in to remotely manage network-attached storage appliances that have been configured with the iSCSI Software Target 3.2.

  • A resource group may not be not visible if a cluster is created after Microsoft iSCSI Software Target is installed.

    The Microsoft Management Console (MMC) does not receive updates when the status of a cluster is changed. This means that if a new cluster is created on a storage appliance (for example, changing a single node cluster to a two-node cluster), a user may not be able to associate new cluster nodes with pre-existing clusters.

    To work around this issue, customers should create the desired cluster configuration first, and then create the desired iSCSI target(s). However, if the cluster already exists, a customer must exit the MMC (in this case, Server Manager) or close the ICT window, and then initialize the MMC or the ICT window.

  • Adding an iSNS entry will fail if the resource is invalid or cannot be reached.

    If you attempt to add an Internet Storage Name Service (iSNS) entry, the process will fail if one or more existing iSNS entries are invalid or cannot be reached. This occurs because the process validates all current iSNS entries before adding a new iSNS entry, and it only permits additions after current iSNS entries have been discovered.

    This behavior can impact the cluster setup process because of the way that iSNS entries are replicated on all cluster nodes. For example, if a resource group owns an iSNS entry for an IP resource (for example, a resource on a different network), that iSNS entry is valid and discoverable for that resource group only. Replication of iSNS entries to clusters nodes that do not own that resource group are not discoverable, and updates to iSNS entries on those clusters will fail.

  • Uninstalling Microsoft iSCSI Software Target deletes resources.

    Deleting VHD resources should be treated differently based on whether the node is the first node of a cluster or the last node of a cluster. However, the logic to detect the last node of a cluster fails, so when Microsoft iSCSI Software Target is removed from a cluster, it removes the VHD and target resources for all nodes, not just the last node.

    To work around this issue, users should evict the node from the cluster before uninstalling Microsoft iSCSI Software Target. This ensures that associated VHDs remain accessible after the snap-in has been uninstalled.

  • The Microsoft iSCSI initiator cannot create a snapshot (or complete similar actions) when the cluster is attached to more than one network.

    If a cluster is attached to more than one network during setup or configuration, the Cluster Name and Domain Join Wizard or Failover Cluster Manager may not associate the cluster name with the same network as the Microsoft iSCSI initiator(s). If this occurs, the VSS provider on the Microsoft iSCSI initiator(s) will not be able to connect to the cluster or perform operations on the Microsoft iSCSI Software Target.

    To resolve this issue, the cluster name must be reset so that it is associated with the same domain as the initiator(s). This can be done using the Cluster Administrator MMC.

  • Cannot use the local mount feature on Microsoft iSCSI Software Target to mount a snapshot of a dynamic disk on the iSCSI initiator.

    If a LUN on the iSCSI initiator is exposed as a dynamic disk, you cannot use the local mount feature on Microsoft iSCSI Software Target to mount a snapshot of the disk.

    To work around this issue, create the LUNs basic disks on the iSCSI initiator, or if dynamic disks are required, create the snapshot directly from the iSCSI initiator, and then manage the snapshot from the ISCSI initiator.

  • Previous data is accessible after creating a new VHD.

    When you create a new VHD, the Wintarget service does not delete the data that will comprise the VHD. This is by design, because writing zeros to each sector of the disk takes time, especially for large VHDs. However, unless these sectors are deleted before a new VHD is created, any application on the iSCSI initiator that supports raw block IO on an iSCSI LUN will be able to read the contents of the VHD.

    To resolve this issue, use the DiskPart tool, or the Disk Management snap-in (diskmgmt.msc) to create the VHD. By default, these tools overwrite the disk sectors during the VHD creation process.

  • Rolling back a VHD creates a corrupted file.

    During the creation of a VHD file, a corresponding change bitmap (CBM) file is created. When creating a snapshot of a VHD, the CBM is used to track the changes to the VHD file since the last snapshot, which allows fast rollback of the VHD. By default, updates to the CBM are made asynchronously and the CBM file may not accurately reflect the content of the snapshot in the event of an unintended system shutdown. In this case, attempting to rollback a VHD to the snapshot by using the corrupted CBM file may cause corruption in the resulting VHD file.

    To resolve this issue, users who want to ensure consistency between the snapshot and the CBM can enable synchronous writes to the CBM by setting the following value of the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\iSCSI Target registry key:

    Name Type Description

    FlushCbmWriteCache

    REG_DWORD

    Set this value to 1 to enable synchronous writes to the CBM. In a default installation, this registry value is not present in Microsoft iSCSI Software Target. To disable synchronous writes to the CBM, edit or delete this value (any value other than 1 disables this feature) or delete the registry key.

Note

If you add this registry key to Microsoft iSCSI Software Target, you must restart the service (located at c:\windows\system32\wintarget.exe) to enable the change. Adding this registry value can degrade performance of Microsoft ISCSI Software Target by up to 20% because of the inline flush. However, this registry value will not affect performance if you do not create snapshots of your VHD, or if you delete all VHD snapshots (which can be done after transferring the snapshot to portable media).

Uninstallation issues

If you uninstall the iSCSI Software Target 3.3 (iscsitarget.msi) on a storage appliance, the following files remain:

  • Driver-store files:

    • %systemroot%\system32\DRIVERS\wtlmdrv.sys

    • %systemroot%\System32\catroot\{F750E6C3-38EE-11D1- 85E5-00C04FC295EE}\<oem_driver_name.cat>

    • %systemroot%\System32\DriverStore\FileRepository\wtlmdrv.inf_amd64_neutral_1db10667c354ceca

    • %systemroot%\System32\DriverStore\FileRepository\wtlmdrv.inf_amd64_neutral_1db10667c354ceca\wtlmdrv.pnf

  • WmiApRpl—iSCSI initiator triggered files:

    • %systemroot%\System32\wbem\Performance\WmiApRpl_new.h

    • %systemroot%\System32\wbem \Performance\WmiApRpl_new.ini

    • %systemroot%\inf\ WmiApRpl\WmiApRpl.h

    • One of the following directories (depending on the language that is installed on Microsoft iSCSI Software Target):

      • %systemroot%\inf\WmiApRpl\0022 - if the operating system language of the server is Portuguese (Brazil).

      • %systemroot%\inf\WmiApRpl\0004 - if the operating system language of the server is Chinese (Chinese – simplified).

      • %systemroot%\inf\WmiApRpl\3076 - if the operating system language of the server is Chinese (Chinese- traditional).

      • %systemroot%\inf\WmiApRpl\0009 – if the operating system language of the server is English.

      • %systemroot%\inf\WmiApRpl\0012 – if the operating system language of the server is French.

      • %systemroot%\inf\WmiApRpl\0007 – if the operating system language of the server is German.

      • %systemroot%\inf\WmiApRpl\0016 – if the operating system language of the server is Italian.

      • %systemroot%\inf\WmiApRpl\0017 – if the operating system language of the server is Japanese

      • %systemroot%\inf\WmiApRpl\0018 – if the operating system language of the server is Korean

      • %systemroot%\inf\WmiApRpl\0025 – if the operating system language of the server is Russian.

      • %systemroot%\inf\WmiApRpl\0010 – if the operating system language of the server is Spanish.

    • One of the following files (depending on the language that is installed on the Microsoft iSCSI Software Target server):

      • %systemroot%\inf\WmiApRpl\0022\WmiApRpl.ini (Portuguese [Brazil] version)

      • %systemroot%\inf\WmiApRpl\0004\WmiApRpl.ini (Chinese simplified language version).

      • %systemroot%\inf\WmiApRpl\3076\WmiApRpl.ini (Chinese- traditional language version).

      • %systemroot%\inf\WmiApRpl\0009\WmiApRpl.ini (English language version).

      • %systemroot%\inf\WmiApRpl\0012\WmiApRpl.ini (French language version).

      • %systemroot%\inf\WmiApRpl\0007\WmiApRpl.ini (German language version).

      • %systemroot%\inf\WmiApRpl\0016\WmiApRpl.ini (Italian language version).

      • %systemroot%\inf\WmiApRpl\0017\WmiApRpl.ini (Japanese language version)

      • %systemroot%\inf\WmiApRpl\0018\WmiApRpl.ini (Korean language version)

      • %systemroot%\inf\WmiApRpl\0025\WmiApRpl.ini (Russian language version).

      • %systemroot%\inf\WmiApRpl\0010\WmiApRpl.ini (Spanish language version).

  • Autorecovery Managed Object Format (MOF) files

    • %systemroot%\System32\wbem\AutoRecover\ 4B6E2467F5D89AFB471302783CE475FF.mof

    • %systemroot%\System32\wbem\AutoRecover\57B9C1E2AF0C6D3AE535812ACFC0F99B.mof

    • %systemroot%\System32\wbem\AutoRecover\ A5F1E13CEC47799EB3FABF55D73CEE5A.mof

  • OEM Setup Information (INF) and Precompiled Setup Information (PNF) files:

    • %systemroot%\inf\<oem_driver_name>.inf

    • %systemroot%\inf\<oem_driver_name>.pnf

If you uninstall Microsoft iSCSI Software Target Client 3.3 (iscsitargetClient.msi) on a client, the following files remain:

  • %systemroot%\System32\wbem\Performance\WmiApRpl_new.h

  • %systemroot%\System32\wbem \Performance\WmiApRpl_new.ini

  • %systemroot%\inf\ WmiApRpl\WmiApRpl.h

  • One of the following directories (depending on the language that is installed on the client):

    • %systemroot%\inf\WmiApRpl\0022 - if the operating system language of the client is Portuguese (Brazil).

    • %systemroot%\inf\WmiApRpl\0004 - if the operating system language of the client is Chinese (Chinese – simplified).

    • %systemroot%\inf\WmiApRpl\3076 - if the operating system language of the client is Chinese (Chinese- traditional).

    • %systemroot%\inf\WmiApRpl\0009 – if the operating system language of the client is English.

    • %systemroot%\inf\WmiApRpl\0012 – if the operating system language of the client is French.

    • %systemroot%\inf\WmiApRpl\0007 – if the operating system language of the client is German.

    • %systemroot%\inf\WmiApRpl\0016 – if the operating system language of the client is Italian.

    • %systemroot%\inf\WmiApRpl\0017 – if the operating system language of the client is Japanese

    • %systemroot%\inf\WmiApRpl\0018 – if the operating system language of the client is Korean

    • %systemroot%\inf\WmiApRpl\0025 – if the operating system language of the client is Russian.

    • %systemroot%\inf\WmiApRpl\0010 – if the operating system language of the client is Spanish.

  • One of the following files (depending on the language that is installed on the client):

    • %systemroot%\inf\WmiApRpl\0022\WmiApRpl.ini (Portuguese [Brazil] version).

    • %systemroot%\inf\WmiApRpl\0004\WmiApRpl.ini (Chinese simplified language version).

    • %systemroot%\inf\WmiApRpl\3076\WmiApRpl.ini (Chinese- traditional language version).

    • %systemroot%\inf\WmiApRpl\0009\WmiApRpl.ini (English language version).

    • %systemroot%\inf\WmiApRpl\0012\WmiApRpl.ini (French language version).

    • %systemroot%\inf\WmiApRpl\0007\WmiApRpl.ini (German language version).

    • %systemroot%\inf\WmiApRpl\0016\WmiApRpl.ini (Italian language version).

    • %systemroot%\inf\WmiApRpl\0017\WmiApRpl.ini (Japanese language version)

    • %systemroot%\inf\WmiApRpl\0018\WmiApRpl.ini (Korean language version)

    • %systemroot%\inf\WmiApRpl\0025\WmiApRpl.ini (Russian language version).

    • %systemroot%\inf\WmiApRpl\0010\WmiApRpl.ini (Spanish language version).