Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Windows File Share keeps getting lost on reboot of server

Created: 15 Jun 2010 • Updated: 13 Dec 2010 | 5 comments
This issue has been solved. See solution.

I wonder if anyone here can assist with this problem.

We have a backup server which uses SFW5.0 which has a FC SAN connected o it.

When we reboot the server it loses its File Share which we use to save all our backups to. The file share is located on a single volume, on an imported disk group.

The volume comes up fine, but the share is always missing when we reboot.

The only thing we can think of is that we had to implement a latestart on the Vertias service because it wasn't importing the disks correctly without this. Our feeling is that it might be to do with Microsoft waiting for the disk volume, when it doesn't see it, it stops trying to share the folder, perhaps because it is coming in so late as a result of the latestart.

Has anyone encountered this or have a workaround to keep the shared folder coming up on reboots?

Nick

Comments 5 CommentsJump to latest comment

Marianne's picture

Suggestion: Download and run the VOS data collector from: https://vos.symantec.com/home
Upload the result for analysis. Any issues with multipathing that can be resolved by updated DMP DDI should be pointed out by reports such as "Risk Assessment" and/or "Installation and Upgrade". Possible compatibility issues will also be highlighted.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Wally_Heim's picture

Hi ncolyer,

You are correct on you assumption.  The Windows server service is responsible for sharing our folders on the server and if it can not see the folder to share during its startup process it does not share out the volume.  After it gives up then your volume comes in.

There are a few things that you can try.

1. Simplify the enviornment - if DMP is involved single path and uninstall DMP.  Then check to see if the share is stil lthere after reboot.  This will reduce the number of devices to be scanned during startup and hopefully point to a rescan time issue.
 

       If this works then you will need to look into DMP related items as to why the disk/volume is arriving late.

2.  If problem still exists with single path, if there are a lot of disks being presented to the server try reducing the numbers to just a few (again this is to reduce the rescan time for the shared disks.)

 

If this helps then try updating HBA drivers/firmware and SFW 5.0 to either 5.0 RP2 or 5.1 SP1.

From there you might want to open a support case with Symantec Technical Support.

Thanks,

Wally

 

anand_study's picture

e.g. in MS Windows

Set service dependency like Something like

C:\ sc config lanmanserver depend= <your SAN SCSI service>
or
C:\ sc config lanmanserver depend= MSISCSIe.g. in MS Windows

 

ncolyer's picture

Thanks for the responses and sorry about the delay in answering this.

We still have the same problem. One of the reasons the volume is probably arriving late is because we had to use the following command:

vxdg -g VRPBackups latestart on

Before this we were having problems where the drive itself wasn't available after the server restarted and we had to keep importing the disk group.

I'm guessing this is why we are having the problem with the late arrival of the share.

I have yet to update Symantec SFW to the latest versions so this still may be a possibility.

Any other recommendations?

Wally_Heim's picture

Hi ncolyer,

 

The laststart option is intended for use is iSCSI environments where the Microsoft iSCSI inititor is used.  It should not be needed for FC SAN configurations.

 

Were you able to simply your environment to a single path with no DMP software installed?  Did the issue go away when this was done?

 

SFW 5.1 SP2 has just been released and it does contain some improvements in our software that can increase performance of volume arrivals.  You might want to test it in your environment to see if it addresses your issue.

 

If you are still having problems, you might also want to consider opening a case with Symantec Technical Support.  We can take a look at your configuration and provide recommendations for your specific situation.

 

Thanks,

Wally

SOLUTION