我的公司正在使用Windows 2003服务器的域环境。 一切都很好，除了一个挑剔的笔记本电脑。 它和域名服务器之间的任何与networking相关的活动都很慢。 另一方面，互联网活动是快速的。 即使漫游configuration文件已被caching在机器上，login到此特定机器上的域也需要大约10分钟的时间，不要夸张。 当试图访问此帐户（以及域中的其他人）可以访问的共享时，它会提示input密码，而不是在后台发送凭据。 即使手动input凭据，它们仍然不被接受，并且login对话框返回。 本机拒绝在login时自动映射驱动器以及通过我们的login脚本，这在800多台其他机器和用户上运行良好。 脚本中没有什么奇特的东西，只有几个net use声明。
现在怪异的部分….
在本机上login其他用户帐户时，所有驱动器都可以正常映射。 当以另一台机器上的特定用户身份login时，所有驱动器都按预期映射，访问共享时不会要求凭据。 这只是这台机器和帐户的组合，不合作。 我们首先认为是硬件，并且更换了系统主板（解决了间歇性连接问题），但是networking驱动器的问题仍然是显而易见的，凭证没有被正确地传递或者有些奇怪。 我已经尝试重新创build此用户的Windowsconfiguration文件无济于事。
任何人遇到类似的东西？ 你怎么吃的？
在解决类似问题时，我发现最好的解决scheme是使用Wireshark进行分类以创build数据包跟踪。 你需要弄清楚机器通信时实际发生了什么。 在交换机上镜像一个端口，然后运行Wireshark三次 – 使用不同用户的机器运行两次，然后使用另一台运行的机器运行在同一个镜像端口上。 查找服务器和客户端之间的stream量长时间停止的时间，并找出哪个客户端正在等待，哪个不响应。 比较三个痕迹，看看所有通信的差异。 如果不是街道地址，你会发现一个线索可以显示问题实际上在哪个大陆。 祝你好运！
显然，Windows会在“脱机文件”caching中保存驱动器映射，DFS链接和其他nitnoid事物（无论是否启用脱机文件）。 caching保存在每个客户端机器上的每个用户。 这个caching可能会变得腐败，这导致涉及到所有技术的许多问题。
清除caching并重新初始化数据库通常可以解决这些问题。 该过程涉及一个registry项是不同的Windows版本。
XP： https ： //support.microsoft.com/en-us/kb/230738
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\NetCache" /v FormatDatabase /t REG_DWORD /d 1 /f
Win7 / 8.1： https ： //support.microsoft.com/en-us/kb/942974
REG ADD "HKLM\System\CurrentControlSet\Services\CSC\Parameters" /v FormatDatabase /t REG_DWORD /d 1 /f
我个人的经验是与DFS链接。 当受影响的用户尝试使用DFS链接访问文件共享时，他们将获得访问被拒绝的错误消息。 如果我们跳过DFS并直接进入文件服务器，他们可以很好地进行身份validation。 如果我们使用备用凭证连接到DFS，那么我们可以很好地进行身份validation。 如果我们以不同的用户身份login，我们可以很好地进行身份validation。 如果连接到DFS的受影响用户在另一台计算机上共享，则他们可以很好地进行身份validation。 保存在脱机文件caching中的DFS链接指针已损坏 – 擦除caching可解决问题。