Windows服务重启后连接Dynamics NAV端点SQL登录失败，IE触发后恢复求助

这种情况我碰到过好几次，核心原因大多和身份验证缓存、服务初始化状态或者网络配置加载有关，具体拆成几个常见场景：

1. NTLM/Kerberos身份验证上下文被IE触发缓存 #

Dynamics NAV的Web端点通常依赖Windows身份验证（NTLM或Kerberos）。你的Windows服务重启后，第一次尝试连接时，可能因为以下原因导致身份验证失败：

• 服务账户的SPN（服务主体名称）未正确注册，Kerberos协商失败
• 服务账户的权限上下文在启动时未完全加载，无法完成NTLM握手
• 系统的身份验证缓存为空，第一次验证请求被SQL Server拒绝

而用IE访问时，你是用当前登录的用户（通常是有NAV/SQL权限的本地或域用户）发起请求，这会触发完整的身份验证流程：系统会和NAV端点、SQL Server完成一次成功的验证握手，并把这个验证上下文（比如NTLM哈希、Kerberos票据）缓存到系统中。当后续你的Windows服务再发起请求时，系统会直接复用这个已缓存的验证上下文，跳过了失败的第一次协商，自然就能正常连接了。

2. NAV端点的应用程序池被IE触发初始化 #

如果你的NAV端点是托管在IIS上的Web服务，服务重启后对应的应用程序池可能处于闲置未启动状态：

• 应用程序池默认会在闲置一段时间后回收，或者服务器重启后需要第一个请求来触发启动
• 第一次启动时，NAV需要加载配置、初始化SQL连接池、加载业务逻辑组件，这个过程可能因为超时或资源不足导致第一次请求失败

IE的访问相当于给了端点一个"唤醒"请求：触发应用程序池启动，完成所有初始化步骤，包括建立SQL连接池。当你的Windows服务后续请求时，端点已经处于就绪状态，直接用已初始化好的连接池和组件，就不会再报SQL登录失败的错误了。

3. 网络代理/WinINET配置被IE触发加载 #

有些服务器会使用代理服务器或者自动配置脚本（PAC）来路由网络请求。Windows服务默认运行在系统账户下，可能不会自动加载IE的代理配置：

• 服务进程的网络上下文没有初始化代理设置，第一次请求无法正确路由到NAV端点
• IE访问时会触发系统加载当前用户的代理配置，并更新系统级的网络缓存

当服务后续发起请求时，系统已经加载了正确的代理配置，请求就能顺利到达NAV端点，进而成功连接SQL Server。

验证和解决建议 #

• 检查SPN注册：用setspn -L <服务账户>命令查看NAV服务的SPN是否正确注册，确保Kerberos验证能正常工作
• 配置应用程序池预热：在IIS中把NAV端点的应用程序池设置为AlwaysRunning，并启用启动模式为AlwaysRunning，这样服务器重启后应用程序池会自动初始化，不需要等待第一个请求
• 同步服务账户的权限上下文：让Windows服务使用和IE登录用户相同的账户运行，或者确保服务账户有足够的权限访问NAV端点和SQL Server

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