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

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: Click Start, click Run, type regedit (Windows 2000 or Windows Server 2003) or type regedt32(Windows NT 4.0), and then click OK.Locate and then click the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters 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: On the Edit menu, point to New, and then click REG_DWORD.Type autodisconnect, and then press ENTER. On the Edit menu, click Modify.Click Hexadecimal.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

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: Click Start, click Run, type regedit (Windows 2000 or Windows Server 2003) or type regedt32(Windows NT 4.0), and then click OK.Locate and then click the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters 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: On the Edit menu, point to New, and then click REG_DWORD.Type autodisconnect, and then press ENTER. On the Edit menu, click Modify.Click Hexadecimal.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

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

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

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.

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!)