Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

iSCSI Favorite Targets may need to be re-created if there is a network configuration change on the initiator system


View products that this article applies to.

Source: Microsoft Support

↑ Back to the top


Rapid publishing

RAPID PUBLISHING ARTICLES PROVIDE INFORMATION DIRECTLY FROM WITHIN THE MICROSOFT SUPPORT ORGANIZATION. THE INFORMATION CONTAINED HEREIN IS CREATED IN RESPONSE TO EMERGING OR UNIQUE TOPICS, OR IS INTENDED SUPPLEMENT OTHER KNOWLEDGE BASE INFORMATION.

↑ Back to the top


Symptom

Consider the following scenario.� You have set up a Favorite Target connection to an iSCSI Target using the Microsoft iSCSI Initiator.� You make a network configuration change on the initiator system, and restart the system.� Once the system has started, you may notice that the LUNs presented by the iSCSI Target are inaccessible.� Also, under the Targets tab in the iSCSI Initiator User Interface, you may notice that the Favorite Target is stuck in a "Reconnecting..." state.

↑ Back to the top


Cause

When a network configuration change is made on the initiator system, the iSCSI Favorite Target data in the registry may become stale.� Because of this, the iSCSI Initiator is unable to connect to the iSCSI Target.

↑ Back to the top


Resolution

If you are experiencing the behavior described in the Symptoms section after making a network configuration change on the initiator system, remove and re-create the Favorite Target connection.� This will update the Favorite Target configuration information in the registry to reflect the new network configuration.

↑ Back to the top


More information



One specific scenario where this behavior can be seen is when a Favorite Target is created with both the IPv4 protocol and the IPv6 protocol bound to the iSCSI network interface(s), then the IPv4 procotol is later un-bound from the iSCSI interface(s), and the system is restarted.

IPv6 addresses end in a Scope ID, which is located after the percent sign at the end of the IPv6 address.� For example, in the following IPv6 address, the Scope ID is 2:

fe80:1234:5678:9abc:def1:2345:6789:abcd%2

On Windows Server 2008, Windows Server 2003, �Windows Vista, and Windows XP systems, the Scope ID for local IPv6 addresses is based on the network interface index, which can be seen using the 'netsh interface ipv6 show interface' command.

In the above scenario, when IPv4 is un-bound from the iSCSI interface(s) and the system is rebooted, the Scope ID of the local IPv6 address(es) changes.� This causes the Scope ID configured in the registry for the Favorite Target to become stale, and thus the initiator cannot determine which local interface to use to create the connection to the iSCSI Target.

↑ Back to the top


Disclaimer

MICROSOFT AND/OR ITS SUPPLIERS MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY, RELIABILITY OR ACCURACY OF THE INFORMATION CONTAINED IN THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE (THE �MATERIALS�) FOR ANY PURPOSE. THE MATERIALS MAY INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS AND MAY BE REVISED AT ANY TIME WITHOUT NOTICE.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.

↑ Back to the top


Keywords: kbnomt, kbrapidpub, KB967476

↑ Back to the top

Article Info
Article ID : 967476
Revision : 2
Created on : 2/3/2009
Published on : 2/3/2009
Exists online : False
Views : 377