3月10日补丁星期二似乎会导致Server客户端连接问题
由于在运行SQL2014的Win 7.1 Pro桌面和Windows2012 R2数据中心Azure服务器上应用了完整的修补程序，(2008和2014年版本)将不会连接到SQL2014 Azure服务器。客户端连接尝试超时，并在server错误5中失败。
SQL server事务性复制继续在本地SQL 2008实例和远程SQL 2014实例之间正常工作。此外，远程(Azure)服务器上的2014可以毫无问题地连接到本地(现场) SQL 2008实例，也可以连接到远程(Azure) SQL 2014服务器。DNS解析和两个方向的IP连接都是正常的。我可以看到远程SQL 2014实例在启动时正确地创建了它的SPN。在SQL 2014中有一个警告，即一些客户端正在使用NTLM回退。
我没有SQL 2014的本地实例，也没有SQL 2008的远程实例。因此，我不确定服务器是否是远程的、Azure上的、VPN上的，或者我是否会看到修补本地客户端和修补本地SQL服务器的问题。
我注意到远程SQL 2014服务器上的SQL浏览器服务已停止并禁用。我不确定这是不是补丁前的情况。但是，我在默认端口上运行一个实例，而不是一个命名实例，因此我希望我不需要SQL浏览器服务？
据报告，此修补程序星期二存在与Server 2003网络文件共享有关的身份验证问题。我还没有看到关于一般AD身份验证问题或Server身份验证问题的报告。有其他人有这个问题或类似的吗？有什么建议我应该尝试回滚哪一个KB？我应该运行Kerberos配置分析器吗？是否启动禁用的SQL浏览器服务？
任何帮助都很感激。
从服务器中删除MS15-027(KB3002657)并重新启动服务器并不能解决问题。
删除客户端上的KB 3046049并重新启动客户端并不能解决问题。删除服务器上的KB 3046049并重新启动服务器并不能解决问题，但错误代码从5更改为53 (更常见的错误代码)。
编辑:这与在今晚的安全更新之后，服务器身份验证失败:登录来自不受信任的域不是同一个问题，尽管它可能有相同的根源。(周二的补丁发布后，似乎有越来越多的报道称，与身份验证相关的问题越来越多。)具体来说，在我的情况下，windows身份验证工作正常，我可以将RDP放入修补程序的机器中，并在修补计算机和基于AD的登录之间运行良好。
编辑:同样的问题会影响SQL身份验证(非AD)。相同的错误信息。这表明这是一个连接问题，而不是身份验证问题。
我们没有任何Windows 2003服务器受到影响。因此，我们看到的问题并不局限于Windows 2003 (其他类似的三月修补程序问题也是如此)。
回答 2
Server Fault用户
发布于 2015-03-13 13:39:49
在3月的Windows更新之后，我们的ODBC和Spotlight软件连接到我们的2005,2008 SQL实例时，它们使用的是windows域凭据。SQL身份验证仍然有效。错误:用户“”登录失败。用户不与受信任的Server连接关联。(，错误: 18452)
我们的域级别是2003在windows 2003 SP2服务器上的多个站点。在我们的Windows2003DomainController上，我们备份了在：https://technet.microsoft.com/library/security/ms15-Mar中列出的所有更新，这恢复了我们所有的，并允许操作成功地完成夜间系统处理。
我们拒绝通过我们的WSUS()为我们的内联网域上的所有服务器安装以下两个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_安全性
Support.microsoft.com/en/kb/3002657(阅读“已知问题”一节)
此时，我们不会在当前的2003域控制器上安装任何更新，因为我们正在监视进一步的问题。
Server Fault用户
发布于 2015-03-17 15:14:41
MS15-27 KB3002657这不仅限于Windows 2003，也不限于微软报告的EMC Epislon。
我的经验是：
将驱动器或使用unc路径从Windows 7工作站映射到多个Windows 2008文件服务器(而不是域控制器)将因用户名消息不正确而失败。
问题是Windows 7工作站位于与Windows 2008文件服务器不同的Active域。我们在dns区域中添加了静态DNS条目，将Windows 7工作站连接起来，以解决Windows 2008服务器的ip地址问题。因此，用户可以使用短计算机名来访问文件共享(Short name = \servername\sharename FQDN long name = \servername.serverdomain.com\sharename)。此过程会导致工作站使用\servername.workstationdomain.com\sharename的工作站dns后缀。这会触发修补程序相信计算机名已被欺骗，因为servername的fqdn错误。
为了纠正这一问题：
1-从工作站dns区域中删除服务器的dns条目。
2-通过组策略将包含工作站dns后缀和服务器dns后缀的dns后缀部署到工作站。
现在工作站仍然可以使用简短的unc路径名，并且它在遍历dns搜索后缀列表之后找到正确的fqdn名称。
我们可能不是唯一这样做的人。
https://serverfault.com/questions/675254
复制相似问题
腾讯云开发者
