我的公司正在使用带有 Windows 2003 服务器的域环境。除了一台挑剔的笔记本电脑外，一切都很好。它与域服务器之间的任何网络相关活动都很慢。另一方面，互联网活动很快。毫不夸张地说，在这台特定的机器上登录域大约需要 10 分钟，即使漫游配置文件已经缓存在机器上。当尝试访问此帐户（以及域中的其他所有人）有权访问的共享时，它会提示输入密码，而不是在后台发送凭据。即使手动输入凭据，它们仍然不被接受，登录对话框会再次出现。这台机器拒绝在通过我们的登录脚本登录时自动映射驱动器，该脚本在 800 多台其他机器和用户上运行良好。脚本中没有什么特别的，只有几个net use语句。
现在说说奇怪的部分......
使用其他用户账户登录时这台机器，所有驱动器映射正常。以这个特定的用户在另一台机器，所有驱动器都按预期映射，并且在访问共享时不要求提供凭据。这只是这台机器和帐户的组合不合作。我们最初认为是硬件问题，并更换了系统板（解决了间歇性连接问题），但网络驱动器的问题仍然很明显，凭据无法正确传递或出现异常。我已经尝试重新创建此用户的 Windows 配置文件，但无济于事。
有人遇到过类似的事情吗？你们的情况如何？
答案1
在排除类似问题时，我发现最好的解决方案是使用 Wireshark 进行数据包跟踪。您需要弄清楚机器通信时到底发生了什么。镜像交换机上的一个端口并运行 Wireshark 三次 - 两次在这台机器上使用不同的用户，然后一次在另一台可以正常工作的机器上使用相同的镜像端口。查找服务器和客户端之间的流量长时间停止的时间段，并找出哪个客户端在等待，哪个没有响应。比较这三个跟踪并查看所有通信中的差异。在其中的某个地方，您会找到一条线索，该线索将显示问题实际上发生在哪个大陆，如果不是街道地址的话。祝你好运！
答案2
显然，Windows 会将驱动器映射、DFS 链接和其他 nitnoid 内容保存在脱机文件缓存中（无论您是否启用了脱机文件）。缓存会按每个客户端计算机上的用户保存。此缓存可能会损坏，从而导致所有相关技术出现大量问题。
清除缓存并重新初始化数据库通常可以解决这些问题。此过程涉及注册表项，而不同版本的 Windows 的注册表项有所不同。
经验值：https://support.microsoft.com/en-us/kb/230738
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\NetCache" /v FormatDatabase /t REG_DWORD /d 1 /f
Windows 7/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 并直接进入文件服务器，他们就可以顺利进行身份验证。如果我们使用备用凭据连接到 DFS，我们可以顺利进行身份验证。如果我们以其他用户身份登录，我们可以顺利进行身份验证。如果受影响的用户在另一台计算机上连接到 DFS 共享，他们可以顺利进行身份验证。保存在脱机文件缓存中的 DFS 链接指针已损坏 - 清除缓存解决了该问题。