TFS 2015（Update3）间歇性连接故障排查咨询

针对你遇到的TFS 2015 Update3间歇性连接故障，结合新域迁移的背景，我整理了几个更深入的排查方向和诊断方法，应该能帮你定位问题：

• TFS应用层详细诊断日志：默认路径一般是C:\Program Files\Microsoft Team Foundation Server 14.0\Application Tier\Web Services\_diag，这里的日志比系统事件日志更细致，故障发生时的*.log文件里可能藏着请求延迟、SQL交互超时的细节。你可以临时调高日志级别到Verbose来捕获更多信息，执行命令：tfsmgmt.exe log /set:Verbose /appTier，排查完记得调回Normal避免日志过度膨胀。
• SQL Server端日志与扩展事件：因为数据层和应用层分离，别只盯着TFS的日志，要查SQL的错误日志（在SSMS的「管理」→「SQL Server日志」里），还要创建针对TFS数据库的扩展事件会话，追踪长时间运行的查询、锁等待、连接超时情况。另外，监控SQL的性能计数器，比如SQLServer:General Statistics里的User Connections、SQLServer:Wait Statistics里的Latch Waits，能直观看出故障时数据库是否存在瓶颈。
• IIS失败请求跟踪日志：开启IIS的失败请求跟踪，针对TFS网站设置追踪耗时超过5秒的请求，这样能完整记录慢请求的执行流程，定位是哪个环节卡住了（比如模块执行、数据库调用）。开启方法：在IIS管理器选中TFS网站，点击「失败请求跟踪规则」，新建规则并设置时间阈值即可。
• 域认证相关系统日志：因为用户迁到新域而TFS在旧域，要重点看TFS服务器系统日志里的Kerberos/NTLM认证事件（事件ID 4624、4625、4776），故障发生时是否有大量认证失败或延迟？这很可能是跨域信任或DNS解析的问题。

• 跨域认证性能测试：找几个新域用户，故障时先执行klist purge清空本地Kerberos缓存，再尝试访问TFS，同时用Wireshark抓包，看认证过程是否有延迟或重传。另外，检查TFS服务器的SPN配置是否正确——跨域环境下SPN错误会导致认证反复重试拖慢速度，执行setspn -L <TFS服务器名>，确认有http/<TFS服务器FQDN>和http/<TFS服务器NetBIOS名>这两个SPN。
• DNS解析验证：故障发生时，在用户端和TFS服务器分别执行nslookup <TFS服务器FQDN>和nslookup <新域域名>，看解析是否超时或返回错误IP。还要确认TFS服务器的DNS设置包含新域的DNS服务器，避免跨域解析延迟。
• AD信任关系检查：联系域管理员，确认旧域和新域的双向信任是否正常，有没有间歇性故障。你也可以自己执行命令验证：netdom trust <旧域名> /domain:<新域名> /verify。

• VMware层面资源监控：因为是VMware 6.0部署，要查ESXi主机的性能数据，看故障时TFS虚拟机是否有CPU就绪时间过高（被主机调度延迟）、存储IO延迟过大（磁盘队列长度超标）这类问题。在vCenter里查看虚拟机的性能图表，重点关注CPU就绪、磁盘读取/写入延迟这些指标。
• TFS缓存深层清理：你已经清理过应用层缓存，但可以试试清理客户端缓存（用户端路径%LOCALAPPDATA%\Microsoft\Team Foundation\7.0\Cache），旧域的缓存信息可能导致访问异常。另外，检查SQL中TFS_Configuration数据库的tbl_Property表，看有没有缓存相关的异常配置。
• TFS后台作业检查：故障发生时，登录TFS管理控制台查看「作业代理」里的作业状态，有没有长时间运行的作业（比如仓库同步、分析数据库处理）占用资源？可以临时用tfsservicecontrol quiesce停止TFS服务，看故障是否消失，排除后台作业的影响。

• 临时切换认证模式：在TFS管理控制台把认证模式从Negotiate临时换成NTLM，测试故障是否消失——这能快速排查Kerberos认证导致的问题。
• 安装TFS累积更新：TFS 2015 Update3之后还有Update3.1、Update3.2等累积更新，其中修复了不少跨域认证和性能相关的问题，可以尝试安装最新的补丁。
• 数据库一致性检查：对TFS的所有数据库（配置、集合、分析）执行DBCC CHECKDB，排查是否有隐性的数据库损坏——有时候这种问题也会导致间歇性故障。

内容的提问来源于stack exchange，提问作者CK89