?
Solved

When mapping drives, intermittent 'The Specified Network Name is No Longer Available' messages displayed

Posted on 2006-10-24
8
Medium Priority
?
1,393 Views
Last Modified: 2013-12-23
I have several servers all set up with Cygwin scripts to mount a network-attached storage device and then run NTBackup.  This works fine accross the board with a couple of exceptions.  One server refuses to backup as it loses the mapped drive, presumably when I log off, but the script does not reconnect the drive.  This procedure is in place and working for many other servers, including two on the same subnet as the faulting server, as the NAS is on a seperate backbone subnet.

This is driving me mad, I can find no explanation as to why this may happen.  I have tried:
Checking FW logs for large volume of network traffic - not consistent with fault timing
Using command line to make mapped drive persistant - not helped
Deleted and reconnected mapped drive several times

I realise many people frown upon NTBackup, my thoughts are that it is good for what we require.  It is the rest of the operating system that is messing things up!

What would be great is some sort of command line diagnostics relating to what network shares the machine has cached, if available?

Any suggestions are much appreciated, thanks for the help
0
Comment
Question by:slands10
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
8 Comments
 
LVL 7

Expert Comment

by:CharliePete00
ID: 17797899
I'd try the following:

1.  Write a script that
        a.  Maps your drive
        b.  Backs up to the mapped drive
        c.  Disconnects the mapped drive
2.  Create a scheduled task that will execute the script under an account with appropriate permissions

Or try backing up directly to a share via UNC (\\Sever\Share\BackupFile.bkf) instead of a mapped drive (z:\BackupFile.bkf)

0
 

Author Comment

by:slands10
ID: 17801834
Hi CharliePete,
That is the very thing I have done, I am using Cygwin to mount the drive, execute NTBackup, and the dismount the drive.  For doing this, I am using the full UNC convention (\\server.domain.com\drive).  A scheduled task is then used to execute a batch file which calls the Cygwin script.
What may confuse the issue slightly is that the target server is a NAS terabyte drive, which is working fine with every other backup scheduled.  This means I have very few options to configure on the target server, so most of the configuration must be done on the server that is to get backed up.  Access to the NAS is through shared folders, the one in question is named \backups, and so my UNC looks like \\nas01.xx.xx-xx.com\backups.  This works on every attempt *except* when the scheduling task is executing, or very occasionally when trying to mount the drive manually.
I have been thoroughly researching this as I am almost at my wit's end.  A Possible reason I have for the particular message ("The Specified Network Name is No Longer Available") is heavy network traffic, but on my network this should not be an issue at the time the script is executing.

Is there anyway to interrogate Windows 2K to see what mapped drives are in cache or such like?

Again, thanks for the help, I shall increase points for this q if that is more of an incentive to help out a poor, stressed individual!
0
 
LVL 31

Expert Comment

by:Gareth Gudger
ID: 17804915
I wonder if it is a logon issue. Try resetting your credentials on the NTBackup job?
0
Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

 

Author Comment

by:slands10
ID: 17804971
Hey, thanks, I'll give it a go, won't hurt.  We did notice that our NAS was configured with the wrong subnet, 255.255.255.0 rather than 255.255.240.0.  This didn't seam to affect most of the servers that were contacting the NAS to perform a scheduled backup, but it could have been some routing issue when most servers could find the NAS, but a few were unable to.
I'm still looking for suggestions, but I'm away for the night so hopefully tommorow I'll come in and we'll have a full round of backups completed without problem!

Thanks again for the input
0
 
LVL 7

Accepted Solution

by:
CharliePete00 earned 1500 total points
ID: 17806356
Now that we've eliminated some of the most obvious it looks like its time to roll up our sleaves and get to work ;-)

Let's start with the following:

1.  Start auditing authentication (logon) failures on the problem server
2.  Examine the event logs on the problem machine for errors corresponding with the times the backup job is attempted
3.  Logon to the problem machine with the same credentials (username, password) used to execute the backup job and attempt to execute the script manually.
4.  Replace references to the servername in UNCs in your script with IP addresses then attempt to execute the script manually and as a scheduled task
5.  Use a service wrapper (like Firedaemon) to execute your script as a service

Be sure to note and report any errors so we can help you resolve this
0
 

Author Comment

by:slands10
ID: 17810301
Hi again CharliePete,
Sorry, I'm really busy with a failed proxy server just now, but this looks to me as a plausible solution, I will give this a go and report back.  
5.  Use a service wrapper (like Firedaemon) to execute your script as a service

I am fairly confident the other suggestions do not apply to this situation or have been tried already, but I will still run through them.  Thanks again for the input
0
 

Author Comment

by:slands10
ID: 17813186
I'm really really sorry guys, I am a FUD.

I had my cygwin backup script looking in the wrong place for logfiles, so I was reporting failed every night.  I checked and we have a complete library of backups for this particular server.  Doh!

Again, really sorry for leading you all down a path to nowhere!

CharliePete, I award you points for your persistent help, many thanks.

Hope we have all learnt at least something from this experience...

Thanks again :-)
0
 
LVL 7

Expert Comment

by:CharliePete00
ID: 17826087
Been there!

Hope you've your proxy taken care of.

Again, Good Luck!
0

Featured Post

[Webinar] Lessons on Recovering from Petya

Skyport is working hard to help customers recover from recent attacks, like the Petya worm. This work has brought to light some important lessons. New malware attacks like this can take down your entire environment. Learn from others mistakes on how to prevent Petya like worms.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Have you ever set up your wireless router at home or in the office to find that you little pop-up bubble in the bottom right-hand corner of Windows read "IP Conflict - One of more computers on the network have been assigned the following IP address"…
Greetings, Experts! First let me state that this website is top notch. I thoroughly enjoy the community that is shared here; those seeking help and those willing to sacrifice their time to help. It is fantastic. I am writing this article at th…
Michael from AdRem Software explains how to view the most utilized and worst performing nodes in your network, by accessing the Top Charts view in NetCrunch network monitor (https://www.adremsoft.com/). Top Charts is a view in which you can set seve…
In this video, Percona Solutions Engineer Barrett Chambers discusses some of the basic syntax differences between MySQL and MongoDB. To learn more check out our webinar on MongoDB administration for MySQL DBA: https://www.percona.com/resources/we…

650 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question