Mapped Drive Shows Disconnected, But Isn't

That is it.  The Public Share, mapped to Z: on the client computer, shows as a 'Disconnected Network Drive' ... however, it can be opened, used, written to, etc.  Strange?!!?
Who is Participating?
geniphConnect With a Mentor Commented:
This is actually not an uncommon problem.  I was seeing this a lot on domains that had one DC that was intermittently not responding.  Generally, the solution for me has been to promote another server to DC and demote the one that's having communication issues (look for a lot of directory service errors indicating replication problems).

I didn't have a lot of luck with the autodisconnect setting in my environment; getting rid of a flaky DC was more effective.  The only time this particular issue caused us a problem was with specific applications that required an "always-available" connection; they saw that drive as actually disconnected, even though clicking on it reconnects it, and the application would fail.
try the following
net config server /autodisconnect:-1
jigdogAuthor Commented:
Try this on the server or on the client?
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

on the client but i'n not sure if this works...cause the kb article is for w2k and nt4...

see here:
jigdogAuthor Commented:
Looks like it is some sort of bug in MS networking.  It eventually just went away.  Thanks everyone!
I have been fighting this issue for a long time, and nothing seemed to work until today.  I have a series of steps and reasons why this happens.  I found a solution for Vista machines on an SBS domain.
Reasons why this happens:
1. You are running a custom user script from AD Profile while Domain policy is calling a different script at logon.  Ex: Profile calls: employee.bat  Domain Policy calls: SBS_LOGIN_SCRIPT.bat  both scripts have the same mapped drive: net use x: \\server\share  mapping to the same drive letter.
2. You are creating an auto connection in AD Profile to a drive being mapped by login scripting.
There are a lot out there, but I have not seen this series of steps yet.
1. Check your domain policy and AD Profile for conflicting scripts.  If you have a logon script, either add it to domain policy or AD to make them match.
2. MS KB:  I deleted all the mount points.  This seemed to work best.
3. Remove your machine from the network.  Unplug it or turn wireless off and restart so it can NOT pull anything from the network.
4. Once you login on stored credentials check Windows Explorer to make sure there are no mapped drives showing.
5. If there are no mapped drives showing, plug the machine back in or turn wireless on to access the network.
6. Start-->run-->cmd  gpupdate /force
7. If asked to logoff, choose yes.
8. Log in and check to see if the correct drives are showing and all are connected.
I have seen this not work with the gpupdate...if it does not, repeat steps 1-5.  Instead of using gpupdate, manually run the login script:
Once all drives map successfully, you are fixed.
jigdogAuthor Commented:
Thanks for the update ... I have found MANY issues lately are related to Symantec software.  I have since been moving all of my my clients to ESET's NOD32 antivirus and receive feedback of better running machines overall.
I should have mentioned this is a solution for those not using Symantec AV.  I believe it was the 9.1 version that would cause this behavior on XP based machines.  You do have an excellent point when mentioning the Symantec error with mapped drives, as I have seen that error as well many times.  I have heard many positive reviews from Network Admins with ESET's product as well as Grisoft's AVG AV.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.