Information Tech

the reality of working in IT for the last decade

Careers

take charge of your career, before someone else does

Management

the realities and joys of being in management

Blogging

a fun project that turned into a hobby sometimes

Life & Times

we all get one shot at it, better make it count

Home » Information Tech

Solved. . . The end of an iSCSI irritation

Submitted by on June 10, 2009 6 Comments
296055_waiter

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

2) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}
MaxRequestHoldTime  REG_DWORD 120

3) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk
TimeOutValue REG_DWORD 60

4) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
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 Comments

Leave a comment!

Add your comment below, or trackback from your own site. You can also Comments Feed via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

CommentLuv badge

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.

*