Solved. . . The end of an iSCSI irritation
We had an issue with our SAN and a couple of Windows servers. When these servers were rebooted from a script, we would lose the network shares that were homed on the SAN volume. The volumes (drives) were mounted correctly; it was just the network shares that were gone. This was bugging the heck out of us for several weeks, and I am so pleased we finally have a solution. A few darn registry entries and a lot of back-and-forth effort was all it took…
A big “thank you” to Robb who worked diligently on the problem with Microsoft.
The Problem: The network shares were lost (disappeared) on volumes that were hosted on the SAN, but only when the host server (Windows 2003 in our case) was rebooted via a script. It happened every time when the server was rebooted from a script, but only rarely happen when the server rebooted via the console. So each time we rebooted the server from a script we would have to go back and recreate the network shares.
Our Solution: We made sure that we were using the latest version of the Microsoft iSCSI Software Initiator, and configured it correctly per the Microsoft documentation. We completed the steps in setting the iSCSI dependency and bound volumes (MS Knowledge Base: File shares on iSCSI devices may not be re-created when you restart the computer). The rest came from working with our friends at Microsoft Technical Support over several weeks.
Open Registry Editor
Disclaimer: This worked for us in our particular situation, and it should not be completed by anyone without an understanding of the impact of these changes. This may not help you in your situation, and it could even make your problem worse, so use this information as a discussion topic with your SAN vendor or Microsoft. It is highly recommended that you consult with your vendor and Microsoft before making changes to your registry. You should always backup up your entire server before making any modification – as well as making an extra local backup of your registry – just in case you OS is damaged or rendered inoperable. Remember Andy Grove’s book, Only the Paranoid Survive.
This is for Windows 2003 server and I have no idea if it applies to any other version or release of Windows.
Navigate to the following registry sub-keys and create the following DECIMAL values if not already present:
1) HKLM\Software\Microsoft\Windows NT\CurrentVersion\ISCSI\Discovery
VolumeRetryCount REG_DWORD 160
VolumeRetryTimer REG_DWORD 1100
MaxRequestHoldTime REG_DWORD 120
TimeOutValue REG_DWORD 60
ServicesPipeTimeout REG_DWORD 60000
We rebooted via script and console several times and hoped for the best! It worked like a charm for us, and we have had zero issues with network shares disappearing after a manual or scripted reboot.
Best of luck to you, and if you find a different solution, please leave a comment with some information!
6 thoughts on “Solved. . . The end of an iSCSI irritation”
According to this MSDN blog:
the second change in the registry should be done not for all SCSI drivers, but specifically for iSCSI initiator:
In my case the is 0001.
Default value for MaxRequestHoldTime is 60 seconds.
Thank you for updating! I greatly appreciate sharing the information.
well it fixed my problem
Go to iscsi initaitor
Select bound volumes and bind the volumes which the shares are on.
Make the lanman service dependent on iscsi service
Thanks for the information. We started with those steps, and they are included in the knowledge base article that I linked in my post. However, it had no effect in our situation. As a mater of fact, it was the first time that I have ever run into this type of problem where the steps in the Microsoft support article and in your comment did not correct ans iSCSI problem.
Thanks for the useful info. It’s so interesting
Comments are closed.