Mapped drives and "local device name already in use"

[paleogryph]

W2K Pro with a mapped drive. Occasionally when a user tries to save a file to that drive they get:

"An error occured while reconnecting H: to \\server\share
Microsoft Windows Network: the local device name is already in use. This connection has not been restored."

Apparently MS tells people to disable AV to fix this.
There is also "net config server /autodisconnect:-1" or deleting the mapped drives and then rebooting.

Any ideas?


>Think for yourself<
...or someone else will do it for you.

 

[packdragon]

Try mapping the drive to a different letter. You don't have to use the command line to do this. You can map drives and disconnect mapped drives through Windows Explorer.

It's possible that the computer assigned that drive letter to another device or drive, making it unavailable for the mapped drive. Because I have lots of removable devices (like card readers and PDAs) I try to map my drives to somewhere in the middle or the end of the alphabet.

- Zoe, that's ZOH-EEE, get it right please
- Just a little ol' MCP at Solien Technology
-

http://www.solien.com

 

[Philly44]

I have run into that problem in the past when I have had access to shares with the same name ie: I:\Images on Server 1 and G:\Images on Server 2. The only resolution I know of is to change the name of one of the shares. Unfortunatley when it somes to shares like the drive doesn't really matter, windows will automatically pick the next letter in line when it finds a conflict.

 

[cainecabe]

We are having the same problem but the situation is a little different. We are migrating to a new Active Directory 2003 domain from an NT4 domain. Most of our our clients are Windows 200Pro, a few XPpro. All users have a mapping to H that points to \\server\username. Almost everyone has been migrated to the AD domain. Problem is, once the users are migrated, a little more then a few people have stated that they get the same error as mentioned above (Windows Network: the local device name is already in use. This connection has not been restored.)
but the files do save. So, it seems that AD is causing this but I can't see why.
There has to be a reason for this but why I don't know. I have heard that the AutoDisconnect feature on server witht he shares may fix it but, if that was the case it would ghave occurred before they were migrated from the NT4 domain to the AD domain.
Anyone with info? this is killing me.

Thanks,

 

[bcastner]

In the logon script begin any predefined mapping assignments with the following:

net use * /delete >nul
net use /persistent:no
net use f: \\server_name\share_name /persistent:no

The key elements are:
. to clear any persistent mappings from previous sessions with line 1
. set the default value for persistence to no; line 2
. to indicate that your default mappings are non-persistent (unecessary but I do it anyway)

While it is true that NT Server and Win2k server treat autodisconnect the same way, Win2k/XP client has by default persistent:yes on any share unless reset as in line 2 above, or by share as in line 3 above.

 

[bcastner]

My script flows better if you do automatic prompt answering:

net use * /delete /Y >nul
net use /persistent:no
net use f: \\server_name\share_name /persistent:no

 

[cainecabe]

I guess there is one other thing i need to mention. A number of the users (those with laptops) need persistent mapping to the home share (h:\\server\username) because they use offline files and if the H isn ot present when offline, they will not have access to it.
Is it possible that some GPO is causing this? I mean before AD it never occurred anywhere, i'm stumped.

Thanks,

 

[bcastner]

A number of the users (those with laptops) need persistent mapping to the home share (h:\\server\username) because they use offline files and if the H isn ot present when offline, they will not have access to it."

Could you explain this better? If you are offline you have no access to the share. The persistence value controls whether the share is auto created at logon between sessions and controls nothing else.

As I noted above, you can control the persistence of each share at its time of creation, both within the GUI and at the command line. The error being discussed is due to the default persistence of mapped shares carrying over mappings from previous logons and creating unintended issues.

 

[cainecabe]

my apologies... All of our users have an H drive mapped to their home share on the server (h:\\server\username share). The laptop users have their offline files synched to the H drive, which is the MyDocuments location. So, the only way they can access their h drive when offline is by a hard/persistant mapping (that way when they bootup offline the H drive is there with their cached offline files in it).
The problem we are expeirencing occurs to both laptop and desktop users, but the hard mapping is only for the laptop users. But I would like to try to treat them all the same since the problem is the same for many of each.
Thank you very much for your assistance in this matter, i greatly appreciate it.

Thanks,

 

[paleogryph]

Ok, here is more detail:

We have a mixed Novell/NT/AD network.

The Novell client (4.9) allows access to some shares, the H: drive (the one having the problem) is in the NT domain. The new AD domain wasn't really being used until we converted from GroupWise to Exchange 2003, which is in AD. The problem started at about the time of conversion.

First we thought it was some domain issue (NT vs. AD), but we found out that if we remove the Novell client the problem goes away. Another peripheral issue that popped up at the same time was that when users opened Office files on the H: drive, they wouldn't actually "open" for like 10-20 seconds. This problem has also gone away since removing the Novell client.

We tried upgrading the Novell client to 4.9SP2, to no avail. We haven't installed the MS Novell client though, because we don't want a IPX stack running.

Whats interesting is that both the users and machines are in the "old" NT domain, yet authenticate in the "new" AD to get their email via Outlook/Exchange, with no problems (there is a two way trust).

Hopefully in the next month or so, everything will be on AD, and these sorts of issues will go away.

Thanks for everyones help and suggestions.


>Think for yourself<
...or someone else will do it for you.

 

[bcastner]

Curious.

. Are you at SP4 for the Win2k workstations and servers?
. Does the Netware client logon include a lastdrive type of statement?

 

[MrTibbs]

The mapped drives on my PC (2K Pro onto 2KServer) were showing little red X's and occasionally showing this error when reading or saving files but otherwise behaving normally.
The files would save despite the error.
I told my PC under the share properties to not index this drive and the errors went away.

 

[MrTibbs]

Further ..
The indexing service on my PC was stopped throughout.
The 'little red X' went away as soon as I told the drive not to be indexed.