Hi,

A Windows XP domain client has logon scripts applied to map three network
drives, P, M and T. One client machine today has the old chestnut of
"Disconnected Network Drive" showing against each of the shares in My
Computer, and right click/disconnect gives the error "The network connection
could not be found".

I've been through all the usual tried and tested suggestions from this
newsgroup and others - net use * /delete ("There are no entries in the
list"), net use /persistent:no, rebooting, logging on as the local
administrator and doing it all again, renaming the drive to "kjshdfljdhfl",
searching the registry for the corresponding key and deleting it (it
resurrected itself on the next reboot), all to no avail.

No other client machines are affected, even in the same OU/Site where all
login scripts are generic.

Searching various newsgroups shows this exact problem occurring as early as
2004, and yet there still doesn't seem to be a coherent resolution for this
problem.

Any clues?

I have found that when all else fails (particularly net use * /delete) that
a registry edit may fix the problem. (Usual warnings - be careful re.
editing registry...)

Under the key
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\MountPoints2]look for an entry like this ##SRV02#C which is the way \\SRV02\C is shown.Delete that key. Then log off and on again or reboot. The stuck shareshould be gone.I'd appreciate your feedback if you apply this. I haven't seen any othermention of this solution, which I found after my own analysis, but it workedwell for me and others have reported success with it.--"Mayy" <Mayy@discussions.microsoft.com> wrote in messagenews:4C83270E-201F-4A16-BD0F-B8998C539E58@microsoft.com...> Hi,>> A Windows XP domain client has logon scripts applied to map three network> drives, P, M and T. One client machine today has the old chestnut of> "Disconnected Network Drive" showing against each of the shares in My> Computer, and right click/disconnect gives the error "The networkconnection> could not be found".>> I've been through all the usual tried and tested suggestions from this> newsgroup and others - net use * /delete ("There are no entries in the> list"), net use /persistent:no, rebooting, logging on as the local> administrator and doing it all again, renaming the drive to"kjshdfljdhfl",> searching the registry for the corresponding key and deleting it (it> resurrected itself on the next reboot), all to no avail.>> No other client machines are affected, even in the same OU/Site where all> login scripts are generic.>> Searching various newsgroups shows this exact problem occurring as earlyas> 2004, and yet there still doesn't seem to be a coherent resolution forthis> problem.>> Any clues?

I have found that when all else fails (particularly net use * /delete) that
a registry edit may fix the problem. (Usual warnings - be careful re.
editing registry...)

Under the key
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\MountPoints2]look for an entry like this ##SRV02#C which is the way \\SRV02\C is shown.Delete that key. Then log off and on again or reboot. The stuckshareshould be gone.I'd appreciate your feedback if you apply this. I haven't seen any othermention of this solution, which I found after my own analysis, but it workedwell for me and others have reported success with it."--"Mayy" <Mayy@discussions.microsoft.com> wrote in messagenews:4C83270E-201F-4A16-BD0F-B8998C539E58@microsoft.com...> Hi,>> A Windows XP domain client has logon scripts applied to map three network> drives, P, M and T. One client machine today has the old chestnut of> "Disconnected Network Drive" showing against each of the shares in My> Computer, and right click/disconnect gives the error "The networkconnection> could not be found".>> I've been through all the usual tried and tested suggestions from this> newsgroup and others - net use * /delete ("There are no entries in the> list"), net use /persistent:no, rebooting, logging on as the local> administrator and doing it all again, renaming the drive to"kjshdfljdhfl",> searching the registry for the corresponding key and deleting it (it> resurrected itself on the next reboot), all to no avail.>> No other client machines are affected, even in the same OU/Site where all> login scripts are generic.>> Searching various newsgroups shows this exact problem occurring as earlyas> 2004, and yet there still doesn't seem to be a coherent resolution forthis> problem.>> Any clues?

Hi GTS,

I've deleted each of the ##server#share keys but there's also 48 keys with
GUID-style names, and in a fit of inspiration I backed up that section of the
registry and deleted each of those keys. Now, each time I refresh the My
Computer view and then refresh that section of the registry, the same five
keys reappear each time.

I delete those keys, go through the refresh process, and the same five keys
reappear. I rename the three drives with unique labels and see those labels
as values within three of these keys. I've no idea if the key names are
significant, but here they are:

{0BC1C0BB-B1D4-4078-A99A-33B36A6CE84C} (corresponds
to drive P)
{4fb54bb4-3ed7-11d9-adea-806d6172696f} (no value
other than "default")
{4fb54bb5-3ed7-11d9-adea-806d6172696f} (no value
other than "default")
{C55B3392-BC85-47A5-9A2A-1E77CC38522A} (corresponds
to drive M)
{DA011442-55FA-45B8-9564-2407DEECB60B} (corresponds
to drive T)

Recall that there's only three mapped drives having this issues, no other
mapped drives, and separate keys for drives A, C and D and one key called CPC.

Now here's the interesting bit.

I reboot, and the names I called the shares above are lost and they are each
again called "Disconnected Network Drive". Another four keys appear under
MountPoints2, and three of the new keys relate to the disconnected drives.
The keys I noted above are still present, but now apparently redundant.

I hope this helps ... (it hasn't helped me!!)



"GTS" wrote:

> I have found that when all else fails (particularly net use * /delete) that
> a registry edit may fix the problem. (Usual warnings - be careful re.
> editing registry...)
>
> Under the key
> [HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\MountPoints2]look for an entry like this ##SRV02#C which is the way \\SRV02\C is shown.Delete that key. Then log off and on again or reboot. The stuckshareshould be gone.I'd appreciate your feedback if you apply this. I haven't seen any othermention of this solution, which I found after my own analysis, but it workedwell for me and others have reported success with it."--"Mayy" <Mayy@discussions.microsoft.com> wrote in messagenews:4C83270E-201F-4A16-BD0F-B8998C539E58@microsoft.com...> Hi,>> A Windows XP domain client has logon scripts applied to map three network> drives, P, M and T. One client machine today has the old chestnut of> "Disconnected Network Drive" showing against each of the shares in My> Computer, and right click/disconnect gives the error "The networkconnection> could not be found".>> I've been through all the usual tried and tested suggestions from this> newsgroup and others - net use *
/delete ("There are no entries in the> list"), net use /persistent:no, rebooting, logging on as the local> administrator and doing it all again, renaming the drive to"kjshdfljdhfl",> searching the registry for the corresponding key and deleting it (it> resurrected itself on the next reboot), all to no avail.>> No other client machines are affected, even in the same OU/Site where all> login scripts are generic.>> Searching various newsgroups shows this exact problem occurring as earlyas> 2004, and yet there still doesn't seem to be a coherent resolution forthis> problem.>> Any clues?
>
>

I've just had a similar problem where a supposed N: network drive was listed
as a disconnected drive in Windows Explorer, but I could double-click on it
to view the drive's contents. However, shortcuts that pointed to locations on
this N: drive didn't work, I couldn't disconnect the drive through Windows
Explorer, and it wasn't listed using the Net Use command.

The problem was with a shortcut in the user's Startup folder that pointed to
a command file on this N: drive. It was as if the N: drive definition was
being created on the fly in response to trying to execute the shortcut, but
not correctly.

The following resolved the problem:

1. Log on as the affected user.

2. Move the shortcut from the Startup folder.

3. Open a Command window, and execute the following commands:
net use /persist:no
net use * /delete

4. Log off, and then back on again, and verify there were no mapped drives.

5. Open a Command window, and execute the following command:
net use /persist:yes

6. Run our standard .cmd file to create our standard drive mappings.

7. Log off, and then back on again, and verify that the drive mappings were
as expected.

8. Restore the shortcut to the Startup folder.

9. Log off, and then back on again, and check that behaviour was as intended.

Your set-up won't match ours, but to generalise, you could look for any
start-up processes that point to your problem mapped drives, disable them,
and ensure that drives are mapped correctly before they are used by any other
processes.

"Mayy" wrote:

> Hi,
>
> A Windows XP domain client has logon scripts applied to map three network
> drives, P, M and T. One client machine today has the old chestnut of
> "Disconnected Network Drive" showing against each of the shares in My
> Computer, and right click/disconnect gives the error "The network connection
> could not be found".
>
> I've been through all the usual tried and tested suggestions from this
> newsgroup and others - net use * /delete ("There are no entries in the
> list"), net use /persistent:no, rebooting, logging on as the local
> administrator and doing it all again, renaming the drive to "kjshdfljdhfl",
> searching the registry for the corresponding key and deleting it (it
> resurrected itself on the next reboot), all to no avail.
>
> No other client machines are affected, even in the same OU/Site where all
> login scripts are generic.
>
> Searching various newsgroups shows this exact problem occurring as early as
> 2004, and yet there still doesn't seem to be a coherent resolution for this
> problem.
>
> Any clues?

Interesting. I take it those drives are the ones mapped in the login
script. Should they be accessible as legitimate shares? If so, might there
be a server related issue re. user rights or some problem with cached
credentials? In the case where I used that registry fix, it was for a
stuck past mount that was more easily resolved.

--

"Mayy" <Mayy@discussions.microsoft.com> wrote in message
news:74761167-2303-4312-B177-5816E8CC78A1@microsoft.com...
> Hi GTS,
>
> I've deleted each of the ##server#share keys but there's also 48 keys with
> GUID-style names, and in a fit of inspiration I backed up that section of
> the
> registry and deleted each of those keys. Now, each time I refresh the My
> Computer view and then refresh that section of the registry, the same five
> keys reappear each time.
>
> I delete those keys, go through the refresh process, and the same five
> keys
> reappear. I rename the three drives with unique labels and see those
> labels
> as values within three of these keys. I've no idea if the key names are
> significant, but here they are:
>
> {0BC1C0BB-B1D4-4078-A99A-33B36A6CE84C}
> (corresponds
> to drive P)
> {4fb54bb4-3ed7-11d9-adea-806d6172696f} (no value
> other than "default")
> {4fb54bb5-3ed7-11d9-adea-806d6172696f} (no value
> other than "default")
> {C55B3392-BC85-47A5-9A2A-1E77CC38522A} (corresponds
> to drive M)
> {DA011442-55FA-45B8-9564-2407DEECB60B}
> (corresponds
> to drive T)
>
> Recall that there's only three mapped drives having this issues, no other
> mapped drives, and separate keys for drives A, C and D and one key called
> CPC.
>
> Now here's the interesting bit.
>
> I reboot, and the names I called the shares above are lost and they are
> each
> again called "Disconnected Network Drive". Another four keys appear under
> MountPoints2, and three of the new keys relate to the disconnected drives.
> The keys I noted above are still present, but now apparently redundant.
>
> I hope this helps ... (it hasn't helped me!!)
>
>
>
> "GTS" wrote:
>
>> I have found that when all else fails (particularly net use * /delete)
>> that
>> a registry edit may fix the problem. (Usual warnings - be careful re.
>> editing registry...)
>>