由于在运行 SQL 2014 的 Win 7.1 Pro 桌面和 Windows 2012 R2 Datacenter Azure 服务器上应用了全套修补程序，SQL Management Studio（2008 和 2014 版本）将无法连接到 SQL 2014 Azure 服务器。客户端连接尝试超时并失败，并出现 SQL 服务器错误 5。
SQL 服务器事务复制在本地 SQL 2008 实例和远程 SQL 2014 实例之间继续正常工作。此外，远程 (Azure) 服务器上的 SQL Management Studio 2014 可以毫无问题地连接到本地 (现场) SQL 2008 实例，以及远程 (Azure) SQL 2014 服务器。双向 DNS 解析和 IP 连接正常。我可以看到远程 SQL 2014 实例在启动时正确创建了其 SPN。SQL 2014 上有一个警告，提示某些客户端正在使用 NTLM 回退。
我没有 SQL 2014 的本地实例，也没有 SQL 2008 的远程实例。因此，我不确定服务器是远程的、在 Azure 上、通过 VPN 是否是相关因素，或者我是否会在修补的本地客户端和修补的本地 SQL 服务器上看到同样的问题。
我注意到远程 SQL 2014 服务器上的 SQL Browser 服务已停止并禁用。我不确定在补丁之前是否出现过这种情况。但是我在默认端口上运行了一个实例，而不是命名实例，因此我认为我不需要 SQL Browser 服务？
据报道，此补丁星期二存在与 Server 2003 网络文件共享相关的身份验证问题。我还没有看到有关一般 AD 身份验证问题或 SQL Server 身份验证问题的报告。还有其他人遇到过此问题或类似问题吗？有没有建议我应该尝试回滚哪个 KB？我应该运行 Kerberos 配置分析器吗？我应该启动已禁用的 SQL Browser 服务吗？
任何帮助均感激不尽。
从服务器上删除 MS15-027（KB3002657）并重新启动服务器无法解决问题。从
客户端删除 KB 3046049 并重新启动客户端无法解决问题。从服务器上删除 KB 3046049 并重新启动服务器无法解决问题，但错误代码从 5 更改为 53（更常见的错误代码）。
编辑：这不是同一个问题 今晚的安全更新后，SQL Server Windows 身份验证失败：登录来自不受信任的域 尽管它可能有相同的根本原因。（周二的补丁发布后，有关各种身份验证相关问题的报告似乎越来越多。）具体来说，就我而言，Windows 身份验证工作正常，我可以通过 RDP 进入已修补的计算机，并且已修补的计算机和基于 AD 的登录工作正常。
编辑：同样的问题影响 SQL 身份验证（非 AD）。相同的错误消息。这表明这是一个连接问题，而不是身份验证问题。
我们没有任何 Windows 2003 服务器受到影响。因此，我们看到的问题并不局限于 Windows Server 2003（正如其他一些类似的三月补丁问题所报告的那样）。
答案1
2015-03-11 星期三早上，在 3 月份 Windows 更新后，我们开始遇到 ODBC 和 Spotlight 软件与我们的 2005、2008 SQL 实例的连接问题，它们使用的是 Windows 域凭据。SQL 身份验证仍然有效。错误：用户“”登录失败。该用户与受信任的 SQL Server 连接无关。（Microsoft SQL Server，错误：18452）
我们的域级别是 2003，位于 Windows 2003 SP2 服务器上的多个站点。在我们的 Windows 2003 域控制器上，我们撤消了以下列出的所有更新：https://technet.microsoft.com/library/security/ms15-Mar 这恢复了我们所有的 SQL 数据库连接并允许操作成功完成夜间系统处理。
我们已拒绝通过 WSUS（Windows 更新服务器）为我们的内部网域上的所有服务器安装以下 2 个 Windows 更新：MS15-027（KB3002657）和 MS15-031（KB3046049）
请阅读以下有关这些更新所报告的问题的文章： http://www.infoworld.com/article/2895022/security/problems-reported-with-microsoft-patch-kb-3002657-and-a-warning-on-kb-3046049.html#tk.rss_security
support.microsoft.com/en-us/kb/3002657（阅读已知问题部分）
由于我们正在监控进一步的问题，目前我们不会在当前的 2003 域控制器上安装任何更新。
答案2
MS15-27 KB3002657 这不仅限于 Windows 2003 或微软报告的 EMC Epislon。
我的经验是：
从 Windows 7 工作站映射驱动器或使用 unc 路径到多个 Windows 2008 文件服务器（不是域控制器）会失败，并显示错误的用户名消息。
问题是 Windows 7 工作站与 Windows 2008 文件服务器位于不同的 Active Directory 域中。我们在 Windows 7 工作站加入的 DNS 区域中添加了静态 DNS 条目，用于解析 Windows 2008 服务器的 IP 地址。因此，用户可以使用短计算机名称访问文件共享（短名称 = \servername\sharename FQDN 长名称 = \servername.serverdomain.com\sharename）此过程导致工作站添加工作站 DNS 后缀 \servername.workstationdomain.com\sharename。这会触发补丁，认为计算机名称已被欺骗，因为服务器名称的 fqdn 是错误的。
为了纠正该问题：
1-从工作站 DNS 区域中删除服务器的 DNS 条目。
2- 通过组策略向工作站部署包含工作站 DNS 后缀和服务器 DNS 后缀的 DNS 后缀搜索列表
现在工作站仍然可以使用短 unc 路径名，并且在经过 dns 搜索后缀列表后找到正确的 fqdn 名称。
我们可能并不是唯一这么做的人。