Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My company is using a domain environment with Windows 2003 servers. All is great, except for one fussy laptop. Any network-related activity between it and domain servers is slow. Internet activity is fast on the other hand. Logging in to the domain on this particular machine takes around 10 minutes, no exaggeration, even if the roaming profile is already cached on the machine. When trying to access shares that this account (and everyone else in the domain) has access to, it prompts for a password rather than sending the credentials in the background. Even when the credentials are typed in manually, they are still not accepted and the login dialog comes back up. This machine refuses to map drives automatically upon loging as well via our login script, which works fine on over 800 other machines and users. There is nothing fancy in the script, just a few net use statements.

Now for the weird part....

When logging in on other user accounts on this machine, all drives map fine. When logging in as this particular user on another machine, all the drives map as expected and it does not ask for credentials when accessing shares. It is just the combination of this machine and account that don't cooperate. We thought it was the hardware at first, and had the system board replaced (which solved issues with intermittent connection problems) but the issue of the network drives is still apparent and credentials are not being passed correctly or something odd. I have already tried recreating this user's Windows profile to no avail.

Anyone ever encounter anything similar? And how did you fare?

share|improve this question
best guess is the machines domain acount maybe bad! – tony roth Sep 30 '10 at 5:51

When troubleshooting similar issues, I have found that the best solution is to triage using Wireshark to make packet traces. You need to figure out what is actually going on when the machines communicate. Mirror a port on your switch and run Wireshark three times -- twice on this machine with different users and then once on the same mirrored port using another machine that does work. Look for periods where traffic between the server and client stops for long periods, and figure out which client is waiting and which is not responding. Compare the three traces and see the differences in all communication. Somewhere in there you will find a clue that will show which continent the problem is actually on, if not the street address. Good luck!

share|improve this answer

Apparently Windows saves drive mappings, DFS links, and other nitnoid things in the Offline Files cache (whether or not you have offline files enabled). The cache is saved per user on each client machine. This cache can become corrupt, which leads to numerous issues with all of the technologies involved.

Clearing the cache and reinitializing the database can usually resolve these issues. The process involves a registry entry which is different for different versions of Windows.

REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\NetCache" /v FormatDatabase /t REG_DWORD /d 1 /f

REG ADD "HKLM\System\CurrentControlSet\Services\CSC\Parameters" /v FormatDatabase /t REG_DWORD /d 1 /f

My personal experience was with DFS links. When affected users attempted to access the file share using the DFS link, they would get an access denied error message. If we skipped DFS and went straight to the file server, they could authenticate fine. If we connected to DFS using alternate credentials, we could authenticate fine. If we logged in as a different user, we could authenticate fine. If the affected users connected to the DFS share on a different computer, they could authenticate fine. The pointer for the DFS link that gets saved in the offline files cache was corrupt - wiping the cache resolved the issue.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.