none
isse with Windows 7 and mapped DFS drives

    Pertanyaan

  • We are a college campus and faculty and staff are using Windows 7 enterprise
    with SP1. I also have 3 servers running DFS. Prior to installing Windows 7 DFS
    worked fine for a couple of years now some not all are having issue connecting
    to the DFS share they are mapped to it just shows a RED X. After period of time
    it will come back by itself. But again another day it reverts back to the RED X

    when we click on the RED x drive it prompts us for username and password but
    when we enter credentials it just keeps prompting and won't stop

    I had one user told me she was prompted for credentials after clicking on the
    DFS drive that had the RED X and gave up. she came back from lunch and the red x
    was gone.

    After a period of time all users experience differenct times the RED x
    disappears and the user can use the drive a day or two later the RED x appears
    again. the only recourse we have is the map the user directly to the server and
    not use dFS

    02 Maret 2012 21:25

Jawaban

  • There are some registry tweaks you can do to resolve this issue, can you try out the following settings on a single machine to see if it resolves the issue:

    1. Click Start, click Run, type regedit (Windows 2000 or Windows Server 2003) or type regedt32(Windows NT 4.0), and then click OK.
    2. Locate and then click the following key in the registry:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
    3. In the right pane, click the autodisconnect value, and then on the Edit menu, click Modify. If theautodisconnect value does not exist, follow these steps:
      1. On the Edit menu, point to New, and then click REG_DWORD.
      2. Type autodisconnect, and then press ENTER.
    4. On the Edit menu, click Modify.
    5. Click Hexadecimal.
    6. In the Value data box, type ffffffff, and then click OK.
    NOTE: The client-side session is automatically disconnected when the idling time lasts more than the duration that is set in KeepConn. Therefore, the session is disconnected according to the shorter set duration value between AutoDisConnect and KeepConn. To change the time-out duration in the client-side during a UNC connection, specify the arbitrary time in KeepConn.
    Locate and then click the following key in the registry:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\lanmanworkstation\parameters
    Value: KeepConn 
    Data type : REG_DWORD 
    Range : 1 to 65535 (sec) 
    Default value: 600 sec = 10 mins

    Source: Mapped Drive Connection to Network Share May Be Lost

    05 Maret 2012 9:07
  • Hi,

    This behavior occurs because the systems can drop idle connections after a specified time-out period (by default, 15 minutes) to prevent wasting server resources on unused sessions. The connection can be re-established very quickly, if required.

    You may fix this problem automatically with Microsoft Fix it tool 50494, or modify registry editor to resolve it.  Here are two related articles can be referred to.

    Maintaining the Dfs Configuration
    http://technet.microsoft.com/en-us/library/cc962150.aspx

    Mapped Drive Connection to Network Share May Be Lost
    http://support.microsoft.com/kb/297684

    06 Maret 2012 8:52

Semua Balasan

  • There are some registry tweaks you can do to resolve this issue, can you try out the following settings on a single machine to see if it resolves the issue:

    1. Click Start, click Run, type regedit (Windows 2000 or Windows Server 2003) or type regedt32(Windows NT 4.0), and then click OK.
    2. Locate and then click the following key in the registry:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
    3. In the right pane, click the autodisconnect value, and then on the Edit menu, click Modify. If theautodisconnect value does not exist, follow these steps:
      1. On the Edit menu, point to New, and then click REG_DWORD.
      2. Type autodisconnect, and then press ENTER.
    4. On the Edit menu, click Modify.
    5. Click Hexadecimal.
    6. In the Value data box, type ffffffff, and then click OK.
    NOTE: The client-side session is automatically disconnected when the idling time lasts more than the duration that is set in KeepConn. Therefore, the session is disconnected according to the shorter set duration value between AutoDisConnect and KeepConn. To change the time-out duration in the client-side during a UNC connection, specify the arbitrary time in KeepConn.
    Locate and then click the following key in the registry:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\lanmanworkstation\parameters
    Value: KeepConn 
    Data type : REG_DWORD 
    Range : 1 to 65535 (sec) 
    Default value: 600 sec = 10 mins

    Source: Mapped Drive Connection to Network Share May Be Lost

    05 Maret 2012 9:07
  • Hi,

    This behavior occurs because the systems can drop idle connections after a specified time-out period (by default, 15 minutes) to prevent wasting server resources on unused sessions. The connection can be re-established very quickly, if required.

    You may fix this problem automatically with Microsoft Fix it tool 50494, or modify registry editor to resolve it.  Here are two related articles can be referred to.

    Maintaining the Dfs Configuration
    http://technet.microsoft.com/en-us/library/cc962150.aspx

    Mapped Drive Connection to Network Share May Be Lost
    http://support.microsoft.com/kb/297684

    06 Maret 2012 8:52
  • I appreciate the responses but I don't believe the timeout on autoconnect has everything to do with the RED X we are experiencing.  As the articles states if you have a RED X you can reestablish connection immediately.  In my situation, you click on the RED X drive and it prompts you for a username and password.  You enter the information and it keeps prompting you again and again and again until you finally give up. Thanks again for all your help.  I hope someone is having the same issue and has resolved it.  It is a shame we have to map directly to the server that holds the share and give up on DFS.  It has always worked until we moved from windows XP to windows 7 sp1.
    30 Maret 2012 20:49
  • Hi Donato1,

    I'm no expert but, given the random nature of this issue, could it be anything to do with Group Policy?  This might explain why it randomly affects different users at different times.  It might be worth checking out if you map your DFS shares via GP (User Configuration>Preferences>Windows Settings>Drive Maps).

    I've been looking at a similar issue (though not the same) and thought this link was interesting, though the issue relates to logon, as the solution related to using UNC paths to point to DFS shares.  If you've migrated from XP to Windows 7 (we are mid way through) you might still have UNC paths configured for drive mappings.  To quote the article:

    "In our case, scripting connection refreshes does not work, as we use folder redirection for roaming users. The problem is that practically everywhere we use DFS with the old style UNC with the bare domain name  eg \\ourdomain\shares\apps or \\ourdomain\shares\users

    Windows 7 takes about 5 minutes after startup to realize that it can use the bare domain name. Before this it only understands ourdomain.local.

    2 ways to fix it:

    - in TCPv4 settings/advanced/DNS put local and ourdomain.local into the domain suffix search list.
    - do the same using Group policy->Computer Configuration-> Administrative Templates/network/DNS Client/ DNS Suffix Search List."

    On a similar vein, you might want to check the UNC format for drive mapping as well - as per Mervyn Zhang at this link - especially if you can manually map to \\servername\share but your GP/persisten drive mappings point to \\FQDN\root\share.  In this scenario, you can get access denied issues when the drive mapping FQDN is seen as an internet site rather than an intranet site.

    Anyway - this may be irrelavant to your scenario but thought I'd post as I've been working along similar lines (think the posts above answer my issue though!)

    17 April 2012 12:20
  • We have a similar issue I haven't gotten to the bottom with.

    Drive mapped dfs-shares are intermittently not connected when you login or unlock the computer. It seems as if you are too fast and open explorer and click on the mapped drive it lists all target folder, but when you click on a target folder you get the error "network location is not available." If I right click a target folder nothing show up on the security tab. It seems as if the acl:s aren't downloaded. Sometimes this corrects itself within a few minutes if not you have to log out and log in again. Also pulling the network cable and reattaching it seems to fix the problem, unless you are eager and try to access the mapped drive to soon once again.

    Going straight for the dfs share works while the mapped drive don't, same thing if you go straight for the share on the fileserver,  same thing if you map a shares on the fileserver, it never fails. So the problem definitely have something to do with drive mappings and dfs shares specifically.

    It would be very interesting if someone have a suggestion on how to troubleshoot why the ACL:s don't show up.

    ninjaedit: Could also be a problem with explorer and not dfs or drive mappings but I'm not sure how to test that theory.


    • Diedit oleh Molotch 26 September 2012 15:42
    26 September 2012 15:40