Force mapped drive reconnect

[steve4king]

Our program requires users to map network locations to drive letters. However, for some users, windows doesn't always appear to fully connect to these network drives until they are browsed manually. As a result, when the program launches, and tries to access files in the m:\ directory, it returns an error that the network directory cannot be found.

Manually browsing the directory beforehand resolves this until the computer is restarted.

Are any of you familiar with this "phenomenon" or know of a way to force the connection?

 

[Olaf Doschke]

Was "reconnect at login" checked when making the connection to M:\ ?

Then this is indicating the windows profiles are whacky, if the network drives are not reconnected.

You would run "net use" to make the drive mapping.

Bye, Olaf.

 

[dgrewe]

In your Statement, you have

However, for some users, windows

What is the difference between the users that do not have the problem and the ones that do have the problem.

Are they in difference groups???
Do they have diofferent connections (VPN,...Etc)???
Are they on Different Hubs/Routers???
Are they on different servers ???



David W. Grewe Dave

 

[JRB-Bldr]

The other 2 above appear to be saying exactly what I would say...

In essence they are saying, if the problem is in the network, don't try to fix it in the application. It likely would not work anyway.

Get the system/network administrator to fix the network so that drives are mapped properly and reliably each time on logon.

Good Luck,
JRB-Bldr

 

[safraser]

Steve
I have to agree with the above post, but I have also been in exactly the same position.
More often than not, when I encounted this problem it was on a very small workgroup network, with 2 maybe 3 compters, 1 acting as both the data server and a workstation.
What I found was that the workstation machines where being turn on before the data server, so the drives where not able to be mapped. I could never educate the users to turn the computers in in the correct order so in the end I started using "Net Use" to create my drive mappings as the software loaded

 

[steve4king]

These are small p2p networks. Usually windows XP pro x86 on all computers.

Yes the connections are persistant, the mapped drives do not go away, and they all seem to work fine in windows. Just not in the application until they are awakened by windows.

None of them are connected across a VPN. The server is always turned on first. Each location with this problem is straight-forward wired TCP/IP connected via a single switch/router. Should all be on the same workgroup. (However I would not expect that to cause any problems.) Sleeping/powerdown of network devices is disabled. I'm not sure what network devices/configurations remain to be changed.

One of my users mentioned he encountered the exact same thing in MS Access, but I cannot speak for that.

This isn't a new problem, and there are quite a few users with this issue. But we have never been able to nail down the cause.



Thanks,
Steve W.

 

[Olaf Doschke]

p2p network. Well, Win XP and other client Windows systems are no server operating systems. Either live with that, eg manually "awake" the network drives, make some workaround or change to a real server. You'll avoid many problems arising of p2p file usage.

Bye, Olaf.

 

[AidanPryde]

Mike Yearwood, I have used batch files to remap the drives on reboot in an attempt to do the same, and it was relatively successful and seemed like a shoddy workaround.

UNC path wasn't really ideal for certain operations.

I wasn't sure whether this could be resolved but.. thanks for the input.

-Steve

 

[GriffMG]

I have seen this effect before, on a pretty sophisticated networks - 'proper' servers, AD that sort of thing.

I *think* Windows sometimes sort of 'times out' mapped connections and there needs to be a bit of 'retry' time to re-establish connections to mapped drives.

I reckon it would be worth testing for the presence of a 'must-have' in the root of the required map - and if it isn't there, wait a couple of second and try again a few times.

If you test for a 'con' in the root of the mapped drive and it isn't there, you could wait a moment and test again:

You could develop a 'driveready' function for you.

(CON always exists in any folder or drive, it is a device, rather than a file.)


Regards

Griff
Keep [Smile]ing

 

[EvDrizzle]

I found out that the connection is a 'sleeping' connection after startup.
It is a windows XP problem and has to do with not supporting DOS programs

My workaround is a Batch file on the desktop which uses START and TASKKILL to open and close a notepad file with the name 'closeme.txt' in a folder on the specific drive.
I use it for a foxpro program.

Put the following line in the batchfile and name it 'connection.cmd', and place a .txt file in a folder on the drive closeme.txt

START X:\openlaptop\closeme.txt & TASKKILL /F /IM notepad.exe & TASKKILL /F /IM word.exe

info about start:

http://technet.microsoft.com/nl-nl/library/bb491005(en-us,TechNet.10).aspx

http://www.robvanderwoude.com/start.html

info about taskkill:

http://technet.microsoft.com/nl-nl/library/bb491009(en-us,TechNet.10).aspx

PS I'm not sure but both programs are XP professional you can put them in the system32 folder of a home version

Did you find something better? let me know...

greetings,
E

 

[baltman]

in error catch:

Run /N Net Use <drive letter>: "\\server\share"

 

[calloatti]

Really late to this party, but these are my notes regarding this problem, for future reference:

How Autodisconnect Works in Windows NT and Windows 2000

http://support.microsoft.com/?scid=kb;en-us;138365&x=11&y=14

Mapped Drive Connection to Network Share May Be Lost

http://support.microsoft.com/?scid=kb;en-us;138365&x=11&y=14

KeepConn

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/58896.mspx?mfr=true

Carlos Alloatti

 

[steve4king]

Microsoft did not do well at documenting that last one as there are multiple entries of the same thing. Some more complete than others. Even the most complete one is written oddly, in that it suggests adding both a keepconn and an autodisconnect Dword value on the workstations. I'm not sure what the difference would be between the two however.

Here is the most complete one I found.

http://support.microsoft.com/kb/297684

I have not run into another user with this problem in order to test again.

 

[calloatti]

Yes, my second link was supposed to be that one, I made a mistake and pasted the first link again, but got the title right.

I never had to try these, just saved the links for future reference.

Carlos